hostsファイルにIPを書いたのにnslookupで名前解決できない原因と対処法｜DNSとhostsの違いを徹底解説

hostsファイルに宛先ホストのIPを追記したのに、nslookupを実行すると「名前解決できない」「IPが返らない」と表示される――この現象は、設定ミスではなく“仕様”で起きることが多いです。本記事では原因を仕組みから整理し、目的別に正しい確認方法と、DNSとして解決させるための具体策をまとめます。

まず結論：nslookupはhostsファイルを参照しない

nslookupは、端末の「hostsを含むOSの名前解決」を確認するためのコマンドではありません。DNSサーバーへ直接問い合わせる“DNS検査ツール”です。そのため、DNSサーバーにレコードが存在しない（またはDNS参照先を外している）状態でnslookupが失敗するのは正常動作です。

観点	hostsによるローカル名前解決	nslookupによるDNS問い合わせ
参照するもの	hosts、OSのDNSキャッシュ、DNSサーバーなど（OSの名前解決順序に従う）	DNSサーバーのみ（指定サーバーへDNSプロトコルで問い合わせ）
DNSサーバーを外した場合	hostsに書いてあれば解決できる可能性が高い	行き先がない/レコードがないので解決できない（正常）
何が分かるか	その端末で通信に使われる名前解決が成立しているか	DNSサーバーにレコードがあり、DNS応答として返るか

ここが混ざると、「hostsに書いたのにnslookupで引けない＝おかしい」と感じてしまいます。実際は見ているレイヤーが違うだけなので、目的に合わせてコマンドを使い分けるのが最短です。

よくある症状：nslookupで出るエラーは「DNS側の問題」を示している

DNS参照先を外している、またはDNSにレコードがない状態でnslookupを使うと、たとえば次のような表示になりがちです（文言は環境で変わります）。

*** Can't find app01.example.local: Non-existent domain

DNS request timed out.
timeout was 2 seconds.

*** Default servers are not available

これらは「hostsが悪い」という意味ではなく、DNS問い合わせとしては解決できないことを表しています。hostsを確認したいのにnslookupを使うと、正しく動いているのに“失敗に見える”ため、切り分けが遠回りになります。

なぜズレるのか：OSの名前解決とDNS問い合わせは別物

イメージすると理解が早いです。

（一般的なアプリの名前解決）
アプリ → OSの名前解決API → hosts / キャッシュ / DNS など → 返ってきたIPで通信

（nslookup）
nslookup → DNSサーバーへ直接問い合わせ → DNS応答（A/AAAA/SRV等）を表示

多くのアプリはOSの名前解決APIを使うため、OSが参照するhostsの影響を受けます。一方でnslookupは「DNSプロトコルでの応答確認」をする道具なので、hostsを見ないのは自然な設計です。

目的別：正しい確認コマンドの選び方

最初に「何を確認したいか」を決めると迷いません。現場でありがちなパターンを、コマンドと一緒に整理します。

確認したいこと	推奨コマンド	分かること	注意点
hostsを含む“その端末の”名前解決で通信できるか	`ping ホスト名` PowerShell `Test-Connection`	OSの名前解決結果（hosts含む）で到達性を確認できる	ICMP遮断環境では結果が判断しづらい
名前解決＋特定ポート（443等）まで確認したい	PowerShell `Test-NetConnection -ComputerName ... -Port ...`	名前解決結果とTCP疎通（ポート開閉）まで確認できる	FW/ACL/NATの影響も受ける
DNSサーバーにレコードがあるか（DNSとして解決できるか）	`nslookup` PowerShell `Resolve-DnsName`	DNS応答としてA/AAAA/CNAME/SRVなどが返るか	hostsは参照しない前提で使う
Linuxで「hostsも含めた」解決結果を確認したい	`getent hosts ホスト名`	NSS（`nsswitch.conf`）の順序に従った解決結果を表示	環境により`hosts:`の順序が違う

