Curl resposta trava

Question

Eu tenho um site configurado em uma caixa virtual. Eu posso acessá-lo muito bem a partir de um navegador na minha máquina, mas eu tenho problemas para acessá-lo via CURL enquanto SSH'ed na caixa.

Quando eu tento, o curl trava antes de exibir a resposta e sair.

Isso é o que eu executo: curl -vvv site1.dev/

Esta é a saída que ela fornece:

* Hostname was NOT found in DNS cache
*   Trying 192.168.10.10...
* Connected to site1.dev (192.168.10.10) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.35.0
> Host: site1.dev
> Accept: */*
> 
< HTTP/1.1 200 OK
* Server nginx/1.9.7 is not blacklisted
< Server: nginx/1.9.7
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Cache-Control: no-cache
< Date: Fri, 08 Apr 2016 16:47:30 GMT
< 
* Connection #0 to host site1.dev left intact
hi

A parte da solicitação é enviada imediatamente, mas a resposta trava por alguns segundos (parece 120ish) e, em seguida, enrola a saída com essa mensagem: * Connection #0 to host site1.dev left intact

Isso é seguido pelo corpo apropriado da resposta, "oi".

Estou um pouco perdido - quaisquer ponteiros seriam apreciados.

Edite 11 de abril: Eu tentei wget e ver um resultado semelhante (resposta trava). Eu suspeito que é um problema de configuração de rede.

Caso seja relevante, aqui estão algumas das configurações de porta para a caixa virtual.

==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
==> default: Forwarding ports...
    default: 80 => 8000 (adapter 1)
    default: 443 => 44300 (adapter 1)
    default: 3306 => 33060 (adapter 1)
    default: 5432 => 54320 (adapter 1)
    default: 22 => 2222 (adapter 1)

EDIT 12 de abril:

Então ... eu decidi destruir esta caixa vagabunda e começar de novo ... isso resolveu o problema.

Eu suspeito que mudei / quebrei algo ao longo dos últimos meses. Começar de novo, com as configurações da caixa de baunilha, corrigiu esse problema.

    

Answer 1

Talvez o nginx esteja configurado para fazer a resolução ip de solicitações recebidas e esteja demorando para resolver a conexão de entrada antes de realmente responder à solicitação.

Alguns ponteiros, no entanto, você vai querer verificar o seguinte em 192.168.10.10.

1. Verifique se os servidores de nomes estão corretos em /etc/resolv.conf
2. Se as configurações de resolução # 1 estiverem corretas para os servidores de nomes primários e secundários, verifique se 192.168.10.10 tem a capacidade de resolver hosts. (o nslookup simples para o google.com é um bom teste para isso, se o tempo limite ocorrer, então isso pode fazer parte do problema)
3. Verifique se o seu servidor nginx tem a capacidade de consultar servidores de nomes externamente ou internamente via firewall (porta 53 tcp / udp)
4. Procure as configurações possíveis do resolvedor nas opções de configuração do nginx e ou defina a configuração de tempo limite de resolução, quando aplicável, e reinicie o nginx.
5. Se ainda for um problema, tente adicionar o host da conexão de solicitação recebida em / etc / hosts em 192.168.10.10.

Deixe-me saber como isso funciona para você ..

Obrigado por postar.

    

Answer 2

Observação: você pode obter informações de tempo mais detalhadas usando time curl -vvv site1.dev/ .

Eu observei que a resposta do servidor contém Connection: keep-alive , o que significa que o servidor está configurado para usar HTTP keep-alive :

HTTP persistent connection, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using a single TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new connection for every single request/response pair. The newer HTTP/2 protocol uses the same idea and takes it further to allow multiple concurrent requests/responses to be multiplexed over a single connection.

O servidor está, portanto, mantendo a conexão aberta na expectativa de Atendendo a mais solicitações. Desta forma, um navegador pode usar a mesma conexão TCP para receber uma página HTML e solicitar imediatamente as imagens vinculadas sem a necessidade de estabelecer novas conexões.

A página man curl.1 especifica o parâmetro --no-keepalive :

Disables the use of keepalive messages on the TCP connection, as by default curl enables them.

Você também pode definir parâmetros semelhantes no módulo do servidor nginx ngx_http_core_module keepalive_timeout :

Syntax:   keepalive_timeout timeout [header_timeout];
Default:  keepalive_timeout 75s;
Context:  http, server, location

The first parameter sets a timeout during which a keep-alive client connection will stay open on the server side. The zero value disables keep-alive client connections. The optional second parameter sets a value in the “Keep-Alive: timeout=time” response header field. Two parameters may differ.

The “Keep-Alive: timeout=time” header field is recognized by Mozilla and Konqueror. MSIE closes keep-alive connections by itself in about 60 seconds.