Easily configure a performant, secure, and stable NGINX server.Learn More
Internal server error / 500 after adding DNS records (Ubuntu — gunicorn — nginx / Django-Wagtail)
Twice now after adding DNS records my site has quit working and displayed the “internal server error” (500) page. I’m still dead in the water. Based on other posts here and on stackoverflow this seems to be a fairly common event with DigitalOcean. Please help.
I can’t afford to have the site go down after each subdomain is added or another configuration change is made. I suspect that the problem is at least partly due to some sort of server-side caching, that blocks/delays recognition of changes in configuration and other site files, maybe done by nginx (more below about why I think so ). Is there a trick to clearing out any such caching?
The site is configured properly per instructions here and here. It was working fine on DigitalOcean before I added the first DNS record—the pages displayed as expected when accessed at its numeric IP address. But after I added the apex domain record (an A-type record for
xxxx.org) and reconfigured my settings for the domain name, the internal server error appeared at the domain address. I had added the domain name correctly to the nginx configuration file (at
…/sites-available) and to my production.py settings file. I checked repeatedly before and after receiving the error to make sure the punctuation and what not were correct. I deactivated and restarted the virtual environment and stopped and started gunicorn and nginx multiple times. I repeatedly checked gunicorn and nginx per their status commands and the nginx -t command and never received any error messages. The server itself started up every time without any errors either. The “internal server error” persisted throughout all that effort to troubleshoot.
When I rolled back to the IP address and went back to accessing the site that way, I still got the internal server error.
Then, many hours later, the site suddenly started working again at the IP address, without my having changed anything. I re-reconfigured for the domain name, and now it worked there as well, with no errors of any sort.
Pleased, and hoping that the server error after adding the apex domain record was just a weird glitch, I went back and added a subdomain (just
www.xxxx.org). Not so fast: Instantly the site went down in exactly the same way, with the internal server error. Once again, re-re-rechecking the settings, and multiple rounds of stopping and restarting all the services have done nothing.
Here’s the clue I have about this issue being a caching-type problem somewhere on the server: Prior to my adding the DNS record for the subdomain at
www.xxxx.org, trying to access the site by the full subdomain name (instead of just
xxxx.org) caused a Django DisAllowedHost error with the suggestion,
You may need to add www.xxxx.org to ALLOWED_HOSTS. I went in and added the subdomain to
ALLOWED_HOSTS just to see what would happen–again, this was before I’d added a domain record for the subdomain on the DO control panel. After resetting everything again and restarting the server, the same DisAllowed error came up. When I checked “‘Local vars”’ on the error page, the readout from production.py lacked the new subdomain entry I had made at
ALLOWED_HOSTS – the code shown on the error page was as of prior to my edit. When I reloaded the page from scratch (Ctl+F5) and tried it on other devices that hadn’t been to the site before and behavior was identical—I got the same outdated Local vars display. In a similar way, when a small change I made to the css did not show up on the working pages (during the time the site was functioning) even when I cleared the browser cache, reloaded with Ctl+F5, and tried viewing pages on other devices. In other words, the server does seems to be serving up cached stuff.
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.×