Internal server error / 500 after adding DNS records (Ubuntu — gunicorn — nginx / Django-Wagtail)

Posted April 28, 2021 1.2k views

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.

  • PS: nginx error log for the site is empty–no errors. The master error log, if that’s what you call it, is inaccessible by the user who owns the site’s venv. I’ll get around to logging in as root and looking at the master error log, but the datestamp on it predates this ‘internal server error’ business.

  • Hi Joan,

    I am facing the same issue mostly during OTP validation and payment gateway redirect. I am not sure how to resolve this. Any leads would be really helpful.


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.

Submit an Answer
1 answer

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.


  • Hello Bobby, thanks for your post.

    I understand that DNS changes shouldn’t cause the ‘internal server error’ but other than adding the new subdomain name to the two files (the nginx config file and that’s the only—and I mean only—change I made, after I created the new A record.

    I said most of this in my original post and the PS, but I can see how you might have missed it:
    — I did add the new domain to and to the nginx config file, and I have triple- checked that it was spelled right etc.
    — I do have a site-specific error log specified in the nginx config file in /sites-enabled. That’s the error log that is empty. I moved the favicon file and sure enough the log showed an error about that, so it’s the correct log. (No errors again after I moved the favicon back to where it’s supposed to be).
    — I have repeatedly checked gunicorn and nginx status and they always report they are running fine, no errors or warnings.
    — The runserver command runs without any errors reported.

    Any other ideas? I’ll try setting DEBUG back to True to see if any better error message gets produced.

    • Hi,

      Yes enabling debug mode should show you the actual problem rather than the generic 500 error.

      Yes, adding an A record to your DNS zone can not really cause internal server errors. As you made 2 more changes: change to the Nginx config file and the file, most likely one of the two is causing the internal server error.

      But in all cases when there is a generic server error, it is best to either check the logs or enable debug mode if possible to see what actually is causing the problem.

      Let me know how it goes.

      • Progress, in that with DEBUG set to True the site again loads and displays fine. But there are no errors reported so I’m in the dark. Setting DEBUG to False again (disabling debug mode) brings back the ‘Internal server error’ page. Error logs remain empty.

        I agree that adding a DNS record should not cause an internal server error, so maybe just a coincidence.

        • Hi there,

          Good to hear that with DEBUG enabled, you are able to see the actual errors causing the problem.

          Feel free to share the errors here in case that you need a piece of advice.


          • I think you misread what I posted; enabling DEBUG did not allow me to see the actual errors, or any errors. The site runs fine with DEBUG enabled; with DEBUG off, it breaks with “internal server error.” The server log is still empty–no errors, no contents of any kind.

          • Hi there Joan,

            Ah I see. I came across the same problem discussed here.

            The person is reporting a 500 error when setting DEBUG to false which they’ve figured out is caused by the ALLOWED_HOSTS definition.

            Can you share how you’ve defined the ALLOWED_HOSTS = [] value exactly?