hostsによるローカル名前解決ができているか確認する手順

1) hostsファイルの場所を確認する

まずは「正しいファイル」を編集しているかを確認します。特にWindowsでは、同名ファイルを別場所で編集していたり、拡張子が付いたりする事故がよく起きます。

OS	hostsのパス	編集のポイント
Windows（Server/10/11）	`C:\Windows\System32\drivers\etc\hosts`	管理者権限で編集・保存。拡張子なし。
Linux	`/etc/hosts`	`sudo`で編集することが多い。順序は`/etc/nsswitch.conf`に依存。
macOS	`/etc/hosts`	反映が遅い時はキャッシュクリアが必要なことがある。

2) 書式を正しく書く（URLやポートは書けない）

hostsの書式はシンプルです。左にIP、空白（スペース/タブ）を挟んで右にホスト名を書きます。1行に複数の名前（エイリアス）も書けます。

192.0.2.10    app01.example.local
192.0.2.10    app01.example.local    app01
# コメントは # で書けます

書けない例：http://app01.example.local や app01.example.local:443（URL/ポートは無効）
全角スペースや不可視文字が混ざると、その行だけ無視されることがあります（貼り付け時に要注意）。
同じホスト名の重複は避け、必要ならコメントで意図（切替日・担当・理由）を残すと運用が安定します。

3) 反映されないときはキャッシュを疑う

hostsを編集しても、OSやアプリが名前解決結果をキャッシュしていると、すぐに反映されないことがあります。Windowsならまずこれが定番です。

ipconfig /flushdns

PowerShellでOSのDNSキャッシュを確認したい場合は、次のようなコマンドが役立ちます（環境により表示が異なる場合があります）。

Get-DnsClientCache

OS別のキャッシュクリア例をまとめます。

OS	代表的なキャッシュクリア	補足
Windows	`ipconfig /flushdns`	アプリ側キャッシュは別途（再起動）必要な場合あり
Linux（systemd-resolved）	`sudo resolvectl flush-caches`	ディストリ構成によりコマンドが変わる
Linux（nscd）	`sudo systemctl restart nscd`	利用していない環境もある
macOS	`sudo dscacheutil -flushcache` `sudo killall -HUP mDNSResponder`	OSバージョン差で手順が変わることがある

4) hostsの効き目はping / Test-Connection / Test-NetConnectionで確認する

hostsが効いているか（OSとして解決できるか）を見たいなら、まずはpingが手早いです。

ping app01.example.local
ping -4 app01.example.local

PowerShellなら次のように書けます。

Test-Connection app01.example.local -Count 2

ICMPが遮断されている運用環境では、TCPで到達性を確認する方が現実的です。

Test-NetConnection -ComputerName app01.example.local -Port 443

ここでIPが期待通りなら「hostsを含むOSの名前解決は成立している」と判断できます。反対に、nslookupが失敗していても、上記が通るなら“通信”としては成立している可能性が高いです（DNSとして正しいかどうかは別問題）。

5) それでも解決しないときの典型パターン（現場で多い順）

よくある原因	症状	対処
hostsではなくhosts.txt等を編集	見た目は正しいのに一切反映されない	拡張子なしの「hosts」を正しいパスへ保存
管理者権限不足で保存できていない	編集後に内容が戻る/保存されない	管理者でエディタ起動して保存（または権限付与）
書式エラー（全角スペース、不可視文字、余計な記号）	特定行だけ無視される	半角スペース/タブで区切り、余計な文字を削除
キャッシュ残り（OS/アプリ）	古いIPに向かい続ける	`ipconfig /flushdns`、アプリ再起動、必要ならOS再起動
短縮名（単一ラベル名）とDNSサフィックスのズレ	`ping app01`は失敗するが`ping app01.example.local`は成功	hostsにFQDNと短縮名を同一行で併記（例：`... app01.example.local app01`）
IPv6優先で意図しない経路へ	hostsにIPv4を書いたのに別IPへ	`ping -4`で切り分け。必要ならAAAAも含め設計を見直す
VPN/セキュリティ製品/プロキシが独自に名前解決	一部アプリだけhostsを無視する	製品のDNS保護/DoH/名前解決設定を確認

