Nginx server works with IP but not with arbitrary domain name

Question

I have a host with Ubuntu Server 14.04 and a LEMP stack that I intend to use as a staging/test server for a web application I am working on.

I don't have a domain name for the server and it works fine with IP address. However, for some testing I need to access it with a domain name. So I have added the following to my local machine's hosts file:

1.2.3.4 nt1.stg

The IP in this question is obviously not my server's real IP, but I am using nt1.stg as the domain.

When I go to http://1.2.3.4/path/to/script.php I get the expected response.

But with http://nt1.stg/path/to/script.php I get ERR_CONNECTION_RESET.

I have verified with Wireshark that the request is sent when using the second address. Wireshark capture shows that with the request this exchange ensues:

Me > Server: (TCP)  [SYN]
Server > Me: (TCP)  [ACK, SYN]
Me > Server: (TCP)  [ACK]
Me > Server: (HTTP) GET /path/to/script.php HTTP/1.1
Server > Me: (TCP)  [ACK]
Server > Me: (TCP)  [RST, ACK]

This is my nginx config file, in which I have set the server_name, and also have default_server:

server {
        listen 80 default_server;
        server_name nt1.stg;
        root /var/www/nt/app;
        index index.php index.html;
        access_log /var/log/nginx/access.log;
        error_log /var/www/nt/nt1_data/logs/error.log;
        location ~ \.php$ {
                try_files $uri =404;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass unix:/var/run/php5-fpm.sock;
                fastcgi_index index.php;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                include fastcgi_params;
        }
}

There are no error or access log entries for the requests made to nt1.stg as if it was never received.

Could this be a firewall issue? How should one investigate that?

Update

The issue is not what a solution was provided in this answer. I checked with wget and the same happens (works with IP and does not work with domain).

Update 2

Per @TheFiddlerWins's recommendation I added the domain to the hosts file on the server as well (both with 127.0.0.1 and the actual server IP). That didn't resolve the issue either.

Update 3

Per @drookie's advice I did a tcpdump on the server with:

tcpdump -i eth0 -s 65535 -w dumpfile.pcap -Z root

After starting the capture I made requests to both IP-based and name-based urls. Terminating the capture, the summary said:

71 packets captured
72 packets received by filter
0 packets dropped by kernel

Examining the dump with Wireshark shows no trace of the requests made to the name-based address. Notwithstanding, a local capture, at the same time the server capture was underway, shows the same old results -- that the requests to name-based address are sent to the correct IP and a TCP session is established, the HTTP request is sent to the server and acknowledged, but then the server sends a TCP RST.

When wireshark tells me this is what happens, I should conclude that it does indeed happen. If the server is not responsible for that, someone is.

My only guess is that the traffic is routed to my server transparently via a data center proxy that does not like the fact that the (arbitrary) host name the request is tagged with does not resolve to the server IP, and hence drops the HTTP request.

This is happening on a digitalocean droplet and I'm going to open a support ticket to confirm this.

Update 4

I have reached out to support and here is what they told me:

... your droplet is definitely not behind a proxy. All droplets are connected directly to the internet

and

If the networking confirms the packets reach the correct host, then the issue would be at the firewall/webserver on higher level. Any signs of the application response crashing? Perhaps some configuration issue where the app isn't being delivered by the domain the same way as the IP?

I have no debugging skills in this area. What I can think of is checking the syslog, iptables rules, and, if there are any, ufw logs. Any guidance as to where else I should look for signs and suspects would be greatly appreciated.

@TheFiddlerWins Will check that, but why should this make a difference? — Majid Fouladpour, Oct 13 '16 at 17:56
@TheFiddlerWins no change. To clarify, I did not change the `hosts` file entry, just the `server_name` in the nginx config, followed by restarting nginx. So the request was still sent to `nt1.stg`. — Majid Fouladpour, Oct 13 '16 at 18:01
Well your request is always sent to nt1.stg - the question is which IP is it using to send... You may want to verify both the client & server will resolve nt1.stg to the same IP. — TheFiddlerWins, Oct 13 '16 at 18:03
@TheFiddlerWins The client *is* resolving `nt1.stg` to the real server IP as confirmed by ping, wget, and wireshark (for browser requests). I thought that was enough to get the request to the server and the server does not need to resolve the domain. Wrong assumption? — Majid Fouladpour, Oct 13 '16 at 18:07
Do you have other `server {}` blocks that `listen` **explicitely on this IP** ? — drookie, Oct 13 '16 at 20:06
@drookie no. I have edited the default config `/etc/nginx/sites-available/default` and that is the only sym-link in `sites-enabled`. — Majid Fouladpour, Oct 13 '16 at 20:13
So you have a literally impossible situation: the HTTP works when you are accessing the server via it's IP (so there's no packet filter tampering packets to tcp/80), it doesn't work when accessing the server via it's name, but in the same time you see in a tcpdump that the packets are sent to the actual IP. This means that you are wrong in some of your statements. You obfuscated too much, so there's no way to check where exactly did this happen. You have to find the mistake by yourself. — drookie, Oct 13 '16 at 20:24
@drookie the only thing I have *obfuscated* is the actual IP address of the server. I have not even changed the arbitrary domain I am using (`nt1.stg` *is* what I am using). This is baffling and I understand it could be frustrating, but that is what I have on my hands. — Majid Fouladpour, Oct 13 '16 at 20:30
And you're getting this `ERR_CONNECTION_RESET` on multiple browsers (to rule out a browser-related issue)? — David B., Oct 13 '16 at 20:56
You could add the `info` option to the end of your `error_log` entry and see if anything more pops up in the log. — Paul, Oct 13 '16 at 20:58
@DavidB. yes, on Google Chrome and Mozilla Firefox. But, I also get the same using wget: with `-vd` switch I get `HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Closed fd 3`. So, it is *not* a browser issue. — Majid Fouladpour, Oct 13 '16 at 21:05
@Paul good suggestion. I will even go with `debug` to get more details. — Majid Fouladpour, Oct 13 '16 at 21:11
@Paul no trace of the request even with `debug` log level. To test, I added a `bad.php` file containing syntax error to cause an error. Requesting with IP, I get `HTTP ERROR 500` as expected. Producing this single `HTTP/1.1 500 Internal Server Error` response, generates 261 lines of debug info. Making the request with domain still results in `ERR_CONNECTION_RESET` and generates *zero* lines in the error.log. — Majid Fouladpour, Oct 13 '16 at 21:32
You have to take tcpdump capture on the server side and see whether it really gets the TCP session when you address the server by it's name. As I said, everything indicates you are exposing us the intended results instead of the real ones, because you made in unintentional mistake in the data interpretation. — drookie, Oct 13 '16 at 21:42
@drookie thanks. I am reading on how to do tcpdump on the server. Will update the question with the results once done. — Majid Fouladpour, Oct 13 '16 at 21:57

score 2 · Answer 1 · answered Oct 14 '16 at 09:43

Why don't you create a new conf file for your host nt1.stg ? This will quickly let you know if its a nginx config issue, network issue or something else.

server {
        listen 80;
        server_name nt1.stg;
        root /var/www/nt/app;
        index index.php index.html;
        access_log /var/log/nginx/access.log;
        error_log /var/www/nt/nt1_data/logs/error.log;
        location ~ \.php$ {
                try_files $uri =404;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass unix:/var/run/php5-fpm.sock;
                fastcgi_index index.php;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                include fastcgi_params;
        }
}

Nginx server works with IP but not with arbitrary domain name

1 Answers1