web-dev-qa-db-ja.com

ChromeがOS Xの/ etc / hostsを無視しているのはなぜですか？

OS X 10.8.5とChrome 30。

127.0.0.1 youtube.comを/etc/hostsファイルに追加して、次の内容が含まれるようにしました。

# 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

コマンドtraceroute youtube.comを実行すると、期待した結果が得られます（youtube.comは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

ただし、Chromeでyoutube.comと入力すると、ブラウザが127.0.0.1との接続を確立せず、代わりにYouTubeの「通常の」IPアドレスを使用して接続を確立します。私はChrome youtube.comを127.0.0.1に解決すると期待していました。

Chromeシステムのプロキシ設定を使用するように設定されています。OSXで、[システム環境設定]> [ネットワーク]> [詳細...]> [プロキシ]に移動すると、[自動プロキシ検出]を選択しました。

Chrome /etc/hostsファイルを無視しているように見えるのはなぜですか？

macosnetworkinggoogle-chromedns
27
Jonathan

Hostsファイルにwww.youtube.comを追加してみてください。 youtube.comはwww.youtube.comに永続的にリダイレクトされるため、youtube.comに一度アクセスした限り、ブラウザはこの応答をキャッシュしてwww.youtube.comにリダイレクトします。このアドレスはホストファイルにないため、chromeは論理的に正しく解決します。

8
user2313067

Google Chromeはホストファイルを無視し、実際のDNSルックアップを実行します（他の人が何を考えていても、/etc/hostsはDNSの一部ではなく、DNSに使用されたものですprior）。 Google Chromeshouldはそれらのhostsファイルエントリを尊重しますが、そうではありません。hostsファイルはDNSの代替は、DNSサーバーが利用できない場合（ネットワーク接続を無効にした場合など）に読み取られます。

これをテストするには、「127.0.0.1 foobar.dev」をホストファイルに追加し、wiresharkを有効にしてネットワークインターフェースで監視します。 Chromeを開き、http://foobar.dev/アドレスバーに移動してください。 Wiresharkに次のようなDNSクエリが表示されます。

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

FWIW、Google DNSはfoobar.devに対して127.0.53.53を返します。

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

回避策は、古いChrome拡張機能である HostAdmin 拡張機能を使用することです。Chromeホストを使用します。ただし、新しいバージョンのChrome（> 38、apprently））はサポートしていません。

10
Karl Wilbur

次の方法でこの問題を修正しました：Chromeの詳細設定で[危険なサイトからあなたとあなたのデバイスを保護する]をオフにしてください。

Chromeの組み込みの「保護」には、ドメインを独自のDNSと直接照合して、「疑わしい」と見なされる特定のタイプのホストエントリ、または上書きされている存在するサイトのエントリをバイパスすることが含まれます。つまり、ほとんどのカスタムホストエントリは無視されます。特に、開発に使用される* .devおよび* .localエントリ。

これをオフにすると、問題は100％解決されました。これは私がローカル開発をしているときに私を何ヶ月も怒らせていました、そして私はどこにもリストされた答えを見つけることができませんでした、誰もがそれは起こり得ないと言い続けました。高度な設定での単純な切り替えでした。これがあなたにも役立つことを願っています、乾杯。

6
Joshua Jarman

hostsファイルが、開発に使用している.dev偽ドメインのmacOSでChrome）で機能しないと思って、この質問に遭遇しました。

実際にはそれが動作します、少なくともChrome 77。

問題はドメインが見つからないことではなく、 すべての.devが自動的にhttpsにリダイレクトされるようになりました ：

This site can't be reached - Chrome

ドメイン名をダブルクリックすると、原因を確認できます。

https

Googleが.devを解読したため、解決策として、上記のリンクは.testや.localhostなどの別のTLDに移行することを提案しています。

0
Benjamin

Localhostは、tcp/ipの内部アドレスである127.0.0.1アドレスの規則ですが、Chromeは/ etc/hostsを使用してアドレスを解決せず、DNSサーバーを使用していますしたがって、アドレスは/ etc/hostsからではなく、DNSサーバーから取得されます。/etc/hostsを使用している場合、アドレスを解決するには、wwwホスト名全体を保持する必要があります。

お役に立てれば。

0
Moises Najar