MENU

Windowsでhostsファイルを使ってDNS解決を手動上書きする方法｜設定手順・flushdns・トラブル対策

Windows

テスト環境の切り替えや一時的な障害切り分けで「このドメインは今だけこのIPへつないでほしい」と思う場面は珍しくありません。Windowsでは hosts ファイルを使えば、通常のDNSを経由せずに任意のドメイン名を任意のIPアドレスへ固定（名前解決の上書き）できます。本記事では具体的な手順、反映確認、陥りやすい落とし穴、運用上の注意点、PowerShellでの自動化までを丁寧に解説します。

目次

DNS解決を手動で上書きする最短手順（結論）

  1. 管理者権限でメモ帳（またはNotepad++等）を起動する。
  2. C:\Windows\System32\drivers\etc\hosts を開く。
  3. 末尾に IPアドレス[半角スペース]ドメイン名 を追記して保存する（拡張子は付けない）。
    例：192.168.1.1  example.com
  4. 管理者権限のコマンド プロンプトでDNSキャッシュを破棄：ipconfig /flushdns
  5. ブラウザーやアプリを再起動し、ping や Test-NetConnection で解決先IPを確認する。

これだけで多くのケースは即座に反映されます。以下では背景知識・検証のコツ・効かないときの原因と対処・安全に運用するためのポイントを詳しく解説します。

hostsファイルの基礎知識

hosts はOSの名前解決プロセスが最初に参照するローカルテーブルです。ここに書いた対応（IP ⇔ ホスト名）がある場合、通常のDNSサーバーへ問い合わせる前にその値が使われます。つまり、DNSサーバーの正規レコードがどうであっても、hostsの記述が勝つ（優先される）と理解してください。

  • ファイルパス：C:\Windows\System32\drivers\etc\hosts
  • 権限：編集には管理者権限が必要です。
  • 書式：IPアドレス[半角スペース1つ以上]ホスト名、行頭の # はコメント。
  • 拡張子：hosts（拡張子なし）。.txt を付けない。
  • 文字コード：既定のまま保存（BOMや文字コード変更は不具合の原因）。
  • 大文字・小文字：ホスト名は大小無視（Example.COM でも可）。
  • ワイルドカード：未対応（*.example.com は使えません）。必要なサブドメインを個別に列挙します。

日本語ドメイン（国際化ドメイン名）を指定したい場合は、Punycode（xn-- プレフィックス）で記述するのが確実です。

手順：hostsファイルの編集と保存

GUIで行う方法

  1. スタートメニューで「メモ帳」を検索し、右クリックして「管理者として実行」。
  2. メモ帳で ファイル > 開く を選択し、C:\Windows\System32\drivers\etc\ へ移動。
  3. 右下の「テキスト文書（*.txt）」を「すべてのファイル」に切り替え、hosts を選択して開く。
  4. 最終行に以下のように追記し、上書き保存する（拡張子は付けない）。# 2025-11-04 テスト用設定 192.168.1.1 example.com # 追加で別名も固定する場合 192.168.1.1 www.example.com

IPv6も併記する（トラブル予防）

アプリやAPIがIPv6を優先する設計のことがあります。確実に上書きしたい場合は、IPv4とIPv6をセットで書くのが安全です。

# v4とv6の両方を明示
192.0.2.10   app.example.com
2001:db8::10 app.example.com

複数ホスト名を同じIPへ

同じIPに別名を束ねる場合、スペース区切りで1行に並べるか、別行に同じIPを重ねます（可読性重視なら別行がおすすめ）。

# 1行で並べる例
192.168.50.5 repo.local repo repo.internal

# 行を分ける例（人に優しい）

192.168.50.5 repo.local
192.168.50.5 repo
192.168.50.5 repo.internal

反映を即時に有効化する：DNSキャッシュのクリア

Windowsは名前解決結果をキャッシュします。編集直後に反映しないときはキャッシュを破棄します。

コマンド プロンプト（管理者）

ipconfig /flushdns

PowerShell（管理者）

Clear-DnsClientCache

さらにブラウザーやアプリ側にも独自キャッシュがあるため、アプリの再起動やブラウザーのDNS・ソケットキャッシュのクリアも有効です。わからなければいったんアプリとOSを再起動するのが手っ取り早い対処です。

正しく上書きできたかを確認する方法（検証のコツ）

検証コマンドには「OSのリゾルバを使うもの」と「DNSサーバーへ直接問い合わせるもの」があり、見える世界が違います。hosts の効果を確実に見たいときは、OSの解決を通るコマンドで確認しましょう。

