@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 
