@downpw said in nginx can't start again:
@justoverclock said in nginx can’t start again:
server
{
server_name justoverclock.it www.justoverclock.it autoconfig.justoverclock.it autodiscover.justoverclock.it;
root /home/justoverclock/public_html;
index index.php index.htm index.html;
access_log /var/log/virtualmin/justoverclock.it_access_log;
error_log /var/log/virtualmin/justoverclock.it_error_log;
fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE nginx;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_param SCRIPT_FILENAME /home/justoverclock/public_html$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_param DOCUMENT_ROOT /home/justoverclock/public_html;
fastcgi_param SERVER_PROTOCOL $server_protocol;
fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param HTTPS $https;
location ~ ^/ads.txt {
root /var/www;
}
location /
{
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $http_host;
proxy_pass http://127.0.0.1:2368;
rewrite ^\Q/mail/config-v1.1.xml\E(.*) $scheme://$host/cgi-bin/autoconfig.cgi$1 break;
rewrite ^\Q/.well-known/autoconfig/mail/config-v1.1.xml\E(.*) $scheme://$host/cgi-bin/autoconfig.cgi$1 break;
rewrite ^\Q/AutoDiscover/AutoDiscover.xml\E(.*) $scheme://$host/cgi-bin/autoconfig.cgi$1 break;
rewrite ^\Q/Autodiscover/Autodiscover.xml\E(.*) $scheme://$host/cgi-bin/autoconfig.cgi$1 break;
rewrite ^\Q/autodiscover/autodiscover.xml\E(.*) $scheme://$host/cgi-bin/autoconfig.cgi$1 break;
ssl_certificate /home/justoverclock/ssl.combined;
ssl_certificate_key /home/justoverclock/ssl.key;
}
client_max_body_size 5G;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
location /cgi-bin/
{
gzip off;
root /home/justoverclock/cgi-bin;
fastcgi_pass unix:/var/fcgiwrap/163388321568860.sock/socket;
fastcgi_param SCRIPT_FILENAME /home/justoverclock$fastcgi_script_name;
}
listen 165.232.65.12:443 ssl default_server;
ssl_certificate /etc/letsencrypt/live/justoverclock.it-0001/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/justoverclock.it-0001/privkey.pem; # managed by Certbot
if ($scheme = http)
{
rewrite ^/(?!.well-known)(.*) https://justoverclock.it/$1 break;
}
fastcgi_read_timeout 60;
}
server
{
if ($host = justoverclock.it) {
return 301 https://$host$request_uri;
} # managed by Certbot
server_name justoverclock.it www.justoverclock.it autoconfig.justoverclock.it autodiscover.justoverclock.it;
listen 165.232.65.12 default_server;
return 404; # managed by Certbot
}
normally, the ssl parameter must be enabled on listening sockets in the server block
Backup the conf file before and test that
unfortunately I have to leave
@downpw not work
@justoverclock I can get to this in around an hour
@justoverclock done, i’ve removed that line and works again
@phenomlab fixed it, removed the two lines and all works again
@justoverclock good 
What caused the issue ? Was something new added to nginx.conf ?
@justoverclock you should also change this line
client_max_body_size 5G;
That could expose your server to a denial of service if someone decides to upload that large a file.
this line ?
ssl_certificate /home/justoverclock/ssl.combined;
ssl_certificate_key /home/justoverclock/ssl.key;
@downpw yep exactly
@justoverclock those two lines
ssl_certificate /etc/letsencrypt/live/justoverclock.it-0001/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/justoverclock.it-0001/privkey.pem; # managed by Certbot
Are issued by certbot, but aren’t normally positioned in the server block. Very odd.
undefined phenomlab has marked this topic as solved on
@justoverclock
I have not yet gone through the comments to see what they answered you,
But never restart Nginx before checking that all the blocks are working properly (this is how you check: sudo nginx -t)
When nginx is restarted with an error it causes all sites (error 521) to shut down until the fault is resolved.
If the test passed successfully you can restart Nginx (how to run: sudo systemctl reload nginx)
@elhana-fine Also worth noting that nginx -t is not disruptive, and will not cause your sites to go offline in the event that the test fails.
@phenomlab
I am writing this from past experience.
Whenever the test failed, all sites on the server were shut down (and returned error 521/502)
Maybe I’m wrong, I write my experiences
@elhana-fine Interesting. That shouldn’t happen with a test. It’s supposed to be a dry run.
@phenomlab
I mean when the test failed and I restarted the nginx with the error (sudo systemctl reload nginx)
Apparently an error in one block in Nginx affects all blocks.
@elhana-fine Yes that will happen of of course if you still choose to restart the NGINX service after making a change and the test fails. The test on it’s own will state the error and the line number allowing you to fix that first 
