端末が IP アドレスを受け取れないとき、最初に確かめるべきなのは「端末の要求（DHCPDISCOVER）がサーバーまで届いているか」と「サーバーの返事（DHCPOFFER）が端末まで戻っているか」の2点です。この記事では、症状とログからどちら側で止まっているかを見分ける方法を説明し、そのうえで起こりやすい順に原因を挙げて、それぞれの確認方法と直し方をまとめます。対象は家庭や事務所のルーターの DHCP と、Linux で動かしている DHCP サーバー（ISC DHCP、Kea、dnsmasq など）の両方です。
まず症状を確認する
端末側で見えるサイン
DHCP に失敗した端末には、OS ごとに特徴的な状態が現れます。
- Windows・macOS：IP アドレスが
169.254.x.xになる。DHCP の返事を受け取れず、OS がリンクローカルアドレスを自分で付けた状態です。ipconfig /renewを実行すると、DHCP サーバーに接続できない旨のエラーが表示されます。 - Linux（NetworkManager）：
journalctl -u NetworkManagerに DHCP のタイムアウトが記録されます。 - Linux（systemd-networkd / netplan）：
networkctl status eth0で、アドレスが付かず設定中のまま止まっているのが分かります。詳しくはjournalctl -u systemd-networkdを見ます。
ほかの端末は正常にアドレスを受け取れているかも確認してください。1台だけの問題なら端末側、全台なら DHCP サーバーやネットワーク側を疑います。この切り分けだけで、調べる範囲は半分になります。
パケットを見てどこで止まっているかを知る
ログだけで判断できない場合は、端末とサーバーの両方で DHCP のパケットを観察します。DHCP はサーバーが UDP 67番、クライアントが UDP 68番を使います。
# 端末側・サーバー側の両方で実行し、やり取りを観察する
sudo tcpdump -ni eth0 -e 'port 67 or port 68'DHCP は DISCOVER（端末）→ OFFER（サーバー）→ REQUEST（端末）→ ACK（サーバー）の4段階で進みます。観察結果は次のように読み分けます。
- 端末から DISCOVER が出ていない：端末の DHCP 設定やリンクの問題
- 端末から出ているのにサーバーに届かない：ケーブル・スイッチ・VLAN・リレーの問題
- サーバーに届いているのに OFFER を返さない：サーバーの設定やアドレス不足
- OFFER は出ているのに端末に届かない、または NAK が返る：経路上のフィルターや、別の DHCP サーバーとの競合
原因と対処（起こりやすい順）
1. リンクや接続先の問題
ケーブルの抜けかけ、Wi-Fi が別の SSID につながっている、スイッチのポートが想定と違う VLAN に入っている、といったケースがもっとも多い原因です。
確認：ip link show で state UP になっているか、Windows で「メディアは接続されていません」と出ていないかを見ます。Wi-Fi なら接続中の SSID 名を確認します。
対処：ケーブルやポートを替える、正しい SSID につなぎ直す。VLAN の設定はネットワーク管理者に確認するのが早道です。
2. DHCP サーバー（サービス）が止まっている
ルーターが固まっている、Linux の DHCP サービスが設定エラーで起動できていない、といったケースです。
確認：ルーターならランプや管理画面の状態を見ます。Linux ならサービスの状態とログを確認します。サービス名はソフトウェアやディストリビューションによって異なります。
# ISC DHCP(Debian/Ubuntu のパッケージ名の例)
systemctl status isc-dhcp-server
journalctl -u isc-dhcp-server -n 50
# Kea(Debian/Ubuntu のサービス名の例。RHEL 系では kea-dhcp4 など)
systemctl status kea-dhcp4-server
# 設定ファイルの構文チェック
sudo dhcpd -t -cf /etc/dhcp/dhcpd.conf
sudo kea-dhcp4 -t /etc/kea/kea-dhcp4.conf対処：構文エラーを直して起動し直します。設定を変更する前には、元のファイルをコピーして残しておきます。なお ISC DHCP は開発元の保守が終了しており、後継として Kea が案内されています（2026年10月現在）。新しく構築する場合は Kea や、小規模なら dnsmasq を検討してください。
3. 払い出すアドレスが足りない
払い出し範囲（プール）のアドレスをすべて貸し出してしまうと、新しい端末には返事ができません。来客用の Wi-Fi や、スマートフォン・IoT 機器が増えたネットワークで起こりがちです。
確認：ルーターの管理画面の DHCP 一覧で、貸し出し数が範囲の上限に達していないかを見ます。ISC DHCP ではログに no free leases と記録されます。
対処：払い出し範囲を広げる、リース期間（貸し出し期間）を短くして使われなくなったアドレスを早く回収する、固定 IP の機器を範囲の外へ移す、といった方法があります。範囲を広げるときは、固定 IP を割り当てている機器と重ならないように注意します。
4. サーバーの待ち受け設定がネットワークと合っていない
Linux の DHCP サーバーでは、待ち受けるインターフェースや、払い出すサブネットの定義がそのインターフェースのアドレスと一致していないと、要求が届いても応答しません。サーバーの IP アドレスやインターフェース名を変えたあとによく起こります。ISC DHCP では起動時に No subnet declaration for eth0 のようなメッセージが出ます。
対処：サーバー自身のアドレスが含まれるサブネットの定義を用意し、待ち受けるインターフェースを正しく指定します（Debian 系の ISC DHCP では /etc/default/isc-dhcp-server で指定します）。
5. ファイアウォールで DHCP の通信を止めている
DHCP サーバーを動かしているマシンのファイアウォールが UDP 67番を受け付けていないと、DISCOVER は届いても処理されません。
# ufw の場合
sudo ufw allow 67/udp
# firewalld の場合
sudo firewall-cmd --permanent --add-service=dhcp
sudo firewall-cmd --reloadルールを追加する前に、既存のルールを sudo ufw status numbered や sudo firewall-cmd --list-all で確認しておくと、意図しない開放を避けられます。
6. 別のネットワークからのリレーが設定されていない
DHCP の DISCOVER はブロードキャストなので、ルーターを越えて別のサブネットには届きません。サーバーと端末が別のサブネットや VLAN にある構成では、間のルーターやL3スイッチに DHCP リレー（機種によって名称が異なります）の設定が必要です。
対処：リレーの転送先にサーバーの IP が正しく設定されているか、サーバー側にその端末のサブネット用の払い出し定義があるかを確認します。
7. 別の DHCP サーバーが動いている
ネットワーク上に DHCP サーバーが2台あると、意図しない側が先に返事をして、間違ったゲートウェイや DNS を配ってしまいます。持ち込まれた無線ルーターをルーターモードのままつないだ場合などに起こります。
確認：端末が受け取ったアドレスや DHCP サーバーのアドレスが想定と違わないかを ipconfig /all などで見ます。管理しているネットワークであれば、nmap の DHCP 検出スクリプトで応答するサーバーを洗い出せます。
sudo nmap --script broadcast-dhcp-discover対処：見つかった機器の DHCP 機能を止めるか、ブリッジ（アクセスポイント）モードに切り替えます。スキャンは自分が管理するネットワークに限って行ってください。
復旧までの一時的なしのぎ方
原因の特定に時間がかかる場合は、重要な端末だけ一時的に静的 IP を設定して業務を続ける方法があります。その際は払い出し範囲の外のアドレスを選び、原因が直ったら DHCP に戻すことを忘れないようにします。
まとめ
- 1台だけか全台かで、端末側の問題かサーバー側の問題かを切り分ける
169.254.x.xのアドレスは DHCP の返事を受け取れていないサイン- tcpdump で DISCOVER・OFFER の流れを見ると、止まっている場所が分かる
- 原因はリンクや VLAN、サービス停止、アドレス不足、待ち受け設定の不一致、ファイアウォール、リレー未設定、別の DHCP サーバーの順に多い
- 設定を変える前はバックアップを取り、スキャンは自分の管理するネットワークに限る