Início / server / Perguntas / 1092950
Accepted
Bob
Asked: 2022-02-08 10:28:44 +0800 CST

Meu navegador não exibirá http://[sub.]example.com

  • 772

Quando vou http://sub.example.comno meu navegador, recebo uma mensagem de "conexão recusada" ou um erro de "certificado inválido" , mas nem quero me conectar por https.

Até onde sei:

  • O servidor web está configurado corretamente parasub.example.com
  • A porta TCP 80 é aberta nos grupos de firewall/segurança
  • HTTP simples e não HTTPS é usado na URL
  • o registro DNS para sub.example.comapontar para o endereço IP correto do servidor web
  • o servidor web foi reiniciado com nova configuração
  • os logs não mostram a inicialização ou quaisquer outros erros

Como posso depurar e qual é o problema?

web-server ssl nginx apache-2.4 hsts

1 respostas

  1. Best Answer

    A primeira coisa a saber é que os navegadores modernos podem não ser a melhor ferramenta para depurar problemas como esses. O navegador pode até ser a causa deles, pois o servidor pode ser configurado completamente corretamente e o problema pode ser 100% do lado do cliente.

    Conteúdo:

    • teste (com curle navegador anônimo/anônimo)
    • ambos os testes exibem o conteúdo esperado
    • curlfaz, mas a janela privada do navegador não exibe o conteúdo correto
    • nenhum teste exibe o conteúdo esperado

    testando

    Tente não apenas testar com o FQDN, http://sub.example.commas use uma URL mais completa, como http://sub.example.com/some-page.html. Quando você sabe que está atrás de um proxy, a adição de parâmetros adicionais geralmente ignora o conteúdo em cache, ou seja, adiciona e incrementa um contador comohttp://sub.example.com/some-page.html?test=3

    • teste de uma janela do navegador "Privado/Incógnito".
      Isso reduz as chances de tirar conclusões incorretas com base em objetos armazenados em cache.

    • teste a partir de uma linha de comando (em um servidor de teste) com, por exemplo , curl -vv http://sub.example.com/some-page.htmlou use telnete emule uma solicitação da web com

      telnet sub.example.com 80

      GET /some-page.html HTTP/1.1
      Host: sub.example.com

    Coisas para procurar na curlsaída:

    • As configurações de proxy são definitivamente um sinal de perigo e um obstáculo real ao depurar problemas do servidor. Os servidores proxy podem armazenar em cache (registros DNS e conteúdo da Web), restringir seu acesso e até substituir certificados TLS.

      curl -vv http://sub.example.com/some-page.html
* Uses proxy env variable no_proxy == 'localhost,127.0.0.1,.corp.example.net'
* Uses proxy env variable http_proxy == 'http://[user]:[pass]@proxy.corp.example.net:8080/'
*   Trying 10.2.0.80:8080...
           ^^^ Danger - Proxy server

    • Teste de um sistema (teste) que não dependa de um servidor proxy se você quiser testar corretamente a configuração de um servidor web da Internet. Normalmente, não tenho sistemas de teste que ofereçam suporte a um navegador completo, mas geralmente consigo gerenciar um sistema que executará comandos curl a partir de uma linha de comando.

      curl -vv http://sub.example.com/some-page.html
* About to connect() to sub.example.com port 80 (#0)
*   Trying 192.168.2.119...
* Connected to sub.example.com (192.168.2.119) port 80 (#0)
                                ^^^ CHECK is this the correct IP-address 
                                    of your webserver?
> GET /some-page.html HTTP/1.1
> User-Agent: curl/7.29.0
> Host: sub.example.com
> Accept: */*

    Lá você observa que uma conexão é estabelecida com sucesso para o endereço IP e porta corretos do servidor web. O > marcador precede os cabeçalhos de solicitação feitos por curl.

    Os cabeçalhos de resposta do servidor são marcados com um < marcador e, após uma linha vazia, o corpo da resposta é enviado pelo servidor:

    < HTTP/1.1 302 Found
  |         ^^^ The server HTTP STATUS response code 
   `^^ the HTTP protocol version

< Date: Mon, 07 Feb 2022 13:58:11 GMT
< Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.4.16
< Location: https://sub.example.com/some-page.html
< Content-Length: 216
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
...

    Após o primeiro cabeçalho de protocolo HTTP/1.1vem o código de status HTTP que o servidor gera. Lá uma 2xxresposta significa alguma forma de sucesso, 3xxas respostas são redirecionamentos (vistos aqui) 4xxe 5xxsão erros.

    Dos outros cabeçalhos que o servidor envia Location:, neste exemplo indica o destino de uma resposta de redirecionamento.

    ambos os testes exibem o conteúdo esperado

    Conclusão: O servidor web está configurado corretamente e o problema está relacionado ao navegador.

    A causa mais provável : pode ter havido um redirecionamento permanente configurado antes que a configuração do servidor da Web fosse alterada e os redirecionamentos permanentes (301) sejam armazenados em cache pelos navegadores . Bastante comuns são redirecionamentos quebrados em cache ou redirecionamentos em cache para https e nenhum certificado e site https para sub.example.comestá configurado ainda.

    Resolução 1: limpe o cache do navegador e o site deve carregar conforme o esperado.
    Resolução 2: obtenha um certificado SSL para sub.example.com e habilite o TLS.

    Causa 2: Não é exatamente a mesma causa raiz, mas causa e efeito efetivamente semelhantes a um redirecionamento em cache para https, uma política HTTP Strict Transport Security (HSTS) definida pelo example.comdomínio também é aplicável a todos os (novos) subdomínios de exemplo. com. Qualquer navegador razoavelmente moderno armazena e respeita as políticas HSTS e se recusará a se conectar via http simples à porta 80 e reescreverá silenciosamente a http://sub.example.comURL https://sub.example.come tentará se conectar à porta 443 com TLS.

    Resolução: obtenha um certificado SSL para sub.example.com e ative o TLS.
    A limpeza do cache do navegador HSTS pode funcionar temporariamente, mas isso só é eficaz quando você também remove a política HSTS de inclusão de subdomínios de example.com, o que não é recomendado.

    curlfaz, mas a janela privada do navegador não exibe o conteúdo correto

    Conclusão: O servidor web está configurado corretamente e o problema está relacionado ao navegador ou cliente.

    Causa 1: Não é exatamente a mesma causa raiz, mas causa e efeito efetivamente semelhantes a uma política de HTTP Strict Transport Security (HSTS) em cache é um domínio na lista de pré-carregamento de HSTS. Mas onde as políticas HSTS armazenadas em cache não devem ser respeitadas em janelas "Privadas/Incógnitas", a lista de pré-carregamento HSTS sempre deve ser aplicada, mesmo em janelas privadas/anônimas.

    Consulte estas perguntas e respostas para obter uma visão geral sobre como determinar se seu domínio ou seu TLD está na lista de pré-carregamento HSTS:
    Lista de domínios de primeiro nível (TLDs) que exigem conexões HTTPS, como .dev

    Resolução: obtenha um certificado SSL para sub.example.com e ative o TLS.

    Causa 2: embora os registros DNS estejam configurados corretamente, o resolvedor do cliente, a área de trabalho em que seu navegador é executado, pode apontar para um endereço IP diferente. Verifique com, por exemplo nslookup, digo que o servidor de nomes do cliente resolve e não esqueça que uma entrada de arquivo hosts para sub.example.com substituirá o DNS.

    Resolução: remova a entrada do arquivo hosts para sub.example.com ou investigue mais a discrepância de DNS.

    nenhum teste exibe o conteúdo esperado

    Conclusão: O problema é do lado do servidor, não do lado do cliente.

    Sem resposta

    Consulte O que causa a mensagem 'Conexão recusada'? quando parece que o servidor web não responde na porta 80.

    Resposta de redirecionamento

    Quando o servidor da web responder, dê uma olhada nessa resposta:

    < HTTP/1.1 302 Found
< Date: Mon, 07 Feb 2022 13:58:11 GMT
< Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.4.16
< Location: https://sub.example.com/some-page.html
< Content-Length: 216
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
...

    Essa é uma resposta bastante típica para um servidor da Web configurado para redirecionar HTTP simples para HTTPS.

    O 302 Foundcódigo de status no primeiro cabeçalho é indicativo de um redirecionamento temporário. Para um redirecionamento permanente, seria um 301 Moved Permanentlycabeçalho de status http.

    O Location:cabeçalho mostra para onde o cliente é redirecionado.

    Causa: quando não definido na configuração do servidor web, é muito comum que aplicativos web gerem redirecionamentos para https ou para um domínio totalmente diferente.
    Em servidores web Apache (que os permitem) um .htaccessarquivo também pode ser a fonte de um redirecionamento.

    Resolução: ajuste ou remova o redirecionamento ou garanta que o redirecionamento se torne válido e algo responda no destino do redirecionamento.
    Frequentemente: obtenha esse certificado SSL e ative o TLS!

    Causa: muitas vezes o destino do redirecionamento está quebrado, verifique se há erros de digitação sutis lá também, vi faltando /'s para redirecionar para sub.example.comsome-page.htmle parâmetros usados ​​incorretamente redirecionando para http://some-page.html, ou http://wwww.example.com/http://sub.example.com/some-page.htmlsimilares.
    Além disso, teste os loops fazendo uma solicitação para os Location:vários níveis de redirecionamentos geralmente indicando uma configuração quebrada e remova o loop.

    Conteúdo de outro site

    Quando você vê o conteúdo de um site diferente que você hospeda e não o conteúdo para, sub.example.comesteja ciente de que a maioria dos servidores da Web exibirá o conteúdo de um site padrão quando não puder corresponder um nome de host a um site específico.

    Resolução: verifique novamente sua configuração quanto a erros de digitação e confirme se o servidor web foi reiniciado com a configuração atualizada.

    • 20

relate perguntas