用途コマンドhostsの影響ポイント
OS経由の名前解決＋疎通確認ping example.com反映される表示されるIPが意図したIPか確認
TCPポート到達性確認Test-NetConnection example.com -Port 443反映されるPowerShell。HTTP/HTTPSの実接続可否まで追える
.NET経由の名前解決[System.Net.Dns]::GetHostAddresses("example.com")反映されるアプリ寄りの視点で確認できる
DNSサーバーへ直接問合せnslookup example.com反映されないDNSの実レコードを確認する用途。hostsの動作確認には不向き

HTTP/HTTPSの動作まで見たいときは、curl -v https://example.com/（Windows 10/11 は標準搭載）で、接続先IPやSNI、証明書名の一致まで確認しましょう。

「反映されない」「効かない」主な原因と対処

症状主な原因解決策
名前が引けない／意図したIPに解決しない拡張子 .txt が付いている／別名で保存されているファイル名を hosts（拡張子なし）に変更。必要ならエクスプローラーで「拡張子を表示」を有効化
解決先が想定外全角スペースやタブが混在、行頭が # でコメント扱いIPとホスト名の間は半角スペース1つ以上、# を外す
保存できない／保存したはずが戻っている管理者権限不足、セキュリティソフトの保護、読み取り専用属性エディタを「管理者として実行」。読み取り専用を解除。セキュリティ製品の「hosts保護」を一時無効化
編集したのにアプリだけ効かないアプリが独自のDNSキャッシュや独自リゾルバ（DoH/TRR等）を使用アプリ側キャッシュを削除・再起動。必要ならアプリのDoHを無効化。OS再起動も検討
ブラウザーのみ効かないブラウザーのDNSキャッシュ、ソケットキャッシュ、事前解決結果が残っているブラウザー再起動。内部キャッシュのクリア機能があれば実行
一部のアクセスだけ元のIPへ行くIPv6で到達、v4のみhostsに書いた／プロキシ・VPN経由で解決がサーバー側で行われる同じホスト名にv6の行も追加。プロキシ利用時はプロキシ側で解決される点に注意（HTTPプロキシは特に）
nslookupでは反映しないnslookupはDNSサーバーへ直接問合せするためhostsの検証は ping や Test-NetConnection などOS経由のコマンドで行う
別ユーザーで挙動が違うUACの仮想化やエディタが仮想ストアへ保存（まれ）hosts の実体パスを確認し、%LOCALAPPDATA%\VirtualStore 等に偽のコピーがないか点検
意図したIPへ解決するが接続できない宛先サーバーがダウン／ファイアウォール／証明書名の不一致（HTTPS）ping・Test-NetConnection -Port で疎通確認。HTTPSは証明書のCN/SANがドメインと一致するか確認
社内全体で影響が出た正式DNSと衝突する上書きが複数端末へ展開されてしまったhostsは一時用途に限定。恒常運用はDNSサーバー側でレコードを管理

運用上の重要ポイント（安全に使うための心得）

  • 衝突リスク：hostsに書いた内容が最優先されるため、正式DNSと食い違うと通信障害や接続先誤りを招きます。テスト用途・一時的用途に限定するのが鉄則。
  • 証明書（HTTPS/TLS）：IPだけ差し替えると、サーバーが提示する証明書名とリクエストのホスト名が一致せず、ブラウザーが警告を出します。該当ドメインの証明書を提示できるサーバーへ向けるか、検証の目的とリスクを理解して回避策（テストCAの信頼化など）を講じてください。
  • プロキシ／VPN：HTTPプロキシでは名前解決をプロキシ側が行うため、クライアントのhosts上書きが効かない場合があります。VPNでSplit-Tunnel構成の場合も経路と解決系が分岐します。
  • IPv6も考慮：上書きはv4だけで満足しがちですが、アプリがv6を優先して元の経路へ出ていくことがあります。v4/v6をセットで書くと事故が減ります。
  • 変更履歴はコメントで残す：# 2025-11-04 テスト用設定 のように目的・日付・担当を記入。撤去忘れを防止。
  • 大規模管理はDNSで：エントリー数が増えると整合・検証が破綻しやすい。恒常運用はDNSサーバーでCNAME/A/AAAA/レコード管理を。
  • セキュリティ：マルウェアは更新サイトやセキュリティサイトを遮断するためにhostsを改ざんすることがあります。定期的に差分監視・改ざん監視を行い、意図しない変更を検出しましょう。

具体例：よくあるユースケースと書き方

ステージング環境へ一時的に向け替える

# 2025-11-04 staging向け：2時間だけ使用
203.0.113.20 api.example.com
2001:db8:100::20 api.example.com

ループバックでローカルに閉じる（開発時）

# ローカルPC上の開発サーバーへ
127.0.0.1   dev.example.local
::1         dev.example.local

同一IPに複数のFQDNを割り当てる

# バーチャルホスト検証
192.168.10.30 blog.local shop.local portal.local

