169.254（APIPA）でWi-Fiがインターネットに繋がらない原因と対処法｜DHCP失敗・Meraki阻害の切り分け

Wi-Fi 接続はできるのにインターネットに出られず、IP が 169.254.x.x（APIPA）になる。これは DHCP が成功していない典型パターンです。原因の切り分け順と、実際に rogue Meraki が DHCP を阻害していた事例を踏まえた恒久対策をまとめます。

まず結論：169.254.x.x（APIPA）は「DHCP が失敗した」サイン

ノートPCだけ、または特定の端末群だけが 169.254.x.x / 255.255.0.0（ゲートウェイなし） になり、ブラウザが「インターネットなし」と表示されるとき、疑うべき本丸はほぼ決まっています。DHCP サーバーに到達できない／DHCP の応答が返ってこないため、Windows が緊急避難的に自己割り当てする IP（APIPA: Automatic Private IP Addressing）になっている状態です。

APIPA はリンクローカルの考え方に近く、同一セグメント内で最低限の通信を成立させるための仕組みです。逆に言えば、デフォルトゲートウェイが入らないのが普通なので、LAN 外（＝別セグメントやインターネット）には出られません。

APIPA 自体は「故障」ではなく、IP 設定が確定できなかった結果として発生する症状です。対処の狙いは「なぜ DHCP が完走しないのか」を最短で特定することになります。

観点	正常（例）	異常（APIPA）	読み取れること
IPv4 アドレス	10.200.x.x	169.254.x.x	DHCP で払い出しを受けていない
サブネットマスク	設計どおり（例：255.255.255.0）	255.255.0.0	自己割り当て範囲（169.254/16）
デフォルトゲートウェイ	10.200.16.1 など	なし	LAN 外へルーティングできず、インターネットに出られない
DNS	社内 DNS / パブリック DNS など	未設定または不適切	名前解決ができず、体感的に「ネットが死んでいる」

Wi-Fi 接続＝ネットワーク正常、ではない

「SSID に接続できているからネットワークは大丈夫」と判断してしまうと、切り分けが遠回りになります。Wi-Fi の接続は大きく分けると次の段階があります。

• 無線区間の接続：電波、認証、暗号化、AP への関連付け（ここが OK だと「Wi-Fi にはつながる」）
• IP の取得：DHCP（ここが失敗すると APIPA になりやすい）
• 名前解決・外部到達：DNS とゲートウェイ経路（ここで詰まると「つながるけど遅い」「一部だけ見えない」など別症状になりやすい）

今回のように APIPA が出ているなら、主戦場は「IP の取得（DHCP）」です。端末設定を疑う前に、SSID→VLAN→中継機器→DHCP サーバーの経路を一本の線として見直すのが近道です。

DHCP の流れを一枚で理解する（Discover が出て Offer が返るか）

DHCP は「要求を出して、応答を受け取って、確定する」という往復通信です。どこで止まっているかが分かると、原因の当たりが付きます。

段階	通信のイメージ	失敗するとどう見えるか	疑うポイント
1	DHCP Discover（端末→ブロードキャスト）	端末が要求を出せない／出していない	NIC/ドライバ、OS 側フィルタ、無線認証の不安定
2	DHCP Offer（サーバー→端末）	Offer が返ってこない	VLAN/トランク、DHCP リレー、ACL/FW、経路上の rogue 機器
3	DHCP Request（端末→サーバー）	Request が通らない／戻らない	双方向の遮断、NAC/ポリシー、過負荷
4	DHCP ACK（サーバー→端末）	ACK が返らず確定しない	サーバー側の枯渇、フィルタ、競合（別 DHCP の介入）

切り分け優先順位：まず「経路側」を疑う

端末が数台ではなく、数十〜数百台規模で同時多発するなら、端末個別の設定よりも ネットワーク側の要因（経路・中継機器・ポリシー）の確率が一気に上がります。特に DHCP はブロードキャストやリレー（IP helper）に依存するため、途中で遮られると一斉に APIPA が発生します。

優先	疑う場所	なぜ優先か	典型的な失敗例
1	Wi-Fi〜DHCP までの経路（AP/コントローラー/ルーター/スイッチ/FW）	多数端末が同時に影響を受ける	SSID→VLAN の紐付けミス、トランク設定不整合、ACL で UDP67/68 を遮断、DHCP リレー未設定
2	クライアント（Windows）	個体差の切り分けに必要	セキュリティソフトがネットワークを「パブリック」と誤判定、仮想 NIC/フィルタドライバの不具合
3	DHCP サーバー/スコープ	枯渇や停止なら全滅するため確認は必須	スコープ枯渇、除外範囲の誤り、サービス停止、許可（Authorized）問題

