何が起きているか
あなたのマシンがDHCPディスカバーブロードキャストを送信しましたが、有効な応答が返ってきませんでした — そのため、自己割り当ての169.254.x.x（APIPA）アドレスにフォールバックするか、まったくアドレスが割り当てられない状態になっています。エラーの全文は次のとおりです：
DHCP lease acquisition failed. No IP address could be obtained.
有効なIPアドレスがなければ、LAN上のどのデバイスもあなたのマシンにトラフィックをルーティングできません。インターネット接続は完全に切断されます。根本原因はさまざまな範囲に存在します：ネットワークアダプター、DHCPクライアントサービス、またはローカルファイアウォール — あるいはDHCPサーバー自体がアドレス枯渇、設定ミス、またはネットワーク側からアクセス不能な状態になっている可能性があります。
デバッグ手順
ステップ1 — 有効なIPアドレスがないことを確認する
設定を変更する前に、インターフェースに実際に割り当てられているアドレスを確認してください。
Windows：
ipconfig /all
Autoconfiguration IPv4 Address . . : 169.254.x.x という行が表示された場合、DHCPが失敗したことが確認されます — WindowsがフォールバックとしてAPIPAアドレスを自己割り当てした状態です。
Linux：
ip addr show
# または古いシステムの場合：
ifconfig -a
インターフェース（例：eth0、ens33）にinetの行がない場合、リースが取得されていないことを意味します。
macOS：
ipconfig getifaddr en0
出力がない、または169.254.x.xのアドレスが表示される場合、DHCPが失敗しています。
ステップ2 — DHCPサーバーに到達できるか確認する
Linuxでは、詳細出力付きで手動DHCPリクエストを実行します：
# eth0 をご使用のインターフェース名に置き換えてください
sudo dhclient -v eth0
出力を注意深く確認してください。DHCPDISCOVERが送信されてもDHCPOFFERが返ってこない場合、問題はネットワーク側にあります — DHCPサーバーがダウンしているか、このVLANにサーバーが存在しないか、またはファイアウォールがUDPポート67/68をブロックしています。
DHCPOFFERの後にDHCPNAKが返ってくる場合は別の問題です：サーバーがリクエストを拒否しています。これは通常、IPプールの枯渇またはアドレスの競合を示しています。
ステップ3 — イベントログ / システムジャーナルを確認する
Windowsイベントビューアー：
# PowerShellで実行
Get-WinEvent -LogName System | Where-Object { $_.ProviderName -eq 'Dhcp-Client' } | Select-Object -First 20 | Format-List TimeCreated, Message
Linux systemdジャーナル：
journalctl -u NetworkManager --since '10 minutes ago'
# または dhclient を直接確認する場合：
journalctl -u dhclient -n 50
解決策
修正1 — リースを解放して更新する（まずこれを試す）
Windows：
ipconfig /release
ipconfig /renew
ipconfig /renewがハングするかエラーをスローする場合は、修正2に進んでください。
Linux：
# 既存の dhclient を終了してから再リクエスト
sudo dhclient -r eth0
sudo dhclient eth0
macOS：
sudo ipconfig set en0 DHCP
またはシステム設定 → ネットワーク → [インターフェース] → DHCPリースを更新から操作してください。
修正2 — DHCPクライアントサービスを再起動する
DHCPデーモンは、特にスリープ/ウェイクサイクルやネットワークの一時的な障害の後に、不正な状態でスタックすることがあります。再起動することで、ゼロからクリーンな再ハンドシェイクが強制されます。
Windows：
# PowerShell（管理者として実行）
Restart-Service -Name Dhcp
ipconfig /renew
Linux（NetworkManager）：
sudo systemctl restart NetworkManager
# 再起動後にステータスを確認
systemctl status NetworkManager
Linux（systemd-networkd）：
sudo systemctl restart systemd-networkd
修正3 — ネットワークアダプターのリセット / 状態のフラッシュ
破損したリースキャッシュや古いアダプターの状態が残っていると、クリアするまでDHCPはすべての試行で失敗し続けます。Windowsでの完全なリセット手順は次のとおりです：
# 管理者として実行
netsh winsock reset
netsh int ip reset
ipconfig /flushdns
ipconfig /release
ipconfig /renew
これらのコマンドを実行した後は再起動してください。winsock resetとint ip resetコマンドは、次回の起動後に完全に有効になります。
Linux — 古いリースファイルを削除する：
# 場所はディストリビューションによって異なります
sudo rm /var/lib/dhclient/dhclient.leases
sudo rm /var/lib/NetworkManager/*.lease
sudo systemctl restart NetworkManager
修正4 — ネットワークアダプターを無効化して再度有効化する
Windows（PowerShell）：
$adapter = Get-NetAdapter | Where-Object { $_.Status -eq 'Up' } | Select-Object -First 1
Disable-NetAdapter -Name $adapter.Name -Confirm:$false
Start-Sleep -Seconds 3
Enable-NetAdapter -Name $adapter.Name
Linux：
sudo ip link set eth0 down
sleep 3
sudo ip link set eth0 up
sudo dhclient eth0
修正5 — DHCPプールの枯渇（サーバー側の修正）
複数のデバイスが同時にIPアドレスを取得できない場合、プールが枯渇している可能性があります。一般的なホームルーターは192.168.1.100〜192.168.1.150のような範囲で出荷されます — これはわずか51アドレスです。60台以上のデバイスがある中規模のオフィスでは、この上限をあっという間に超えてしまいます。
ルーターの管理画面にログインして、以下のいずれかまたは複数を実行してください：
- DHCPプールの範囲を拡張する（例：100〜150の代わりに192.168.1.100〜200）
- リース時間を24時間から4〜8時間に短縮し、古いリースをより早く期限切れにする
- すべてのアクティブなリースをクリアして、デバイスに新しいリースを再要求させる
dnsmasqまたはisc-dhcp-serverを実行しているLinuxサーバーでは、現在アクティブなリース数を確認してください：
# 現在のリースを確認
cat /var/lib/misc/dnsmasq.leases
# または
cat /var/lib/dhcpd/dhcpd.leases | grep -c 'binding state active'
修正6 — UDPポート67/68をブロックするファイアウォールを確認する
DHCPトラフィックはUDPで動作します：サーバー用のポート67、クライアント用のポート68です。厳格なファイアウォールルールがこれらのパケットを静かにドロップすることがあります — エラーメッセージなし、サーバーからの応答もなし。
# Linux — iptables が DHCP トラフィックをドロップしているか確認
sudo iptables -L INPUT -n -v | grep -E '67|68'
# 一時的に許可する（テスト用のみ）
sudo iptables -I INPUT -p udp --dport 68 -j ACCEPT
sudo iptables -I OUTPUT -p udp --dport 67 -j ACCEPT
修正が機能したことを確認する
# Windows
ipconfig /all
# 確認項目：IPv4 Address = 192.168.x.x（169.254.x.x ではないこと）
# 確認項目：DHCP Enabled = Yes
# 確認項目：Lease Obtained = [最近のタイムスタンプ]
# Linux
ip addr show eth0
# 確認項目：inet 192.168.x.x/24
# ゲートウェイにpingを送信してルーティングが機能することを確認
ping -c 4 192.168.1.1 # Linux/macOS
ping 192.168.1.1 # Windows
ヒント
サブネットの設定ミスやIPレンジが正しくないと思われる場合は、ToolCraftのサブネット計算機を使用してCIDRレンジを確認し、IPが期待するサブネット内に実際に含まれているかどうかを検証できます。ブラウザ上で完全に動作し、何もアップロードされません。
学んだこと
- 169.254.x.x はWindowsにおける最初の手がかりです — このアドレスはDHCPが失敗し、WindowsがAPIPAフォールバックを自己割り当てしたことを意味します。
- Linuxでは
dhclient -vを使用してください — 詳細出力によりDISCOVER → OFFER → REQUEST → ACKの完全なハンドシェイクが表示されるため、どのステップで問題が発生しているかを正確に確認できます。 - リースプールの枯渇はオフィスや研究室でよく見られます — リース時間を（24時間ではなく）4〜8時間に短縮することで、リースを解放せずに離席したデバイスからアドレスを回収しやすくなります。
- VMやコンテナには特別な注意が必要です — ライブマイグレーションやスナップショット復元後に仮想ネットワークアダプターやブリッジが不正な状態になることがあります。アダプターの完全なリセットでほぼ必ず解消されます。