日本語ドメイン（Punycode）

# 「例え.テスト」をPunycodeで（例）
198.51.100.77 xn--r8jz45g.xn--zckzah

トラブル解決のための段階的チェックリスト

  1. hostsの書式を再確認：全角スペース／タブ／#の有無／拡張子なし。
  2. 権限と保存の実体を確認：エディタを管理者で開き、Get-Content C:\Windows\System32\drivers\etc\hosts で内容を再確認。
  3. キャッシュの破棄：ipconfig /flushdns または Clear-DnsClientCache。
  4. アプリ再起動：ブラウザーや開発ツールは特に独自キャッシュを持ちます。
  5. 検証方法を切替：nslookup ではなく ping / Test-NetConnection / curl -v。
  6. IPv6を含める：v4のみならv6行も追加。
  7. プロキシ／VPNの影響：プロキシ経由ならプロキシ側で解決。VPNの経路分岐も確認。
  8. DNS Clientサービスの再起動（必要時）：services.msc で「DNS Client（Dnscache）」を再起動。
  9. 最終手段：netsh int ip reset（IPスタックのリセット）。実施前に業務影響を要確認。

自動化：PowerShellで安全に追記・削除する

追記スクリプト（バックアップ付き／UTF-8 BOMなし）

# 実行は管理者PowerShellで
$HostPath = "C:\Windows\System32\drivers\etc\hosts"
$Backup   = "$HostPath.bak_{0:yyyyMMdd_HHmmss}" -f (Get-Date)
$IP       = "192.168.1.1"
$Name     = "example.com"

# 入力の簡易妥当性チェック

if (-not ($IP -match '^(\d{1,3}.){3}\d{1,3}$' -or $IP -match '^[0-9a-fA-F:]+$')) {
throw "IP形式が不正です：$IP"
}
if (-not ($Name -match '^[A-Za-z0-9.-]+$')) {
throw "ホスト名に使用できない文字が含まれます：$Name"
}

# バックアップ

Copy-Item $HostPath $Backup -Force

# 既存の同名行を削除してから追記（重複回避）

$lines = Get-Content $HostPath
$filtered = $lines | Where-Object {$_ -notmatch "^\s*#"} | Where-Object {$_ -notmatch "\s$Name(\s|$)"}
$comments = $lines | Where-Object {$_ -match "^\s*#"}
$final = @()
$final += $comments
$final += $filtered | Where-Object {$_ -notmatch "^\s*#"}
$final += "# $(Get-Date -Format 'yyyy-MM-dd HH:mm') 追加"
$final += "$IP $Name"

# UTF8（BOMなし）で上書き保存

$Utf8NoBom = New-Object System.Text.UTF8Encoding($false)
[System.IO.File]::WriteAllLines($HostPath, $final, $Utf8NoBom)

Write-Host "完了：$HostPath に $IP $Name を追加。バックアップ：$Backup"

削除スクリプト（指定ホスト名の行を消す）

# 管理者PowerShellで
$HostPath = "C:\Windows\System32\drivers\etc\hosts"
$Backup   = "$HostPath.bak_{0:yyyyMMdd_HHmmss}" -f (Get-Date)
$Name     = "example.com"

Copy-Item $HostPath $Backup -Force
$lines = Get-Content $HostPath
$kept  = $lines | Where-Object { $_ -match "^\s*#" -or $_ -notmatch "\s$Name(\s|$)" }
$Utf8NoBom = New-Object System.Text.UTF8Encoding($false)
[System.IO.File]::WriteAllLines($HostPath, $kept, $Utf8NoBom)
Write-Host "削除完了：$Name のエントリーを除去。バックアップ：$Backup"

CI/CDや端末管理（Intune/SCCM等）で一時的に配布する場合も、バックアップと巻き戻し手順を同梱しておくと安全です。

HTTPSで注意すべき「SNIと証明書」

HTTP/1.1以降では「Hostヘッダー」、TLSでは「SNI（Server Name Indication）」で仮想ホストを切り替えます。hosts で向け先IPだけを差し替えても、

  • サーバー側が当該ドメインの証明書を提示できない
  • リバースプロキシ／ロードバランサーでSNIやHostヘッダーが到達先を決めている

といった理由で接続エラー（証明書のCN/SAN不一致や404/503）になることがあります。検証対象のサーバーが正しい証明書を返すか、あるいはテスト用証明書を信頼させるなど、アプリ層の要件まで確認してから上書きしてください。curl -v https://example.com/ で提示証明書のサブジェクト名とSNIの関係を確認するのが手早いです。

