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 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 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 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, trying to access the site by the full subdomain name (instead of just caused a Django DisAllowedHost error with the suggestion, You may need to add 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 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.

Show comments

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

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.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.

Hi there Joan,

Generally speaking, the DNS changes can’t cause server errors. What the A record in your DNS zone does is to point your Domain name to a specific IP address.

The 500 error could be caused by either the Nginx configuration change that is made when the new domain name is added or the Django changes after that.

When changing the domain name for a Django application, you need to make sure that you add your new domain to your allowed Django hosts:

nano /path/to/your/yourprojectname/settings/ 

And add and the www version of the site to the ALLOWED_HOSTS.

The 500 error is also a generic error that shows that something is wrong on the server-side but it does not really indicate what the actual problem is. In order to find out the actual problem and the actual error, you need to check your server logs and possibly the application logs as well.

The Nginx server log is by default at:


If the log is empty, it is possible that your website has a custom log location. You can check that in your Nginx server block inside the /etc/nginx/sites-enabled directory. The configuration line will look like this:

    error_log   /home/newuser/yourprojectname/nginx-error.log;

Also, you could check the Gunicorn status with the following command:

sudo journalctl -u gunicorn

If the logs are empty, what I could suggest is to enable the Django debug mode so that it would display the actual problem rather than the generic 500 error.

Feel free to share the error here as well so I could try to advise you further.

Regards, Bobby