What I want:
I want to redirect www.mydomain.eu and mydomain.eu to, let's say, www.google.com, while having access to a local gitea server through git.mydomain.eu.
What I have:
I have this nginx config in /etc/nginx/sites-available:
ssl_certificate /XXX/fullchain.pem;
ssl_certificate_key /XXX/privkey.pem;
server {
listen 443 ssl default_server;
listen 80 default_server;
server_name www.mydomain.eu mydomain.eu;
access_log /var/log/nginx/reverse-access.log;
error_log /var/log/nginx/reverse-error.log;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
location / {
return 301 http://google.com;
}
}
server {
listen 443 ssl;
server_name git.mydomain.eu;
access_log /var/log/nginx/reverse-access.log;
error_log /var/log/nginx/reverse-error.log;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
location / {
proxy_pass http://localhost:3000;
}
}
with XXX being an absolute location and mydomain being the actual name of my domain (this config file is also in sites-enabled thanks to a "ln -s" command)
What my problem is
When I go to https://mydomain.eu, I am redirected to https://www.google.com/. => great !
When I go to https://www.mydomain.eu, Firefox (and chrome) says that "This site can’t be reached" => :(, different behavior than mydomain.eu, why ?
Same with https://git.mydomain.eu ("This site can’t be reached") => why ? I am sure that http://localhost:3000 is a valid website, as I can access it through its IP address.
It seems that nginx ignores the "www" in my first rule, and I can't figure out why.
This is not related to nginx but your domain host configuration as the net traffic not even reach to your nginx server yet.
In order to be able to access git.example.com, you will need to have a CNAME configured at your host with CNAME host as git, and value as example.com. You also need another one for www, as shown below:
Type Host Value
CNAME git example.com
CNAME www example.com
One more thing to be aware is if you are using a sub-domain like git.example.com, depend on how you configure your ssl certificate and what kind of ssl certificate you purchased, the git.example.com may need a separate ssl certificate, unless you have a multi-site ssl certificate....
Related
I have an nginx server running. I want it to redirect http://www.example.com to https://www.example.com, but not touch any other subdomains like http://foo.example.com.
For some reason, no matter what I add in the subdomain, it still gets rerouted. My webpage shows on www.example.com (as it should), but also on foo.example.com and example.com (as it shouldn't)
This is my example.com config file:
server {
listen 80;
server_name www.example.com;
# For debug
add_header X-debug-message "listen:80, server_name:www.example.com, redirect:https://$host$request_uri" always;
# Riderect
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name www.example.com;
# For debug
add_header X-debug-message "listen:443, server_name:www.example.com, redirected:https://$host$request_uri" always;
# SSL
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
root /var/www/example.com;
# Redirect
location / {
proxy_pass http://192.168.1.224:80;
}
}
Going to www.example.com shows me my webpage as expected. But going to foo.example.com also gives me my webpage - which it shouldn't. example.com also gives me the webpage.
Opening www.example.com in my browser, I see the following http header (as expected):
X-debug-message: DEBUG: listen:443, server_name:www.example.com, redirected:https://www.example.com/
Opening foo.example.com in my browser, I see the following http header (not as expected):
X-debug-message: DEBUG: listen:443, server_name:www.example.com, redirected:https://foo.example.com/
How can I make my nginx only redirect www.example.com ?
Ensure that the dns record for foo.yourdomain.com is actually created with
dns provider
Create a second server block for the subdomain 'foo.example.com'
otherwise all request to port 80
will be redirected to available server block, which in your case
www.example.com - the server block should look like this:
server {
server_name foo.example.com;
location / {
root path/to/foo/index.html;
index index.html index.htm;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
try_files $uri $uri/ /index.html;
}
listen 443 ssl; # managed by Certbot
ssl_certificate
/etc/letsencrypt/live/example.com/fullchain.pem; # n
managed by Certbot
ssl_certificate_key
/etc/letsencrypt/live/nextoma.com/privkey.pem; # managed by
Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by
Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by
Certbot
}
Add ssl certificate to the foo.example.com with the command:
certbot --nginx -d foo.example.com
Restart nginx and recheck foo.example.com again
You need to make the first entry listen on 443 for HTTPS and server name _ and return 404.
server {
listen 443 ssl;
server_name _;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_certificate /etc/nginx/certs/nginx-selfsigned.crt;
ssl_certificate_key /etc/nginx/certs/nginx-selfsigned.key;
location / {
return 404;
}
}
By having the typical HTTP to HTTPS redirect in the file (I have it as the last entry):
server {
listen 80 default_server;
server_name _;
return 301 https://$host$request_uri;
}
Then all HTTP requests get converted to the HTTPS counterparts. Then, if you request a subdomain that has not been configured in the NGINX configuration file, it will default to the first entry which returns a 404. All other configured subdomains, and the root domain, if you have that as an entry, will resolve correctly.
Also you can keep your wildcard DNS, which is more practical than having to add each subdomain as an entry, as you point out in your answer.
Thank you for all the comments!
For other readers, and future reference, this is now my enlightened understanding.
nginx treats the first entry in it's enabled-sites conf as a default route. Thus, the first entry
server {
listen 80;
server_name example.net www.example.net;
...
}
is in fact treated as
server {
listen 80 default_server;
server_name example.net www.example.net;
...
}
So, my mistake, was to add *.example.com -> MyIP to my DNS, and assuming nginx would just 404 all routes I didn't explicitly define. When in fact, it looks for a route that matches foo.example.com, and if it doesn't, routes it to the default route.
So, I now changed my DNS to explicitly handle all subdomains I want routed, and I list all of them explicitly in nginx.
Now - how I achieve my original plan - to just route *.example.com to my IP, and have nginx 404 all requests except the ones I excplicitly define - I still don't understand.
Explicitly routing all subdomains in the DNS is a bit less flexible, as I need to update the DNS and wait for the change to propagate if I want to test a new service internally. But, I guess that is fine for now.
I struggle to change configuration of already set-up container to use SSL.
I have VPS with CentOs 8, on which I have 2 containers running, one with Wordpress and other with wordpress DB. Wordpress works fine on port 80. I'd like to enable SSL and move it to 443.
Right now what I did:
Open firewall port 443 for docker trusted interface;
Changed wp-config.php with wp-home and wp-site url to use respectively https protocols;
Added FORCE_SSL_ADMIN in wp-config.php
In stoped container changed hostconfig.json and config.v2.json to use respectively 443 protocols to 80
EDIT 1
Current outcome:
When running curl localhost:443 I got wordpress page returned (from local machine to wordpress), however I do not think it uses https protocol.
Desired outcome:
I'd like to be able to serve wordpress over https for external traffic. Right now I got connection refused message.
If I were you I wouldn't bother doing anymore config at container level, rather I'd use an application server like Nginx or Apache to resolve DNS and redirect incoming traffic to the containers via reverse proxy.
If this is not possible, could you please provide the (I'm assuming) docker-compose file and dockerfiles you have to set up your server?
EDIT:
Don't run the docker container on 443, it can listen internally on any port you want, but map it to something else, like 8080, for the following example config.
nginx.conf
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
gzip on;
server {
listen 80;
server_name example.com;
rewrite ^ https://$host$request_uri permanent;
}
server {
listen 443 ssl http2;
server_name example.com;
ssl on;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/privkey.key;
location / {
proxy_pass http://127.0.0.1:8080;
}
}
}
Torrent client, qtorrent, has web GUI.
Torrent client on one server with unique ip address.
Nginx reverse proxy setup with unique ip address.
Have setup Nginx reverse proxy to point subdomain address internal ip address with specific port (traffic HTTPS via letsencrypt).
Can load Torrent Client GUI login page, but no page formatting (images provided below).
enter image description here
enter image description here
Can access Torrent Client GUI when on local network, via local ip address:port.
When login details are entered in site (that is accessed via domain address sub.example.com), a blank white web page is loaded and the web address changes to "https://www.sub.example.com/?username=UNameExample&password=PASSWORDExample"
Any advise on where to confirm or check configurations.
Below worked for Nginx Reverse Proxy setup for qtorrent.
Original found solution here.
#
#Code below is for SSL
#
server {
listen 80;
listen [::]:80;
server_name bittorrent.example.com www.bittorrent.example.com;
include snippets/letsencrypt.conf;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
server_name bittorrent.example.com;
ssl_certificate /etc/letsencrypt/live/bittorrent.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/bittorrent.example.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/bittorrent.example.com/chain.pem;
include snippets/ssl.conf;
include snippets/letsencrypt.conf;
return 301 https://www.bittorrent.example.com$request_uri;
}
server {
listen 443 ssl http2;
server_name www.bittorrent.example.com;
ssl_certificate /etc/letsencrypt/live/bittorrent.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/bittorrent.example.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/bittorrent.example.com/chain.pem;
include snippets/ssl.conf;
include snippets/letsencrypt.conf;
location / {
proxy_pass http://192.168.0.10:9091/;
proxy_set_header X-Forwarded-Host $server_name:$server_port;
proxy_hide_header Referer;
proxy_hide_header Origin;
proxy_set_header Referer '';
proxy_set_header Origin '';
add_header X-Frame-Options "SAMEORIGIN";
}
}
I am having issues with CORS, specifically with max cdn. CORS was working properly with maxcdn until a few days ago. I have posted my host config and the cors header is included.
I am stumped at this point, as I have done the following to troubleshoot:
Disabled a rocket-cache specific configuration for nginx included in
the server block.
I have changed caching methods - rather than redis-hhvm I have tried
switching over to fcgi-hhvm with rocket cache.
I have disabled rocket cache after clearing it's cache - then purging
the entire cache, and used a third party plugin for wordpress
specifically for linking the cdn.
I am using SNI with SPDY on maxcdn - I have a cert just for the subdomain (cdn.jurisdesk.com). And I am using Digitalocean for hosting.
Below is my current nginx config (everything was working properly until a few days ago which prompted me to speak with maxcdn support - who are great by the way, and extremely knowledgeable when it comes to advanced configurations specifically using nginx).
server {
server_name www.jurisdesk.com;
ssl_certificate_key /path/to/key/foobar.key;
ssl_certificate /path/to/cert/foobar.crt;
listen *:80;
listen *:443 ssl spdy;
listen [::]:80 ipv6only=on;
listen [::]:443 ssl spdy ipv6only=on;
return 301 https://jurisdesk.com$request_uri;
}
server {
server_name jurisdesk.com;
listen *:80;
listen [::]:80;
return 301 https://jurisdesk.com$request_uri;
}
server {
server_name jurisdesk.com;
listen *:443 ssl spdy;
listen [::]:443 ssl spdy;
ssl on;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
ssl_certificate_key /path/to/key/foobar.key;
ssl_certificate /path/to/cert/foobar.crt;
access_log /var/log/nginx/jurisdesk.com.access.log rt_cache_redis;
error_log /var/log/nginx/jurisdesk.com.error.log;
root /var/www/jurisdesk.com/htdocs;
index index.php index.html index.htm;
include common/redis-hhvm.conf;
include rocket-nginx/rocket-nginx.conf;
include common/wpcommon.conf;
include common/locations.conf;
location ~ \.(ttf|ttc|otf|eot|woff|woff2|font.css|css|js)$ {
add_header Access-Control-Allow-Origin "*";
}
}
I have also added CORS to rocket-nginx.conf - as this is something I've been tinkering with lately and reflects a change to my config - however I have also removed the directive to eliminate that as the cause of the problem.
My server is running NGINX. My problem is my site is accessible by both IP address and the domain. But I want that when someone browse the IP address the user shoulde be redirected to my domain.
Example :: When any one browse through http://107.170.126.xxx he should be redirected to http://mydomain.com
Please can anybody help me? Thanks in advance
so you can add the server block in the sites-available configuration file like below
server {
listen 80;
server_name 111.11.111.111;
return 301 $scheme://yourname.com$request_uri;
}
so above code will make sure that if you enter 111.11.111.111 it will redirect to http://yourname.com
make sure after editing the config file to reload nginx server
It is known as IP Canonical Issue
You want your ip address to be redirected to your domain name
for that you can add following code in nginx server block or add an additional server block in nginx configuration
server {
listen 80;
server_name www.example.com example.com 192.168.xxx.xx;
return 301 https://www.example.com$request_uri;
}
I use this configuration on my server; if you try an HTTP connection to the IP address of the VPS it will be redirected to my main web site.
i solved redirect from ip adress http/https in ispconfig with:
server {
listen *:80;
listen *:443 ssl http2;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_certificate /var/www/clients/client1/web1/ssl/domain.example-le.crt;
ssl_certificate_key /var/www/clients/client1/web1/ssl/domain.example-le.key;
server_name xxx.xxx.xxx.xxx;
return 301 https://domain.example;
}
server {
listen *:80;
listen *:443 ssl http2;
*#Required TLS Version*
ssl_protocols TLSv1.1 TLSv1.2;
*#SSL Certificate Path*
ssl_certificate /etc/nginx/keyfiles/ssl_certificate.crt;
ssl_certificate_key /etc/nginx/keyfiles/ssl_cert.key;
*#IP Address*
server_name 000.111.222.333;
*#Domain Name to be redirected*
return 301 https://www.domainname.com/;
}