クライアント側：5分でできる基本確認

端末側の確認は「ネットワークが悪いのか、端末が悪いのか」を切り分けるための材料集めです。現場で使いやすい順に並べます。

IP 設定と DHCP 状態を確認する

ipconfig /all

見るポイントは次のとおりです。

• IPv4 が 169.254.x.x になっていないか
• DHCP 有効になっているか（固定 IP になっていないか）
• デフォルトゲートウェイが空欄ではないか
• DNS が想定どおりか
• 同一 SSID でも 問題端末と正常端末で「接続先 AP（BSSID）」が違うことがあるため、可能ならそこも控える

リース更新で改善するか（改善しても「原因特定」は続ける）

ipconfig /release
ipconfig /renew

ここで 10.200.x.x を取得できるなら、DHCP が「たまたま」通った可能性があります。台数が多い現場では、偶然の成功に引っ張られると原因究明が遅れます。再現性があるか、場所・時間・AP・SSID で偏りがあるかを必ず確認してください。

名前解決ではなく「経路」を見る（APIPA ではほぼ通らない）

route print
ping 8.8.8.8

APIPA のままではデフォルトルートがなく、外部へ到達できないのが普通です。ここで重要なのは ping の成否よりも、0.0.0.0/0 のデフォルトルートが存在するかです。存在しないなら DHCP が完走していません。

ネットワークスタックのリセット（端末起因を疑うとき）

netsh winsock reset
netsh int ip reset
shutdown /r /t 0

仮想 NIC や VPN クライアント、EDR のフィルタドライバが絡んで DHCP 周りが不安定になることがあります。端末個別の問題が濃厚なときに実施します。

コマンド	目的	期待する変化	変化がない場合の示唆
ipconfig /all	現状把握	DHCP で 10.200.x.x + ゲートウェイ	経路側の DHCP 遮断、またはリレー不備
ipconfig /release	リース解放	IPv4 が解放される	NIC/ドライバ異常の可能性
ipconfig /renew	DHCP 再取得	Offer/ACK を受けて IP 取得	DHCP 応答が戻っていない
route print	ルーティング確認	デフォルトルートあり	ゲートウェイ未設定＝DHCP 未完了

ネットワーク側：DHCP が止まるポイントはここ

APIPA が大量に出るときは、DHCP 要求（Discover）が届かないか、応答（Offer/ACK）が戻っていないかのどちらかです。多くの現場では、「DHCP サーバー自体」よりも「途中の中継機器」で詰まります。

SSID と VLAN の紐付けを再確認する

SSID が正しい VLAN にブリッジされていないと、DHCP が別セグメントに飛ばず、APIPA になります。特に次の変更が直近で入っている場合は要注意です。

• SSID の追加・複製（似た SSID を作ったつもりが VLAN が別だった）
• ゲスト用設定（クライアント分離、L2 制限、ポータル設定）
• AP の有線側がアクセスポートになっており、本来必要な VLAN が通っていない

DHCP リレー（IP helper）設定の漏れ・誤り

無線 VLAN が L3 で分離されている構成（SVI/ルーター配下）では、DHCP ブロードキャストをサーバーへ中継するための DHCP リレーが必要です。ここが抜けると「Wi-Fi にはつながるが IP が取れない」が発生します。

「他のスコープは動いているのに、このスコープだけ APIPA が出る」というときは、スコープ設定そのものより その VLAN の L3 側（SVI/VRF/セキュリティゾーン）に問題があるケースが目立ちます。

ACL / ファイアウォールで DHCP（UDP 67/68）を落としていないか

DHCP は UDP を使います。セキュリティ機器やポリシーでブロードキャスト／リレーが遮断されると、端末は APIPA になります。大量発生の場合、「誰かが入れた機器」「誰かが変えたポリシー」が原因になりやすいのが現実です。

