O servidor Nginx trabalha com IP, mas não com nome de domínio arbitrário

2

Eu tenho um host com o Ubuntu Server 14.04 e uma pilha LEMP que pretendo usar como um servidor de teste / teste para um aplicativo da web em que estou trabalhando.

Eu não tenho um nome de domínio para o servidor e funciona bem com o endereço IP. No entanto, para alguns testes, preciso acessá-lo com um nome de domínio. Então, adicionei o seguinte ao arquivo hosts da minha máquina local:

1.2.3.4 nt1.stg

O IP nesta questão obviamente não é o IP real do meu servidor, mas eu estou usando nt1.stg como o domínio.

Quando vou para http://1.2.3.4/path/to/script.php obtenho a resposta esperada.

Mas com http://nt1.stg/path/to/script.php obtenho ERR_CONNECTION_RESET .

Eu verifiquei com o Wireshark que o pedido é enviado ao usar o segundo endereço. A captura do Wireshark mostra que, com o pedido desta troca, ocorre:

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]

Este é o meu arquivo de configuração nginx, em que eu configurei o server_name, e também tenho 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;
        }
} 

Não há entradas de log de erro ou acesso para as solicitações feitas para nt1.stg como se nunca tivessem sido recebidas.

Este poderia ser um problema de firewall? Como se deve investigar isso?

Atualizar

O problema não é o que uma solução foi fornecida em esta resposta . Eu verifiquei com wget e o mesmo acontece (funciona com IP e não funciona com o domínio).

Atualização 2

Per @ recomendação TheFiddlerWins Eu adicionei o domínio para o arquivo de hosts no servidor também (ambos com 127.0.0.1 e o IP do servidor real). Isso também não resolveu o problema.

Atualização 3

O conselho de Per @ drookie Eu fiz um tcpdump no servidor com:

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

Depois de iniciar a captura, fiz solicitações para URLs baseadas em IP e em nome. Terminando a captura, o resumo dizia:

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

Examinar o despejo com o Wireshark não mostra nenhum rastreamento das solicitações feitas ao endereço baseado em nome. Não obstante, uma captura local, ao mesmo tempo em que a captura do servidor estava em andamento, mostra os mesmos resultados antigos - que as solicitações para o endereço com base no nome são enviadas para o IP correto e uma sessão TCP é estabelecida , o pedido HTTP é enviado para o servidor e reconhecido, mas o servidor envia um TCP RST.

Quando o wireshark me diz que é isso que acontece, devo concluir que isso realmente acontece. Se o servidor não é responsável por isso, alguém é .

Meu único palpite é que o tráfego é roteado para o meu servidor de forma transparente por meio de um proxy de datacenter que não gosta do fato de o nome do host (arbitrário) com o qual o pedido está marcado não resolver o IP do servidor e, portanto, a solicitação HTTP.

Isso está acontecendo em um droplet digitalocean e vou abrir um ticket de suporte para confirmar isso.

Atualização 4

Eu estendi a mão para apoiar e aqui está o que eles me disseram:

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

e

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?

Eu não tenho habilidades de depuração nesta área. O que eu posso pensar é verificar o syslog, as regras do iptables e, se houver, os logs do ufw. Qualquer orientação sobre onde mais eu deveria procurar sinais e suspeitos seria muito apreciada.

    
por Majid Fouladpour 13.10.2016 / 19:20

1 resposta

3

Por que você não cria um novo arquivo conf para seu host nt1.stg? Isso permitirá que você saiba rapidamente se é um problema de configuração do nginx, problema de rede ou qualquer outra coisa.

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;
        }
} 
    
por 14.10.2016 / 11:43