nslookupで解決したい場合の正攻法：DNSにレコードを登録する

「nslookupで解決したい」は言い換えると“DNS問い合わせで解決したい”です。この場合、やるべきことは1つです。

DNSサーバーに正しいレコード（A/AAAAなど）を登録
クライアント（またはサーバー）がそのDNSを参照するよう設定

Windows Server DNSでAレコードを作る（名前→IPv4）

GUI（DNSマネージャー）での流れは以下です。

DNSマネージャーを開く
「正引き参照ゾーン」→対象ゾーン（例：example.local）
「新しいホスト (A または AAAA)」でホスト名とIPを登録
逆引きが必要なら「関連付けられたPTRレコードを作成」にチェック

PowerShellで作るなら、次のように登録できます。

Add-DnsServerResourceRecordA -ZoneName "example.local" -Name "app01" -IPv4Address "192.0.2.10"

IPv6を使うならAAAAも検討します。

Add-DnsServerResourceRecordAAAA -ZoneName "example.local" -Name "app01" -IPv6Address "2001:db8::10"

クライアントのDNS参照先がズレていると永遠に引けない

DNSにレコードを作っても、参照先が違えば当然引けません。「DNSを外した」環境だと、ネットワーク設定にDNSサーバーが空のまま、というケースが特に多いです。

チェック対象	見るべきポイント	ありがちな落とし穴
WindowsのNIC設定	IPv4/IPv6のDNSサーバー欄	DNSが未設定で`nslookup`の問い合わせ先がない
DHCP配布	DNSサーバーオプション、ドメイン名、サフィックス	古いDNSが配られていて端末全体が誤参照
Linux	`/etc/resolv.conf`、NetworkManager、systemd-resolved	直書きと管理ツールが競合して上書きされる

nslookupは「DNSサーバー指定」で切り分けると速い

nslookupは問い合わせ先DNSサーバーを明示できます。これができると、原因切り分けが一気に加速します。

nslookup app01.example.local 192.0.2.53

この形式で成功するなら「DNSサーバー（192.0.2.53）にはレコードがある」。失敗するなら「そのDNSにはレコードがない、または到達できない」。さらに、DNSが複数ある環境では「Aでは引けるがBでは引けない」といった差分を炙り出せます。

Active Directory環境での補足：DNSを外すと“名前解決以上”が壊れる

「pingが通るからOK」と判断してしまうと、後から痛い目を見る典型がAD（Active Directory）環境です。ADはDNS（特にSRVレコード）を前提に設計されているため、DNSを無効化・撤去すると認証やドメイン機能が不安定になります。

機能	DNSが必要な理由	起きがちな障害
ドメインコントローラー探索	SRVレコードでLDAP/Kerberos等のサービス位置を発見	ドメイン参加・ログオン遅延、DC不検出
Kerberos認証	サービス探索やSPN関連で名前解決が前提になる場面がある	認証失敗、共有アクセス不可、断続的エラー
GPO（グループポリシー）	ドメイン名・SYSVOL参照でDNS前提	ポリシーが反映されない/遅い
冗長構成・フェイルオーバー	複数Aレコード、サービス名での切替などDNS機能に依存	片系固定、障害時に切替不能

ADでDNSを確認するときは、AレコードだけでなくSRVレコードも見ます。例として、ドメインコントローラー探索に使われるレコードは次のように確認できます（ドメイン名は環境に合わせて変更）。

nslookup -type=SRV _ldap._tcp.dc._msdcs.example.local

この手の確認はhostsでは代替できません。だからこそ、AD環境では「一時回避としてhosts」「恒久対策はDNS整備（冗長化含む）」が現実的です。