疑わしい要因	起きやすい症状	確認ポイント	対処の方向性
VLAN/トランク不整合	特定の AP 配下だけ APIPA	AP uplink の VLAN 許可、ネイティブ VLAN、スイッチポート設定	VLAN 設計どおりに統一
DHCP リレー未設定	その VLAN だけ IP 取得不可	L3 インターフェース/SVI の helper 設定	正しい DHCP サーバーへ中継
ACL/FW で DHCP 遮断	突然一斉に APIPA	UDP 67/68、ブロードキャスト許可、セキュリティログ	ポリシー修正、例外追加
DHCP スコープ枯渇	徐々に増える／朝だけ多い	リース数、除外範囲、予約、リース期間	スコープ拡張、リース調整
Rogue 機器の混入	場所やタイミングで発生率が揺れる	配線変更履歴、持ち込み機器、スイッチの MAC 学習	物理的に隔離し、接続位置を正す

DHCP サーバー側：スコープが「動いているように見える」罠

DHCP スコープ設定を見て「問題なさそう」に見えても、運用上の罠はいくつかあります。Windows Server の DHCP でありがちな観点を、実務目線でまとめます。

スコープ枯渇は「他が動いている」でも起きる

スコープは VLAN（セグメント）ごとに別物です。他のスコープが正常でも、問題の VLAN のみ枯渇していれば、そこだけ APIPA が出ます。特に見落としやすいのが次の2つです。

• MAC ランダム化：端末が接続のたびに MAC が変わると、DHCP 側では別端末としてリースを消費し、枯渇が早まる
• リース期間が長すぎる：一時接続の端末が多い環境（研修・イベント・来客）でリースが戻らず、翌日以降に詰む

フィルタ（許可/拒否）や予約の影響

DHCP のフィルタ設定や予約設定は、運用者が変わると意図が引き継がれず「いつの間にか一部が取れない」原因になります。フィルタや予約がある場合は、問題端末の MAC アドレスが対象外になっていないか確認します。

ログと統計で判断する

「コンソールの表示が警告っぽい」だけで判断せず、統計（割当済み/空き）とログで事実を確認します。DHCP サーバー側のログ、イベントログ、監視ツールのアラートなど、複数の根拠を合わせると判断がブレません。

「PC だけ APIPA」でも、端末を疑い過ぎない

質問でよくあるのが「スマホはつながるのに、ノートPCだけ APIPA」という状況です。ここで端末原因に寄りがちですが、実務的には次のパターンが多いです。

• スマホは別 SSID（ゲスト SSID や 2.4GHz/5GHz の設定差）で実は経路が違う
• PC だけ 802.1X（証明書/認証成功後に VLAN が割り当てられる）で VLAN が変わり、DHCP 経路が変わる
• PC のみポリシー対象（NAC/EDR 連携）で DHCP を含む通信が制限される

「同じ SSID、同じ AP、同じ場所、同じ時間」でスマホと PC を比べ、さらに PC も正常端末と問題端末を入れ替えて比較できると、原因特定が一気に進みます。

一時的に効くことがある回避策と、その扱い方

現場では「とりあえず復旧」が求められるため、回避策を使う場面はあります。ただし、台数が多いときは 回避策＝恒久対策ではないことを強く意識してください。

回避策	期待できる効果	効いてしまう理由	落とし穴
IPv6 を無効化	一部環境で DHCP が安定することがある	ドライバやフィルタの相性でタイミングが変わる	根因が残り、再発する。将来の IPv6 施策と衝突
Windows ファイアウォール/セキュリティソフトを一時無効化	クライアント起因なら改善	DHCP 周りを含むフィルタが外れる	セキュリティ低下。大量展開には不向き
ipconfig /release & /renew	タイミング次第で IP を取れる	再試行で偶然成功する	「直ったように見える」だけで原因が不明のまま

原因の実例：rogue（想定外）Meraki ファイアウォールが DHCP を阻害

最終的に解決したケースとして多いのが、ネットワーク経路上に “想定外の機器” が入り、DHCP が遮られていたパターンです。今回の結論もまさにこれで、端末側ではなく rogue（不正／想定外）Meraki ファイアウォールが DHCP 通信を阻害していました。

なぜ Meraki などの FW が DHCP を止めてしまうのか

• 接続位置が設計と違い、ブリッジすべきブロードキャストが遮断される
• VLAN タグの扱いが想定と異なり、DHCP Discover が別 VLAN に落ちる
• セキュリティポリシーや IDS/IPS の挙動で、UDP 67/68 がドロップされる
• 機器側で DHCP サービスが有効になっており、競合（誤った Offer）が発生する

