I think it narrows down to this:

For some reason the host name matters to Nginx when it's trying to figure out whether to proxy the request. If the host name is set to git.example.com the request does not seem to go through, but if it's set to then it goes through. Why does the host name matter?

Filed an issue with Nginx here

Original Question

When I type in the IP address of the reverse proxy directly into my browser bar, it does perform the redirect.

In this case I'll enter and the redirect to is performed.

When using a URL that is resolved via the /etc/hosts entry git.example.com the "Welcome to Ngnix page" is shown instead of the page that would result from the redirect.

IIUC the browser will first resolve the IP address per the URL entry git.example.com, and so both should result in the proxy configuration being invoked, but that is not what happens.

This is the configuration:

server {
    listen 80;
    server_name git.example.com;

    proxy_set_header X-Real-IP  $remote_addr; # pass on real client IP

    location / {

One interesting thing is that I can navigate to for example:

If I then change with git.example.com I get Nginxs "404 not found" page.


I spent a few hours yesterday fiddling with nginx and gogs configurations with no luck.

What did work was to set the A Record on the DNS configuration of the domain name for the git subdomain to point to the right IP address.

  • I I actually have this working when I run all the containers separately outside of docker-compose. I'm going to try going back to the manual setup again and see if it still works or if nginx has changed something that now makes it not work. I'll post all my steps in detail so that I can show if docker-compose is causing it. – Ole Oct 24 '18 at 21:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.