運用の現実解：hostsは“補助”、DNSは“基盤”として設計する

hostsは便利ですが、端末ごとの設定であり、更新漏れ・戻し忘れ・管理不能が事故につながりやすいのも事実です。次の方針にすると破綻しにくくなります。

シーン	おすすめの打ち手	理由
検証や切替で、一部だけ一時的に向け先を変えたい	hostsで短期間上書き（期限を決める）	影響範囲を端末単位に閉じ込められる
複数サーバー/複数端末に恒久的に配りたい	DNSに登録し、DNS冗長化（2台以上）	配布漏れが致命傷になるため
移行期間でIPが揺れる	DNSのTTL設計＋段階切替（必要なら一部だけhosts）	キャッシュ影響をコントロールしやすい
「とりあえずDNSを撤去したい」	撤去ではなく復旧/再構成/冗長化を優先	ADや認証・運用基盤に波及しやすい

hostsを使う場合は、次のような運用ルールを作っておくと事故が減ります。

変更理由・期限・担当者をコメントで残す（例：# 2025-12-29 切替検証のため期限:2026-01-05）
検証が終わったら必ず削除（戻し忘れが最も危険）
サーバー群へ広げるなら、手作業ではなく構成管理（スクリプト/GPO/管理ツール）で一元化

最短で原因に辿り着くチェックリスト

目的を決める：OSとして解決したいのか、DNSとして解決したいのか
OSとしての確認：ping / Test-Connection / Test-NetConnection
hostsの確認：パス、拡張子なし、書式、権限、重複、短縮名、IPv6優先
キャッシュ対策：ipconfig /flushdns、アプリ再起動、必要ならOS再起動
DNSとしての確認：nslookupでDNSサーバーを指定して問い合わせ
DNS側の修正：A/AAAA/PTR/SRVなど必要なレコード登録、参照先DNS設定（DHCP含む）を整備

よくある質問

Q. hostsに書いたのに、pingが古いIPに向かいます

A. DNSキャッシュやアプリのキャッシュが残っている可能性が高いです。まずipconfig /flushdnsを実行し、ブラウザや常駐サービスなど“長く動いているアプリ”も再起動してください。サーバープロセスは内部キャッシュを持つことがあり、OS側をクリアしても反映されない場合があります。

Q. nslookupで「Server: Unknown」やタイムアウトになります

A. 参照するDNSサーバーが未設定、到達不可、または53番（UDP/TCP）が遮断されている可能性があります。まずは問い合わせ先を明示して実行し、疎通（ルーティング/ACL/FW）もセットで確認すると早いです。

nslookup app01.example.local 192.0.2.53

Q. hostsで解決できているのに、特定アプリだけ接続先が変わりません

A. アプリが独自の名前解決（DoH、内蔵リゾルバ、VPN/プロキシ経由の解決）を使っている可能性があります。同じ端末でpingの結果とアプリ挙動を比較し、ズレるならアプリ側設定やネットワーク中継の設定を確認してください。

Q. AD環境ですが、DNSをやめてhosts運用にしても大丈夫ですか？

A. 原則おすすめしません。ADはDNS（特にSRVレコード）を前提にしており、認証やドメインサービス探索が壊れやすいです。一時的にしのぐなら影響範囲を限定しつつ、DNSの復旧・冗長化を最優先で進めるのが安全です。

まとめ：nslookupが引けないのは正常。目的に合わせて“道具”を替える

hostsにIPを書いたのにnslookupで名前解決できないのは、nslookupがhostsを参照せず、DNSだけを問い合わせるためです。hostsの効き目を確認したいならpingやTest-Connectionで、DNSとして解決させたいならDNSサーバーにレコード登録・参照先設定を行い、nslookupで検証しましょう。特にWindows Server／Active Directory環境ではDNSが基盤になるため、「hostsは一時回避、恒久対策はDNS整備」が最も事故が少ない進め方です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。