WSL・Docker・仮想環境の落とし穴

  • WSL（Linux側）：WSLはLinux側の /etc/hosts を見ます。WindowsアプリはWindowsのhosts、WSLのアプリはWSL側の/etc/hostsでそれぞれ制御される点に注意。
  • Docker：コンテナはコンテナ内の/etc/hostsを参照。ホストOSのhostsは直接影響しません（ポートフォワードの設定で間接影響はあり）。
  • 仮想マシン：ゲストOSごとに別ファイル。NAT/ブリッジのネットワーク方式によって疎通も変わります。

「最後まで解決しない」場合の復旧フロー

  1. hosts全行をコメントアウト（行頭に#）、OSとアプリを再起動して元に戻るか確認。
  2. DNSサーバー／DHCP／ファイアウォール／プロキシ設定を点検し、ネットワーク側の問題を切り分け。
  3. 必要であれば「DNS Client（Dnscache）」サービス再起動や、netsh int ip reset でIPスタックの再初期化を検討。

このフローで多くの「効かない」問題は切り分け可能です。設定の変更履歴と目的をコメントに残し、撤去日も記載しておくと運用事故を大きく減らせます。

よくある質問（FAQ）

Q. エントリーの順序は影響しますか？

A. 一般的には上から評価され、最初に一致した行が利用されます。ただしアプリの呼び出し方法（IPv4/IPv6の優先度、getaddrinfo のフラグ等）によっては結果の並びや使われ方が異なるため、同じホスト名に複数のIPを並べないほうが意図を明確にできます。

Q. サブドメインをまとめて上書きできますか？（ワイルドカード）

A. できません。*.example.com のような記法は非対応です。必要なサブドメインを列挙してください。

Q. 会社のセキュリティ製品が保存をブロックします

A. 多くのエンドポイント保護製品はhosts改ざんを検知・遮断します。一時的に例外設定を入れるか、ネットワーク管理者に運用ポリシーを確認してください。

Q. Windows 10と11で手順は違いますか？

A. 手順・パスは同一です。UIの見た目が多少違う程度で、概念とコマンドは共通です。

まとめ

hosts を使ったDNS上書きは、Windowsで最も手軽に「ドメイン名の行き先」を変える方法です。編集は管理者権限で、書式は「IP 半角スペース ホスト名」。反映しないときはキャッシュを削除し、ping や Test-NetConnection で検証します。効かない原因の多くは書式・権限・キャッシュ・プロキシ／IPv6／アプリの独自解決に集約されます。恒常運用はDNSで、hostsは一時利用が基本。コメントで履歴を残し、撤去漏れを防ぎましょう。

付録：チェックシート（貼って使える早見表）

項目確認ポイント
場所C:\Windows\System32\drivers\etc\hosts
権限エディタを「管理者として実行」
書式IP[半角スペース]ホスト名、#はコメント、ワイルドカード不可
保存拡張子なし、既定の文字コード、読み取り専用解除
キャッシュipconfig /flushdns または Clear-DnsClientCache
検証ping / Test-NetConnection / curl -v（nslookupはDNS直問合せ）
IPv6必要に応じてAAAA相当のIPv6行も追加
プロキシHTTPプロキシ下ではプロキシが名前解決する可能性
履歴コメントに日付・目的・担当を明記

実践レシピ：よく使うコマンド集

# DNSキャッシュを表示
ipconfig /displaydns

# DNSキャッシュをクリア（cmd）

ipconfig /flushdns

# DNSキャッシュをクリア（PowerShell）

Clear-DnsClientCache

# OSリゾルバ経由で解決確認

ping example.com

# TCP 443の到達性を確認（SYNまで）

Test-NetConnection example.com -Port 443

# 証明書名やSNIも確認（冗長出力）

curl -v [https://example.com/](https://example.com/)

この設定で守れる／守れないもの

  • 守れる：クライアントPC上でOSの名前解決を使うアプリの接続先IP。ブラウザー、curl、一般的なCLI/GUIアプリ。
  • 守れない（場合がある）：独自DoH/TRRを使うアプリ、HTTPプロキシ越しの通信、コンテナ／WSL内部、リモート環境でのサーバー側リダイレクト。

「hostsで直したのに一部だけ効かない」は珍しくありません。通信経路（ローカル解決か、プロキシ解決か）と、アプリの解決方法（OS依存か、独自DoHか）を分けて考えると早く収束します。

おわりに

WindowsでのDNS上書きは、トラブルシューティング・検証・ロールバックを素早く回すための即効薬です。正しい手順と検証の作法、上手な撤去の運用を押さえておけば、現場の時間を大きく節約できます。本記事の手順とチェックリストをチームの標準ノートに貼り付けて、迷いなく実施できる体制を整えておきましょう。

Windows
DNS PowerShell トラブルシューティング Windows ネットワーク Hostsファイル

コメント

コメントする

目次