2

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.

16
  • What happens if you set _ as your server_name? Oct 13, 2016 at 17:54
  • @TheFiddlerWins Will check that, but why should this make a difference? Oct 13, 2016 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. Oct 13, 2016 at 18:01
  • 2
    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, 2016 at 20:58
  • 1
    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, 2016 at 21:42

1 Answer 1

2

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;
        }
} 

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .