Por que o Chrome está ignorando o / etc / hosts no OS X?

27

Estou usando o OS X 10.8.5 e o Chrome 30.

Eu adicionei 127.0.0.1 youtube.comao meu /etc/hostsarquivo para que agora ele contenha:

# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1       localhost
255.255.255.255 broadcasthost
::1             localhost
fe80::1%lo0     localhost

127.0.0.1       youtube.com

Quando executo o comando traceroute youtube.com, recebo os resultados esperados (youtube.com é resolvido para 127.0.0.1):

traceroute to youtube.com (127.0.0.1), 64 hops max, 52 byte packets
1  localhost (127.0.0.1)  0.272 ms  0.118 ms  0.063 ms

No entanto, quando digito youtube.com no Chrome, meu navegador não estabelece uma conexão com o 127.0.0.1, mas com o endereço IP "normal" do YouTube. Eu esperava que o Chrome resolvesse o youtube.com para 127.0.0.1.

Eu tenho o Chrome configurado para usar as configurações de proxy do meu sistema. No OS X, quando vou para Preferências do sistema> Rede> "Avançado ..."> Proxies, selecionei "Descoberta automática de proxy".

Por que o Chrome aparentemente está ignorando meu /etc/hostsarquivo?

— Jonathan
fonte

4

Tem certeza de que está tentando resolver o youtube.com e não o www.youtube.com? Também é possível que o youtube.com tenha um redirecionamento 301 que é armazenado em cache pelo navegador para que nem tente entrar em contato com youtube.com (não no meu computador para verificar).

— user2313067

@ user2313067 Obrigado! Eu revisei o / etc / hosts para também ter uma linha para www.youtube.com resolvendo para 127.0.0.1 e isso fez o truque.

— 22413 Jonathan

@ user2313067 Você pode postar seu comentário como resposta.

— Blacklight Shining

2

Possível duplicata de Por que o Chromium está ignorando / etc / hosts e dnsmasq?

— Scott

você provavelmente está usando uma VPN ou uma extensão do Chrome que altera sua conexão de alguma forma

— user1735921 16/12

8

Tente adicionar www.youtube.comao seu arquivo hosts. youtube.comé redirecionado permanentemente para www.youtube.com, desde que você tenha visitado youtube.comuma vez, seu navegador armazena em cache essa resposta e o redireciona para www.youtube.com. Esse endereço não está no arquivo do seu host, portanto, o chrome o resolve logicamente corretamente.

— user2313067
fonte

11

Faça isso para limpar seus redirecionamentos superuser.com/questions/304589/... ou simplesmente usar o modo incógnito para o desenvolvimento

— james.c.funk

11

Adicionar wwwnão funciona para mim. Mesmo depois de limpar todos os dados do navegador e liberar o DNS. Talvez essa seja uma medida anti-phishing incorporada ao Chrome?

— F1lt3r

adicionando nu e www. versões no arquivo hosts funcionaram para mim. Também desabilitei o chrome: // flags / # enable-new-preconnect no Chrome

— LyK

10

O Google Chrome ignora o arquivo de hosts e faz pesquisas de DNS reais (apesar do que os outros possam pensar, /etc/hostsnão faz parte do DNS, é o que foi usado antes do DNS). Embora o Google Chrome deva honrar essas entradas de arquivo de hosts, isso não ocorre. O arquivo hosts, sendo uma alternativa ao DNS, será lido quando nenhum servidor DNS estiver disponível (como se você desativasse sua conexão de rede).

Você pode testar isso adicionando "127.0.0.1 foobar.dev" ao arquivo de hosts, ativando o wireshark e assistindo na sua interface de rede. Abra o Chrome e coloque http://foobar.dev/na sua barra de endereços e pronto . Você verá uma consulta DNS no Wireshark, algo como:

2   1.668727000 192.168.32.104  8.8.8.8 DNS 75  Standard query 0x663a  A foobar.dev

FWIW, o DNS do Google retorna 127.0.53.53 para foobar.dev.

3   1.706484000 8.8.8.8 192.168.32.104  DNS 91  Standard query response 0x663a  A 127.0.53.53

Uma solução alternativa seria usar o HostAdmin, uma extensão mais antiga do Chrome que faz o Chrome usar os hosts. No entanto, versões mais recentes do Chrome (> 38, adequadamente) não são mais compatíveis.

— Karl Wilbur
fonte

O Chrome não está realmente ignorando o /etc/hostsarquivo no OS X. Pelo menos não o Chrome v43 no OS X 10.10.3.

— quer

O Wireshark conta uma história diferente.

— Karl Wilbur

11

O fato de o Chrome também consultar o DNS do Google pode não significar / etc / hosts é ignorado. Isso pode ser simplesmente para fins de otimização / registro / espionagem. Uso o arquivo / etc / hosts com muita frequência no OS X e não tenho problemas com o Chrome.

— Petr Peller

3

Quando meu arquivo host possui '127.0.0.1 foo.dev' e o Chrome resolve magicamente foo.dev para 127.0.53.53, ele está IGNORANDO o arquivo de meus hosts.

— Karl Wilbur

11

Sim, mas com wi-fi no, Chrome deve usar o arquivo hosts primeiro antes de fazer uma pesquisa de DNS. Isso não. Esse é o problema.

— Karl Wilbur

5

Corrigi esse problema: Desative "Proteger você e seu dispositivo contra sites perigosos" nas Preferências avançadas do Chrome.

A "proteção" incorporada do Chrome inclui a verificação direta de um domínio em relação ao seu próprio DNS e o desvio de certos tipos de entradas de host que considera "suspeitas" ou entradas de sites que estão sendo substituídos, o que significa que a maioria das entradas personalizadas de host são ignoradas. Especialmente as entradas * .dev e * .local usadas para desenvolvimento.

Desativar isso resolveu o problema 100% do tempo para mim. Isso me deixou louco por meses durante o desenvolvimento local e eu não consegui encontrar a resposta listada em nenhum lugar, todo mundo ficava dizendo que isso não poderia estar acontecendo. Acontece que foi uma simples alternância nas configurações avançadas. Espero que isso ajude você também, felicidades.

— Joshua Jarman
fonte

Obrigado, eu sabia que funcionava na semana passada, alterei as opções do Chrome para o padrão há alguns dias e não funcionou mais. Funcionou!

— 98percentmonkey 31/07

Obrigado, eu sabia que funcionava na semana passada, alterei as opções do Chrome para o padrão há alguns dias e não funcionou mais. Funcionou! É chamado de "Navegação segura" em versões mais recentes

— 98percentmonkey

0

Localhost é uma convenção para o endereço 127.0.0.1 que é um endereço interno para tcp / ip; no entanto, o Chrome não está usando os / etc / hosts para resolver o endereço, está usando um servidor DNS; portanto, nenhum endereço não vem do seu / etc / hosts, mas a partir de um servidor DNS, se estiver usando o / etc / hosts, ele deverá conter os nomes de host www inteiros para resolver qualquer endereço.

Espero que isto ajude.

— Moises Najar
fonte

11

-1. /etc/hostssubstitui todos os servidores DNS. Sim, se você estiver usando apenas /etc/hosts , ele deverá conter todos os nomes de domínio, mas a maioria das configurações também inclui servidores DNS. Se o Chrome simplesmente solicitar que o sistema operacional resolva o nome de domínio, como deveria , /etc/hostsserá verificado primeiro e, se não contiver uma entrada, uma consulta DNS será enviada.

— Blacklight Shining

/etc/hosts deve substituir e solicitação de DNS, mas esse não é o caso do Google Chrome. Ele realiza suas próprias pesquisas de DNS, apesar do que pode estar no arquivo hosts. Isso é facilmente demonstrável. Isso é especificamente um problema para o desenvolvimento local usando o .devTLD.

— Karl Wilbur

0

Eu me deparei com essa pergunta pensando que o hostsarquivo não funcionava no Chrome para macOS para os .devdomínios falsos que eu uso no desenvolvimento.

Realmente ele faz o trabalho, pelo menos no Chrome 77.

O problema não é que o domínio não foi encontrado, mas que todos os .dev agora são automaticamente redirecionados para https :

Se você clicar duas vezes no nome do domínio, poderá ver o culpado:

Agora que o Google quebrou o nosso .dev, como solução, o link acima sugere a mudança para outro TLD para desenvolvimento, como .testou .localhost.

— Benjamin
fonte