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.
Related
On our research project, we have an Ubuntu 20.04 LTS virtual machine running, which should serve via nginx multiple project related websites/apps on different subdomains.
The setup is supposed to be as following:
maindomain --> redirecting to our project info site hosted by our university
subdomain1.maindomain --> nextcloud for project management stuff served via nginx
subdomain2.maindomain --> serving app1 via nginx proxy and gunicorn (for django)
subdomain3.maindomain --> serving app2 via nginx proxy and express.js
What I did:
Added the IP address of the server to the A record of our German domain hoster Strato.
https://maindomain: configured nginx to redirect to university site
server {
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
root /var/www/html;
server_name maindomain;
return 301 https://university-site;
ssl_certificate /etc/ssl/wildcard.crt;
ssl_certificate_key /etc/ssl/wildcard.key;
ssl_trusted_certificate /etc/ssl/wildcard.crt;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
}
configured nginx to serve nextcloud stuff in /etc/nginx/sites-available/subdomain1.maindomain
server {
listen 80;
#listen [::]:80;
server_name subdomain1.maindomain;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
root /var/www/nextcloud;
index index.html index.php /index.php$request_uri;
server_name subdomain1.maindomain;
ssl_certificate /etc/ssl/wildcard.crt;
ssl_certificate_key /etc/ssl/wildcard.key;
ssl_trusted_certificate /etc/ssl/wildcard.crt;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
... lot's of nextcloud related stuff ...
}
up to this point: everything is working fine for some time now
What I tried:
Now it was time to start deploying the next app on subdomain2.maindomain. In my naive thinking I thought just to copy /etc/nginx/sites-available/subdomain1.maindomain to subdomain2.maindomain and change "subdomain1.maindomain" to "subdomain2.maindomain" in the config file (of course: getting rid of all the nextcloud stuff, too).
First I experimented with just serving a static index.html page to see if everything is working:
server {
listen 80;
server_name subdomain2.maindomain;
root /var/www/subdomain2;
index index.html index.php /index.php$request_uri;
# return 301 https://$server_name$request_uri;
}
added a static index.html into /var/www/subdomain2
restarted nginx (feels like a 1000 times actually... :-))
Now when I try to navigate to "http://subdomain2.maindomain" it throws the error: DNS_PROBE_FINISHED_NXDOMAIN
For testing purposes I added our IP address to the configuration /etc/nginx/sites-available/subdomain2.maindomain, resulting in:
server {
listen 80;
server_name subdomain2.maindomain IP_ADDRESS;
root /var/www/subdomain2;
index index.html index.php /index.php$request_uri;
# return 301 https://$server_name$request_uri;
}
Now, when I browse to IP_ADDRESS the static index.html page is served just as expected, but browsing to subdomain2.maindomain still fails.
What can I do next?
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.
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....
I am trying to implement HTTPS on a site ased on nginx server, Now even with the below config it only opens HTTP site
My server config for nginx server is like this
server {
listen 443 ssl http2;
ssl_certificate /etc/letsencrypt/live/mydomain.in/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mydomain.in/privkey.pem;
server_name mydomain.in www.mydomain.in;
rewrite ^(.*) http://$server_name$1 permanent;
}
server {
server_name mydomain.in www.mydomain.in;
access_log /var/log/nginx/mydomain.in.access.log rt_cache_redis;
error_log /var/log/nginx/mydomain.in.error.log;
root /var/www/mydomain.in/htdocs;
index index.php index.html index.htm;
include common/redis-php7.conf;
include common/wpcommon-php7.conf;
include common/locations-php7.conf;
include /var/www/mydomain.in/conf/nginx/*.conf;
}
The server does not serve HTTPS Requests i.e even if i specifically put https in browser it still takes me back to http site. I am not able to diagnose if its nginx or wordpress which is at fault ?
Note : the traffic is routed through cloudflare dns and certificate is
switch off in cloudflare so that it doesn't interfere. I am Relatively new to nginx
Well below is the basic idea.
server {
server_name mydomain.in www.mydomain.in;
listen 80;
location / {
return 301 https://mydomain.in$request_uri;
}
}
server {
listen 443 ssl http2;
ssl_certificate /etc/letsencrypt/live/mydomain.in/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mydomain.in/privkey.pem;
server_name mydomain.in www.mydomain.in;
access_log /var/log/nginx/mydomain.in.access.log rt_cache_redis;
error_log /var/log/nginx/mydomain.in.error.log;
root /var/www/mydomain.in/htdocs;
index index.php index.html index.htm;
include common/redis-php7.conf;
include common/wpcommon-php7.conf;
include common/locations-php7.conf;
include /var/www/mydomain.in/conf/nginx/*.conf;
}
The top server block listens on port 80 (http). It has one location block which does a return 301. return is preferred over rewrites in most cases. I also put it into a location block because you have a letsencrypt ssl cert which might require another location ^~ /.well-known { block to help handle that.
The second server block listens on port 443 (https). It has the SSL certs and includes the information exposed previously for as the http server block.
This setup will handle redirecting from http on either mydomain.in or www.mydomain.in to https mydomain.in. On https both mydomain.in and www.mydomain.in will receive SSL requests.
If you want it to redirect to a primary https domain you can add another server block for the secondary(ies) like so.
server {
server_name www.mydomain.in;
listen 443 ssl http2;
ssl_certificate /etc/letsencrypt/live/mydomain.in/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mydomain.in/privkey.pem;
location / {
return 301 https://mydomain.in$request_uri;
}
}
Of course, this means you would have to change the second server block to remove the secondary(ies) domain names.
Also while testing you might want to change the 301s to 302s so that if you misconfigure the first time that it not be stuck in the browser cache. After you get everything to a good state then change back to 301s.
Environment:
Ubuntu 16.04 LTS
Nginx version: nginx/1.10.3 (Ubuntu)
OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016
Simple Description:
I have configured nginx to use http2, and some of my requests are using http2, however, some of my requests are using http1.1 instead.
Nginx Configuration:
I use exactly the same configuration as Mozilla generator suggest
server {
listen 80 default_server;
listen [::]:80 default_server;
# Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
# certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
ssl_certificate /path/to/signed_cert_plus_intermediates;
ssl_certificate_key /path/to/private_key;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
# Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
ssl_dhparam /path/to/dhparam.pem;
# intermediate configuration. tweak to your needs.
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
ssl_prefer_server_ciphers on;
# HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
add_header Strict-Transport-Security max-age=15768000;
# OCSP Stapling ---
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;
## verify chain of trust of OCSP response using Root CA and Intermediate certs
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
resolver <IP DNS resolver>;
....
}
And my special configuration looks like:
server_name mydomain;
set $root myrootpath;
root $root;
location / {
try_files $uri /index.html;
}
location /api/ {
proxy_pass http://127.0.0.1:5000/api/;
proxy_redirect default;
}
location /page/ {
proxy_pass http://127.0.0.1:5000/page/;
proxy_redirect default;
}
More Details:
The http request to /api and /page can use http2 correctly, but when the browser request static resources like images or .js files under / or /static, it will use http1.1, I attached picture
after I clear the cache, and still those static resources are requested via http1.1. However, the response status code is 304 this time
I searched google and do not find the answer, people said OpenSSL and nginx version may cause http2 problem, but my version has no such problem, and it works for /api and /page route request. So what's the problem?
As #sbordet said the requests that were not served by HTTP/2 in the first screenshot were served from the disk cache and were presumably downloaded using HTTP/1.1 originally, hence why that’s what they show.
The requests that were not downloaded by HTTP/2 in the second screenshot were either the same or were 304 Not Modified requests - so the original version from the disk cache was loaded and it was presumably loaded from HTTP/1.1.
Clear your cache properly or, if using Chrome tick the “Disable cache” option in Developer Tools network and reload and they should all be loaded over HTTP/2.