状況の説明
Chromeを開いてURLを入力すると、次のエラーが表示されます：
This site can't be reached.
example.com's server IP address could not be found.
DNS_PROBE_FINISHED_NXDOMAIN
ドメインが解決できない状態です。主な原因は4つ：古いDNSキャッシュ、壊れたDNSサーバー、ドメインが本当に存在しない、または不正な/etc/hostsエントリが上書きしている可能性があります。どれが原因かを特定していきましょう。
簡易診断
NXDOMAINは*Non-Existent Domain（存在しないドメイン）*の略で、DNSリゾルバーが「このドメインは存在しない」という明確な応答を返した状態です。まず、問題がサイト側ではなく自分の環境にあるかを確認します：
# Linux / macOS
nslookup example.com 8.8.8.8
# Windows (PowerShell)
Resolve-DnsName example.com -Server 8.8.8.8
これで正常に解決できるのにブラウザが失敗する場合、問題はローカル側――システムのDNSキャッシュまたは設定にあります。nslookupでもNXDOMAINが返る場合は、ドメイン自体がダウンしているか、DNSサーバーが誤った応答を返している可能性があります。
簡単な確認方法として、スマートフォンのモバイルデータに切り替えて同じURLを試してみてください。それで表示されるなら、問題はあなたのマシンまたはローカルネットワーク側にあり、サイト自体ではありません。
修正1 — DNSキャッシュをフラッシュする
古いキャッシュが最も一般的な原因です。DNSレコードにはTTL（生存時間）があり、通常300〜86400秒です。システムが古いNXDOMAIN応答をキャッシュしている場合、TTLが切れるか手動でフラッシュするまでその誤った応答を返し続けます。
Windows
ipconfig /flushdns
macOS
# macOS 12以降（Monterey以降）
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
Linux（systemd-resolved）
sudo systemd-resolve --flush-caches
# 確認
sudo systemd-resolve --statistics | grep "Current Cache Size"
Chrome内部DNSキャッシュ
ChromeはOSとは完全に独立した独自のDNSキャッシュを持っています。新しいタブを開いて以下にアクセスしてください：
chrome://net-internals/#dns
Clear host cacheをクリックします。次にchrome://net-internals/#socketsに移動してFlush socket poolsをクリックします。両方の手順が必要です――ソケットのフラッシュを省略すると、Chromeが固まったままになることがあります。
修正2 — 信頼できるDNSサーバーに切り替える
ISPのDNSはクエリをドロップしたり、誤った応答を返したり、単純に遅い場合があります。Cloudflare（1.1.1.1）またはGoogle（8.8.8.8）に切り替えると2分で完了し、多くの場合すぐに問題が解決します。
Windows
# まずアダプター名を確認
Get-NetAdapter
# DNSを設定（"Wi-Fi"はご自身のアダプター名に置き換えてください）
Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses ("1.1.1.1", "8.8.8.8")
macOS
システム設定 → ネットワーク → 使用中の接続 → 詳細 → DNS → 1.1.1.1と8.8.8.8を追加し、古いISPのエントリを削除します。
Linux（NetworkManager）
# 現在の接続名を確認
nmcli connection show
# DNSを設定
nmcli connection modify "Your-Connection-Name" ipv4.dns "1.1.1.1 8.8.8.8"
nmcli connection up "Your-Connection-Name"
Linux（/etc/resolv.conf）
sudo nano /etc/resolv.conf
# nameseverの行を追加または置き換え：
nameserver 1.1.1.1
nameserver 8.8.8.8
systemd-resolvedを実行しているシステムでは、resolv.confはシンボリックリンクのため編集が反映されません。代わりに/etc/systemd/resolved.confを編集し、sudo systemctl restart systemd-resolvedを実行してください。
修正3 — hostsファイルを確認する
hostsファイルはDNSを完全に上書きします。このファイルに問題のあるエントリがある場合、DNSをいくらフラッシュしても意味がありません。開発環境のマシンは特にこの問題が起きやすく、Dockerプロジェクト、Laravel Valetなどのツール、ローカルSSL設定などがこのファイルにエントリを追加することがあります。
Windows
notepad C:\Windows\System32\drivers\etc\hosts
macOS / Linux
cat /etc/hosts
アクセスしようとしているドメインを参照している行がないか確認してください。以下のようなエントリがあるとブロックされます：
0.0.0.0 example.com
127.0.0.1 example.com
問題のある行の先頭に#を追加してコメントアウトし、ファイルを保存してからDNSを再度フラッシュしてください。
修正4 — DHCPリースを更新する
ルーターはDHCP経由でDNSサーバーのアドレスを配布します。そのリースが古くなるかルーターが誤ったアドレスを送信すると、システムが機能しないDNSサーバーに問い合わせることになります。
Windows
ipconfig /release
ipconfig /renew
macOS / Linux
# ネットワークインターフェースを無効にして再度有効にする
sudo ifconfig en0 down && sudo ifconfig en0 up
# またはNetworkManager経由
nmcli networking off && nmcli networking on
修正5 — VPNまたはプロキシを確認する
VPNクライアントは独自のDNSサーバーを設定します。VPNが半接続状態や誤作動している場合、DNSクエリはエラーなしで静かに失敗し、すべてのドメインがNXDOMAINになります。VPNを切断してURLをテストし、再接続してみてください。VPNなしで動作する場合、問題はシステムではなくVPNのDNS設定にあります。
プロキシの問題の場合：Chromeで設定 → システム → コンピューターのプロキシ設定を開くに移動します。Windowsではインターネットのプロパティ → 接続 → LANの設定に移動します。以前の職場環境などから残った不要なプロキシエントリが設定されていないか確認してください――意外とよくある原因です。
確認方法
ブラウザでテストする前に、システムレベルでDNS解決が正常に動作しているか確認します：
# ドメインが解決できるか確認
nslookup example.com
# またはdigを使用（Linux/macOS）
dig example.com +short
# DNS解決の完全なパスをトレース
dig example.com +trace
IPアドレスが返ってくるはずです。DNSルックアップは成功するのにブラウザがNXDOMAINを表示する場合は、Ctrl+Shift+R（MacはCmd+Shift+R）でハード更新してブラウザキャッシュを回避してください。
上記の方法がすべて効かない場合
この段階では、ドメイン自体が存在しないか有効期限切れの可能性があります。有効なDNSレコードがあるか確認してみてください：
# ドメインにNSレコードがあるか確認
dig NS example.com @8.8.8.8
# WHOISで登録状況を確認
whois example.com
NSレコードがなく、WHOISで未登録または有効期限切れと表示される場合、それはあなたの問題ではありません――そのサイトは単純に存在しなくなっています。
予防策
マシンごとではなく、ルーターレベルで1.1.1.1と8.8.8.8を設定しましょう。ネットワーク上のすべてのデバイスが自動的に恩恵を受け、新しいデバイスが追加されるたびに同じ修正を繰り返す必要がなくなります。
固定IP、カスタムサブネット、またはローカルDNS設定を扱っている場合、ToolCraftのSubnet CalculatorはCIDR範囲の確認やDNSサーバーIPが正しいサブネット内にあるかの検証に役立ちます――この方法で設定ミスを発見したことが実際にあります。