特に「Wi-Fi にはつながる」状態を維持したまま DHCP だけを壊せてしまうのが厄介です。ユーザー視点では突然の障害に見えますが、ネットワーク視点では「途中で DHCP が断ち切られている」だけなので、経路を追うと必ず痕跡が出ます。

Meraki（または rogue 機器）を疑うべきサイン

• 同じビルでもフロアや島で発生率が違う
• AP をまたぐと症状が変わる
• 配線変更や機器追加の直後から発生した
• 一部端末は取れるが、時間帯で揺れる（混雑時に悪化）

特定のやり方：DHCP を「見える化」する

DHCP は目に見えないため、現場では「見える化」が最強です。おすすめは次の2つです。

Wireshark で DHCP の往復を確認

問題端末でキャプチャし、フィルタをかけます。

udp.port == 67 || udp.port == 68

理想は Discover → Offer → Request → ACK が見えること。Discover は出ているのに Offer が返らない場合、端末より外側（AP 以降、ルーター、FW、リレー）の問題です。

キャプチャで見えること	状況	次に疑う場所
Discover も見えない	端末が要求を出していない/出せていない	端末（ドライバ/フィルタ/無線認証）
Discover はあるが Offer がない	応答が戻らない	VLAN/トランク、DHCP リレー、ACL/FW、rogue 機器
Offer はあるが ACK まで行かない	途中で遮断・競合	ポリシー、過負荷、複数 DHCP の干渉

スイッチ側で「その DHCP パケットがどこから来たか」を追う

管理者が対応できる環境であれば、スイッチの MAC アドレステーブルやミラーポートで DHCP を確認し、想定外の機器（Meraki など）を物理的に特定します。ネットワーク図と現物が一致していないとき、障害は高確率でそこで起きます。

解決：該当 FW を経路から外す／正しい構成に戻す

原因となっていた Meraki ファイアウォールを経路から外す（または適切に修正）したところ、DHCP が正常化し、端末は 10.200.x.x を取得してインターネット到達が回復しました。大量の APIPA 端末が一気に解消するのは、経路原因の典型的な治り方です。

再発防止：APIPA 多発を「事故」にしない運用

同じ障害を繰り返さないためには、技術面だけでなく運用面のガードも重要です。特に rogue 機器混入は、設計より運用で防げる余地が大きいです。

再発防止策	狙い	具体例	効果が出やすい場面
変更管理（いつ・どこを変えたか）	原因探索を短縮	AP/スイッチ/FW の変更をチケット化、作業前後で疎通確認	突然の一斉障害
スイッチポートのガード	持ち込み機器の抑止	未使用ポートを shutdown、Port Security、802.1X、MAC 制限	rogue 機器混入
DHCP の監視	兆候を早期検知	割当失敗・枯渇のアラート、リース使用率の可視化	徐々に増える不具合
ネットワーク図と実配線の同期	経路の迷子防止	フロア単位で定期棚卸し、ラベル付け、ラック写真の管理	現場が大きい環境

現場で使えるチェックリスト

最後に、APIPA 大量発生時に「順番どおりに潰せる」チェックリストを置いておきます。焦るほど端末設定に手を入れがちですが、まずは経路を疑うのが鉄則です。

チェック	やること	判断基準	次の一手
1	問題端末で ipconfig /all を取得	169.254.x.x / GW なしなら DHCP 失敗	DHCP 往復のどこで止まるか確認
2	同じ場所で正常端末と入れ替え	場所依存なら経路・AP 側が濃厚	AP uplink/VLAN/トランク確認
3	SSID→VLAN の設定確認	設計 VLAN と一致しているか	誤設定を修正
4	DHCP リレー/ACL/FW を点検	UDP 67/68 が通るか	ログ/ポリシー/例外で切り分け
5	物理経路に想定外の機器がないか確認	作業履歴がない機器追加がないか	rogue 機器を隔離（今回の Meraki 事例）

まとめ

169.254.x.x（APIPA）は「DHCP が取れていない」ことを端的に示します。大量発生するなら、端末よりも Wi-Fi 経路上で DHCP を止めている要因（VLAN/リレー/ACL/FW/rogue 機器）を優先して疑うのが最短ルートです。特に、今回のように 想定外の Meraki ファイアウォールが DHCP を阻害していたケースでは、機器を外すだけで一気に解消します。次に同じ症状が出たときは、端末設定をいじる前に「経路に何が増えたか」を先に見に行ってください。