Red Hat EADDRNOTAVAIL (99) 解説: 指定アドレス利用不可エラーの原因究明と再設定策編

【注意】 本記事は EADDRNOTAVAIL (99) の一般的な原因整理と確認手順の解説です。運用中の本番環境で拙速に設定変更・再起動・再デプロイを繰り返すと、切り分け情報を失い、影響範囲を広げるリスクがあります。状況が複雑（クラスタ/コンテナ/複数NIC/経路制御/セキュリティ要件）な場合は、株式会社情報工学研究所のような専門事業者への相談を優先してください（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983 ／電話：0120-838-831）。

　

「昨日まで動いていたのに」—本番で突然出るEADDRNOTAVAIL(99)の理不尽

現場でこのエラーに遭遇する典型は、こんな瞬間です。デプロイ自体は通る。ヘルスチェックも（たまに）通る。なのに朝イチで監視が赤くなり、ログには EADDRNOTAVAIL (99)。関係者からは「結局ネットワーク？」「アプリが悪い？」と聞かれ、こちらは心の中でこう思う。

「いや、昨日まで動いてたんだって……。しかも“指定アドレス利用不可”って、こっちが指定した前提が崩れたってことだよね？」

ここで大事なのは、最初に“ダメージコントロール”を選ぶことです。EADDRNOTAVAIL は、焦って設定をいじるほど「どこがズレたのか」という証拠を消しやすいタイプのトラブルです。逆に言うと、最初の5分で観測点を確保できるかどうかで、その日の負荷が変わります。

最初の5分でやること（壊さない観測）

• 再起動ループ（systemdのRestart=always 等）を一度止め、ログが流れ続けない状態にする
• その時点のネットワーク状態を保存（IP、経路、ソケット、sysctl）
• 「いつから」「どのノードだけ」「listenなのかconnectなのか」を切り分ける

具体的には、次の“観測コマンド”をそのまま控えとして残します（貼り付け先はチケットでも障害報告でも構いません）。

date uname -a ip -br addr ip route nmcli -t dev status ss -lntp ss -s sysctl net.ipv4.ip_nonlocal_bind net.ipv4.ip_local_port_range 2>/dev/null || true journalctl -u <service_name> --no-pager -n 200

---

「EADDRNOTAVAIL＝ネットワークが落ちた」ではない

このエラーは、回線断やDNS障害のような“外側の故障”だけを意味しません。むしろ多いのは、アプリが期待しているローカル側の住所（IP/ポート/経路）が、今の環境と一致していないパターンです。環境が変わったのに設定が追随していない、あるいは設計上“変わり得る”ものを固定してしまっている。そういうズレが表面化します。

だからこそ、いきなり「設定を直す」より先に、「何が固定されていて、何が変わった可能性があるか」を棚卸しします。ここができると、次章以降の原因候補が一本道につながります。

　

エラー名に騙されない：EADDRNOTAVAILは「bind/connectの住所不一致」

まず事実として、EADDRNOTAVAIL は「アドレスが使えない」ですが、どのアドレスが・どの呼び出しで使えないのかで意味が変わります。Linux のネットワーク障害は、ここを曖昧にすると議論が過熱しがちです（「アプリが悪い」「NWが悪い」の空中戦）。温度を下げるために、syscall 目線に落とします。

bind() で出る EADDRNOTAVAIL：そのIPは“このホストのもの”ではない

待受（listen）の前段である bind() が失敗する場合、要点はシンプルです。指定したアドレスがローカルではない、または存在しないインターフェースを要求した、という系統です。典型例は「設定ファイルに固定IPを書いたが、そのIPが今のNICに載っていない」です。

このときの“最短の確認”は、設定ファイルを見るより先に ip addr で実在を確かめることです。目視で「そのIPがどのIFに付いているか」が分かれば、アプリ側の問題か、OS側の問題かが一気に絞れます。

connect() で出る EADDRNOTAVAIL：一時ポート枯渇や送信元決定の失敗

一方 connect() 側で出る EADDRNOTAVAIL は、話が少し変わります。Linux では、ソケットが未bindのまま connect() しようとした際、内部的に一時ポート（ephemeral port）を割り当てますが、その範囲のポートが使い尽くされていると EADDRNOTAVAIL になり得ます。つまり「相手に届かない」というより、自分側の出発点（送信元ポート）が作れないという状態です。

このタイプは、トラフィック増・短命接続の多用・TIME_WAIT の増加・NAT配下でのポート消費など、運用条件で起きます。「昨日まで動いていた」の延長線で起きやすいので、勘違いしやすいポイントです。

---

“どっちのEADDRNOTAVAILか”を決めるための最小表

起点	ありがちな原因	まず見る観測点
bind()	指定IPがローカルに無い／IFが違う／コンテナ名前空間に無い	ip -br addr、nmcli dev status、設定のlistenアドレス
connect()	一時ポート枯渇／TIME_WAIT過多／送信元アドレス決定ができない	ss -s、ss -tan state time-wait、ip_local_port_range

ここまでの整理ができると、次に進む伏線が揃います。つまり「そのIPは今このホストに載っているのか？」そして「載っていないのに載っている前提で動かしていないか？」です。

　

まず疑うべき伏線：そのIPアドレス、本当に今このホストに載ってる？

第1章・第2章の流れを踏まえると、最初の大きな分岐はここです。「指定しているIPが、今この実行環境でローカルアドレスとして成立しているか」。これが崩れていると、どれだけアプリを直しても収束しません。逆に、ここが成立しているなら、アプリ側の bind 戦略や connect 時のポート枯渇側に焦点を移せます。

確認は“文字列検索”ではなく“OSの事実”から

よくある失敗は「設定ファイルにそのIPが書いてあるから、OSにもあるはず」と思い込むことです。現実は、IPは消えます。DHCP更新、インターフェース名の変化、NetworkManagerの接続プロファイル差し替え、クラスタ切替、Kubernetesの再スケジューリング。アドレスは運用で揺れます。

なので、まずは OS が持つ事実を短いコマンドで見ます。

# どのIFにどのIPが付いているか（最短） ip -br addr # NetworkManager配下の“接続”状態（RHEL系で特に重要） nmcli -t dev status nmcli -t con show --active # そのサービスがどのアドレスで待ち受けようとしているか ss -lntp | head

---

コンテナ/Kubernetesで特に多い：ホストのIPをコンテナでbindしている

コンテナ環境では「ホストに存在するIP」と「コンテナ内（Pod内）で見えるIP」は一致しません。アプリが listen するアドレスを固定していると、ホストでは成立してもコンテナでは非ローカルになり、EADDRNOTAVAIL になります。

この場合の対策は大きく二つです。

• アプリは基本的に 0.0.0.0（IPv6なら ::）で待受し、到達制御は Service / Ingress / FW で行う
• どうしても特定IPが必要なら、hostNetwork など“そのIPが存在する名前空間”で動かす設計に寄せる

ここで重要なのは、場当たり的に「とりあえずhostNetwork」に逃げるのではなく、セキュリティ境界と運用責任がどこに移るかを理解した上で選ぶことです。権限と責任が増える変更ほど、後で戻しづらいからです。

---

VRRP/VIPやフェイルオーバー：非ローカルbindが“必要な設計”もある

ロードバランサやHA構成（例：Keepalived + HAProxy）のように、フェイルオーバーで VIP（仮想IP）が移動する設計では、「VIPを持っていない瞬間でも起動して待っていてほしい」という要件が出ます。このとき Linux の net.ipv4.ip_nonlocal_bind を有効化して、非ローカルアドレスへの bind を許可する設計があります。

ただし、これは“魔法の修正”ではなく、要件があるときにだけ選ぶべき設定です。なぜなら、非ローカルbind を許すと、アプリが「本来は存在しないはずのアドレス」にも bind できてしまい、設計ミスが見えにくくなる面があるからです。つまり、短期的には沈静化しても、長期的には運用の不確実性が増えることがある。ここは契約（要件）として扱うのが安全です。

次章では、この“アドレスが消える”代表格である DHCP/VRRP/クラスタ切替で、どの瞬間に何が起きるのかを、運用目線で整理します。

　

DHCP/VRRP/クラスタ切替で“指定アドレス”が消える瞬間

ここから先は「設定は正しいはずなのに、ある瞬間だけアドレスが成立しない」系の話です。EADDRNOTAVAIL を“運用の揺れ”として理解すると、対策が「場当たりの再起動」から「再発しない構成」へ寄っていきます。

DHCP更新・リンクダウン・再接続：IPが一時的に外れるのは珍しくない

RHEL系では NetworkManager が管理している構成が多く、リンクの瞬断やDHCPリース更新、プロファイル切替で、短時間だけIPが外れることがあります。そのタイミングでアプリが「特定IPへのbind」を行うと、bind() が EADDRNOTAVAIL になり得ます。

特に“昨日まで動いていた”のに起きるケースは、OSアップデート、NIC名の変化、接続プロファイルの差し替え、スイッチ側の再学習など、アプリ外の変更がトリガになります。ここで大切なのは、原因究明を急ぐ前に観測点を確保してから収束させることです（ログが流れ続けると肝心な瞬間が埋もれます）。

VRRP/VIPフェイルオーバー：VIPを“持っていない側”でbindしていないか

Keepalived等でVIPが移動する構成では、フェイルオーバーの直後に「VIPが付く前」または「付け替えの途中」という状態が発生します。そこで、アプリがVIPを固定でlistenしようとすると、bind() は失敗します。これは設計上の衝突です。

この衝突を避ける選択肢は大きく2系統です。

• アプリを 0.0.0.0（全IF）で待受し、到達制御はFW/LB/iptables/nftables側で担保する
• 要件がある場合のみ、非ローカルbind（ip_nonlocal_bind）を使い「VIPが来る前でも起動」できるようにする

非ローカルbindは、HA構成で合理性がある一方、誤設定でも“起動だけはできてしまう”面があります。つまり、短期的には抑え込みになっても、長期的に「本当にVIPが来ているのか？」という監視が必須になります。採用するなら、運用の契約（監視・検証・設計書）まで含めて決めるのが安全です。

---

systemdの起動順序：network.target と network-online.target は別物

ブート直後のEADDRNOTAVAILは、単純に「アプリが早起きしすぎた」ことでも起きます。systemd の After=network.target は“ネットワークスタックが起動した”程度で、IP取得が完了したことを保証しません。IP（DHCP）を待ちたいなら network-online.target を使い、NetworkManager環境では nm-online の有効化なども合わせて検討します。

さらに堅い運用として、サービス起動前に「必要なIPが存在するまで待つ」チェックを ExecStartPre に入れる方法があります。これは“やみくもな再起動”より、観測を保ったまま安全に収束させやすいです。

# 例：指定IPが付与されるまで最大30秒待つ（概念例） # 実環境ではタイムアウト値・対象IF・ログ出力先を要件に合わせる for i in $(seq 1 30); do ip -br addr | grep -q " 192.0.2.10/" && exit 0 sleep 1 done exit 1

起きていること	“安全に”寄せる対策の方向
DHCP/再接続でIPが一時的に外れる	起動順序の見直し（network-online）、必要なら起動前チェック、アプリは可能なら0.0.0.0待受
VIP移動で「VIP未付与」の瞬間がある	0.0.0.0待受＋到達制御／要件がある場合のみip_nonlocal_bind＋監視をセットで設計
フェイルオーバー後に疎通が不安定	GARPや近傍機器のARP更新、LBのヘルスチェック設計を見直し（“起動しただけ”を成功にしない）

次章では、同じ“アドレスの前提崩れ”でも、コンテナ/Kubernetesでなぜ頻発するのかを、名前空間の観点で整理します。

　

コンテナとKubernetes：Podの世界から見た「利用可能なアドレス」

コンテナ環境でEADDRNOTAVAILが増える理由は、特殊なバグではなく、前提が明確に違うからです。ホストOSの視点では“そのIPはある”。でも、Pod/コンテナの視点では“そのIPは無い”。このズレで bind() が失敗します。

ネットワーク名前空間：IPの“所有者”が違う

Linuxでは、プロセスはネットワーク名前空間に属します。コンテナは通常、ホストとは別の名前空間を持ち、そこで見えるIFとIPはPod/コンテナのものです。したがって、アプリ設定で「ホストの特定IP」をlisten先に指定していると、コンテナ内では非ローカルになり、EADDRNOTAVAILになります。

このとき、最初に確認すべきは「そのプロセスがどの名前空間で動いているか」と「その名前空間にIPがあるか」です。Kubernetesなら、Podに入って次を確認します。

# Pod/コンテナの中で ip -br addr ss -lntp

基本は“全IF待受”＋“外側で制御”が事故りにくい

多くのWeb/アプリサーバは、コンテナでは 0.0.0.0（全IF） で待受し、公開/制限は Service/Ingress、NetworkPolicy、FW、LB側で制御するのが一般的です。これなら「Pod IPが変わる」「ノードが変わる」といったKubernetesの前提（可変）に追随できます。

逆に、「特定IPを固定でbindしたい」という要件があるなら、それはKubernetesの“移動”と衝突しやすいので、設計の段階で整理が必要です。たとえば以下のように、責務が変わります。

要件	設計の方向（例）
特定IPでlistenしたい（IPが意味を持つ）	hostNetwork等でホスト側IPを直接扱う／Node固定の制約が増える点を許容できるか検討
Podが移動しても動けばよい	0.0.0.0待受＋Service/Ingressで到達性を担保（アプリはIP固定を捨てる）
到達制御を厳密にしたい	NetworkPolicy/セキュリティグループ/LBヘルスチェックで制御（アプリで縛りすぎない）

---

connect側のEADDRNOTAVAIL：短命接続とNATで“自分の出発点”が尽きる

コンテナやマイクロサービスでは、短命なHTTP接続が増えがちです。keep-alive不使用、過剰な再接続、タイムアウト設定の不整合があると、TIME_WAITが増え、一時ポート消費が進みます。すると connect() の段階で「ローカルに割り当てるポートが無い」状態に寄り、EADDRNOTAVAIL が出ることがあります。

このタイプは、アプリ修正というより接続の作法（再利用、プール、タイムアウト、リトライ）で大きく変わります。次章以降で触れる「IPv6/IPv4の解決結果」や「経路制御」も絡むので、ここで乱暴にリトライを増やすのは危険です。まずは現状のソケット統計を取り、増え方を見てから手を打つのが、結果として被害最小化になります。

# 接続状態の概要（TIME_WAITなど） ss -s # TIME_WAITが多いか ss -tan state time-wait | wc -l

次章では、見落とされがちなIPv6/IPv4のミスマッチが、EADDRNOTAVAILの引き金になるケースを整理します。

　

IPv6/IPv4ミスマッチ：getaddrinfoの結果とsysctl設定のズレ

「アプリはIPv4で動かしているつもり」でも、実際にはDNS解決結果やライブラリ挙動でIPv6を先に使おうとして、EADDRNOTAVAILに遭遇することがあります。特にRHEL系の環境差（sysctl、カーネル設定、NW機器のIPv6対応状況）があると、再現が難しくなります。

よくあるズレ1：IPv6を無効化しているのに、アプリがIPv6 bind しようとする

IPv6を net.ipv6.conf.all.disable_ipv6=1 などで無効化している環境で、アプリが :: や特定のIPv6アドレスにbindしようとすると、当然ながらアドレスが存在せず、EADDRNOTAVAILになり得ます。逆に、IPv6が有効でも、対象IFにIPv6が付与されていないと同じです。

# IPv6が有効か（代表例） sysctl net.ipv6.conf.all.disable_ipv6 sysctl net.ipv6.conf.default.disable_ipv6 # IPv6アドレスが付いているか（存在確認） cat /proc/net/if_inet6 2>/dev/null || true

よくあるズレ2：DNSがAAAAを返し、アプリがIPv6を優先して失敗する

名前解決（getaddrinfo）がAAAA（IPv6）を返すと、アプリやランタイムが先にIPv6へconnectを試みることがあります。ネットワーク経路がIPv6で成立していない場合、ENETUNREACH等になることもありますが、ローカル側の送信元アドレス選択が成立しない状況では、EADDRNOTAVAILが見えることがあります。

ここでの“安全な考え方”は、IPv6を使うなら使うで、OS設定・DNS・NW機器・監視まで揃えることです。中途半端にすると「環境によって成功/失敗が揺れる」状態になり、現場の説明コストが跳ね上がります。

---

対策の方向：OSで抑える／アプリで明示する

対策は二層あります。OS側で「IPv6は使う/使わない」を明確にし、アプリ側でも「待受はIPv4/IPv6どちらか」「解決結果の扱い」を明示する。どちらか片方だけだと、再発します。

レイヤ	チェック/方針（例）
OS（sysctl/IF設定）	IPv6を使うならIFに付与され経路があるか、使わないなら無効化方針を統一（部分無効化は事故が増える）
DNS/名前解決	AAAAの返り方と優先順位を把握。環境差があるなら、記録と監視をセットで
アプリ	待受は 0.0.0.0 / :: のどちらかを要件で決める。必要ならIPv4優先や解決結果のフィルタ（実装/設定）を検討

次章では、同じ“ローカル側の前提崩れ”でも、経路制御（ポリシールーティング等）や送信元固定が絡むケースを扱います。ここが分かると、EADDRNOTAVAILが「ネットワークが不安定」ではなく「設計の前提が揺れている」サインとして読めるようになります。

　

ルーティング／ポリシールーティング：送信元アドレス固定の落とし穴

EADDRNOTAVAIL が「IPが存在しない」だけでなく「送信元の決め方が破綻している」サインになるのが、経路制御が絡むケースです。複数NIC、複数経路、VPN、VRF、クラウドのセカンダリNICなどがあると、“どのIFから出すか”と“どの送信元IPを使うか”が自明ではなくなります。

まず押さえる事実：送信元IPは「bind」ではなく「経路」で決まることがある

アプリが送信元IPを明示していない場合、Linuxはルーティングを見て送信元アドレスを選びます。ここでポリシールーティング（ip rule）や複数テーブル、優先度が絡むと、想定と違うIFが選ばれ、そのIF上に送信元として使えるアドレスが無い状態に落ちることがあります。このとき connect() が失敗し、EADDRNOTAVAIL が見えることがあります。

逆に、アプリが送信元IPを固定（明示bind）している場合も注意が必要です。固定した送信元IPが「その時点でOSに存在しない」「経路的に不整合（返りが別IFになる等）」だと、やはり破綻します。ここは“正しさ”の議論より、実際にOSがどう選んでいるかを観測して、議論の温度を下げるのが先です。

観測の基本セット：ip route get で“OSの答え”を見る

経路に迷ったら、まず ip route get で「その宛先に対し、どのIFで、どの送信元が選ばれるか」を確認します。これは机上の設定読みより強いです。

# 宛先に対する経路・送信元の選択（例） ip route get 203.0.113.10 ip -4 route get 203.0.113.10 ip -6 route get 2001:db8::10

次に、ポリシールーティングがあるなら ip rule と各テーブルの中身を見ます。

ip rule show ip route show table main # 追加テーブルがある場合（例：100, 200 など） ip route show table 100 ip route show table 200

---

ありがちな事故パターン

• 複数NICで戻り経路が別IF：送信元固定により、戻りが非対称になり、接続が不安定化。結果として再接続が増え、一時ポート消費が進む。
• VPN/プロキシ導入でデフォルト経路が変化：アプリの送信元固定が、導入後の経路と整合しなくなる。
• クラウド環境でセカンダリIP/セカンダリNICを想定していたが未付与：設定上は存在する前提でも、実際にはアタッチされていない瞬間がある。
• rp_filter（逆方向パスフィルタ）設定の影響：非対称経路を“拒否”する方向に働き、疎通が揺れて、結果として接続試行が増える。

見える現象	確認ポイント
connect が断続失敗し、たまに EADDRNOTAVAIL	ip route get の src 表示、ip rule とテーブル、ss -s（TIME_WAIT増加）
特定ノードだけ発生	そのノードだけ経路/IF/IPが違う（付与漏れ、ルール差、NMプロファイル差）
VPN切替やLB変更の直後に増える	デフォルト経路とポリシールートの優先度、送信元固定の整合性

この章の結論は単純です。「送信元を固定する」ことは“設計の契約”です。契約があるなら監視と検証（経路確認、アドレス存在確認）が必要で、契約が無いなら固定しないほうが運用は安定しやすい。次章では、OS側で“正しい住所”を取り戻す再設定策を、RHEL/NetworkManager前提で整理します。

　

再設定策（OS側）：ip addr / nmcli / NetworkManagerで“正しい住所”を取り戻す

ここからは「原因がアドレスの不在・付与漏れ・起動順序・経路差」に寄っている場合の、OS側の再設定策です。大前提として、本番での変更は“最小・可逆・観測付き”が基本です。焦って設定を盛ると、鎮火どころか、切り分け不能になります。

1) まず“現状”を固定する（変更前の保存）

NetworkManager配下なら、接続プロファイルと現在の状態を必ず記録します。障害対応は、後から説明できることが価値です。

date hostname ip -br addr ip route nmcli -t dev status nmcli -t con show --active nmcli -t con show <CONNECTION_NAME> 2>/dev/null || true

---

2) “今だけ直す”の応急処置（永続化は別）

緊急で一時的にIPを付与し、サービスを復旧させたい場合、ip addr add で追加する方法があります。ただしこれは再起動で消えます。応急処置として割り切り、必ず次の永続設定に進みます。

# 例：一時的にIPを付与（環境に合わせて置換） ip addr add 192.0.2.10/24 dev eth0

この時点で、サービスが bind できるか（EADDRNOTAVAILが消えるか）を確認し、原因が“IP不在”に寄っていることを早期に確定させます。

---

3) 永続設定（RHEL系での本命）：nmcli で接続プロファイルを直す

RHEL 8/9 では NetworkManager が標準です。永続化は nmcli でプロファイルを直し、再接続して反映します（手動編集より安全なことが多い）。

# 接続名を確認 nmcli -t con show # 例：IPv4を手動にしてアドレス/ゲートウェイ/DNSを設定（値は要件に合わせる） nmcli con mod "<CONNECTION_NAME>" ipv4.method manual nmcli con mod "<CONNECTION_NAME>" ipv4.addresses "192.0.2.10/24" nmcli con mod "<CONNECTION_NAME>" ipv4.gateway "192.0.2.1" nmcli con mod "<CONNECTION_NAME>" ipv4.dns "192.0.2.53,192.0.2.54" # 反映（瞬断の影響があるため実施タイミングは要調整） nmcli con down "<CONNECTION_NAME>" nmcli con up "<CONNECTION_NAME>"

DHCP運用で、特定の“固定IP”ではなく「インターフェースにアドレスが付いていること」が要件なら、ipv4.method auto のまま、サービス側を 0.0.0.0 待受に寄せるほうが事故りにくい場合があります。ここは“固定すべき理由”があるかを先に確認します。

---

4) 起動順序の見直し：network-online と事前チェック

ブート直後のEADDRNOTAVAILは「IP取得前に起動」の可能性があります。systemdで After=network-online.target を検討し、必要なら ExecStartPre でIP付与を待つ仕組みを入れます。これは「再起動で直る」を減らし、運用の場を整えます。

5) sysctlは“要件があるときだけ”

よく話題に上がる sysctl（例：net.ipv4.ip_nonlocal_bind、ポート範囲等）は、効く場面がありますが、効く理由が説明できない状態で投入すると危険です。特に非ローカルbindは、HA要件がある場合の選択肢で、一般のアプリには推奨しにくいことが多いです。

設定	使う理由（要件）	注意点
ip_nonlocal_bind	VIPが移動し、VIP未付与でも起動して待ちたい	誤設定を隠す面がある。VIP存在の監視とセットで
ip_local_port_range	短命接続が多く一時ポート枯渇が疑われる	増やせば良いではない。接続再利用/タイムアウトも同時に見直す

OS側で住所を正したら、次はアプリ側です。次章では「固定bindをやめる」「再解決・再試行を設計する」など、環境変化に強い作り方へ寄せます。

　

再設定策（アプリ側）：0.0.0.0 bind、再解決、リトライ設計で環境変化に強くする

EADDRNOTAVAILの再発を減らす一番の近道は、アプリが「変わり得る前提」に依存しすぎないことです。特に、固定IPへのbindや、送信元IPの固定は、要件が無い限り運用コストを押し上げます。ここでは“契約がないなら固定しない”を基本方針にします。

待受（サーバ側）：特定IPに縛らず、到達制御は外側へ

Web/API等の一般的なサービスでは、0.0.0.0（全IF）で待受し、公開範囲はFW/LB/Ingressで制御するほうが、環境差で崩れにくいです。これにより、DHCP更新、インターフェース再構成、Pod移動などの変化に対し、bind失敗（EADDRNOTAVAIL）を起こしにくくなります。

どうしても「このIPでのみ受けたい」要件があるなら、そのIPが“常に存在する”ことを運用で担保する必要があります。具体的には、IP付与の監視、起動前チェック、フェイルオーバー時のVIP付与検証、構成変更手順の整備などが必要です。ここまで含めて初めて“固定にする価値”が出ます。

---

外向き接続（クライアント側）：送信元を固定しない、接続を増やしすぎない

connect側のEADDRNOTAVAILは、送信元固定の不整合や、一時ポート枯渇が絡むことがあります。アプリ側でできる基本は次のとおりです。

• 送信元IP/送信元ポートを固定しない（要件がある場合のみ。固定すると経路変更やNATで破綻しやすい）
• コネクションプールやkeep-aliveを使い、短命接続を減らす
• タイムアウト（接続/読み取り）を明示し、障害時に無限待ちしない
• リトライは指数バックオフ＋ジッタで、失敗時に“同時多発”させない（被害最小化）

ここでよくある落とし穴が「失敗したら即リトライを高速で回す」実装です。障害時にこれをやると、接続試行が増えてTIME_WAITが増え、結果として一時ポート消費が進み、EADDRNOTAVAILを自分で増幅させます。ダメージコントロールの観点では、“速い復旧”より“悪化させない復旧”が先です。

---

DNSと再解決：IPが変わる世界では“解決結果を握りしめない”

クラスタやLB配下では、宛先IPが変わることが前提です。にもかかわらず、解決結果をプロセス起動時に一度だけ固定し続けると、切替時に失敗が続きます。したがって、以下のような設計判断が必要です。

論点	考え方
DNS結果のキャッシュ	TTLを尊重し、長時間固定しない。障害時の再解決ができる設計にする
IPv6/IPv4の優先	環境で差が出るなら“明示する”か“統一する”。中途半端は不安定要因になる
リトライ戦略	即時連打ではなく、バックオフ＋ジッタ。障害を増幅させない

次の最終章では、ここまでの伏線を回収します。EADDRNOTAVAIL(99)は「アドレスが無い」という単発の不具合ではなく、“指定＝契約”が運用とズレたことが表面化したものです。一般論の対処には限界があり、構成・契約・セキュリティ要件が絡むほど、専門家に相談する判断が合理的になります。

　

帰結：「指定」は契約—アドレスと構成を“前提”にしない運用へ

EADDRNOTAVAIL(99) を一言でまとめるなら、「そのアドレスは、いまこの実行環境では“自分のもの”として成立していない」です。ここまでの章で見てきたとおり、原因は大きく2系統に分かれます。待受（bind）での「存在しないローカルアドレス」か、外向き接続（connect）での「送信元の割り当て失敗（送信元選択／一時ポート枯渇など）」か。どちらも、“ネットワークが不安定”という曖昧な言い方に逃げるほど、議論が過熱し、現場の消耗が増えます。

そして、いちばん重要な帰結はここです。固定IPへのbind、送信元アドレス固定、VIP未付与でも起動したい（非ローカルbind）、IPv6は使う／使わない――これらはすべて「指定」であり、指定は「契約」です。契約とは、要件があり、責務があり、検証と監視がセットである、という意味です。契約が無いのに指定すると、環境が少し揺れたときに破綻します。逆に、契約として握っているなら、揺れを前提に設計できます。

---

“契約”にするか、“前提にしない”か：判断の軸

現場で悩むのは、「指定を捨てて0.0.0.0で待受に寄せるべきか」「要件があるので固定を維持すべきか」です。一般論としては、次の整理が安全側です。

状況	事故りにくい方針
Kubernetes/コンテナでPodが移動する	アプリは0.0.0.0 / :: 待受に寄せ、到達制御はService/Ingress/Policyで担保（固定IPの前提を捨てる）
DHCP・NW再接続でIPが揺れる	固定bindを減らす／どうしても必要なら起動順序（network-online）＋事前チェック＋監視で契約化
VIP移動（HA/VRRP）がある	要件がある場合のみ非ローカルbindを検討し、VIP存在の監視とフェイルオーバー手順をセットで設計
外向き短命接続が多い	接続再利用（keep-alive/プール）・タイムアウト・バックオフ設計を優先。闇雲にリトライを増やさない

この表を見て「うち、複数行に当てはまるな」と感じたなら、一般論だけで“きれいに解ける”期待は下げたほうがいいです。なぜなら、EADDRNOTAVAILは単体の設定ミスだけでなく、構成（NW・デプロイ・セキュリティ）の相互作用として出ることがあるからです。たとえば「IPv6を半端に無効化」「VPN導入で経路が変化」「クラスタ切替でVIPが遅れて付与」「その上でアプリが送信元固定」などが重なると、表面的なログは同じでも、根の原因は一つではありません。

---

“場を整える”ための最終チェックリスト

最後に、現場で「何から手を付けるべきか」を迷ったときの、順序つきチェックリストを置いておきます。これは“最短復旧”ではなく、“被害最小化”と“説明可能性”を優先した順番です。

1. bindなのかconnectなのかを確定（ログ／スタックトレース／対象プロセスの挙動）
2. IPが存在するか（ip -br addr、コンテナならコンテナ内で）
3. 経路と送信元選択（ip route get、ip rule）
4. 接続状態とポート消費（ss -s、TIME_WAITの増え方）
5. 起動順序（network-online、ExecStartPreの存在確認）
6. 変更は最小・可逆・観測付きで行い、変更前後の状態を記録

ここまでやっても原因が一つに絞れない、あるいは「構成上、指定を契約として握る必要がある」場合、無理に一般論で押し切るのは危険です。契約・案件・セキュリティ要件（分離境界、到達制御、監査、復旧手順）を含めて設計し直したほうが、結果として運用負荷が下がるケースは少なくありません。

そのときに頼れる相談先があるかどうかで、現場の消耗は大きく変わります。ネットワーク・OS・アプリ・運用の境界をまたぐ問題ほど、第三者視点で“前提の衝突”を見つけるのが早いです。個別案件で「どの指定が契約で、どの指定は捨てるべきか」を整理したい場合は、株式会社情報工学研究所への相談・依頼を検討してください（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983 ／電話：0120-838-831）。

　

付録：主要プログラミング言語別に見たEADDRNOTAVAIL周辺の注意点

同じEADDRNOTAVAILでも、言語やランタイムの“標準ライブラリの作法”でハマりどころが変わります。ここでは、特定のフレームワークに依存しない、比較的普遍的な注意点をまとめます（バージョン差があるため、最終的には利用中のランタイム／OS設定で検証してください）。

---

C / C++（POSIXソケット）

• bindの失敗を握りつぶさない：EADDRNOTAVAIL/EADDRINUSE/EACCESなどを区別してログに残す（原因究明速度が変わります）。
• アドレスファミリの整合：IPv4/IPv6で sockaddr_in/sockaddr_in6 の扱いを混ぜない。
• SO_REUSEADDR等の意味を誤解しない：EADDRNOTAVAILの根本解決にはならず、別の症状を見えにくくすることがあります。

Java（JVM系）

• DNS/名前解決とキャッシュ：JVMはDNSキャッシュの方針が環境で変わり得るため、切替（LB/フェイルオーバー）時の挙動を確認する。
• IPv6/IPv4の優先：環境差が出るなら、JVMオプションやOS側方針で“どちらを使うか”を統一し、半端な状態にしない。
• HTTPクライアントの接続再利用：短命接続が増えるとポート消費が進むので、プール／keep-alive／タイムアウトを明示して運用する。

Go

• Listenの指定：":8080" のようにホスト部を空にすると全IF待受になり、IP固定bind事故を避けやすい（要件が無いなら有効）。
• Dialのタイムアウト設計：タイムアウトなしの再試行や、ゴルーチン大量生成で接続試行が増えると、短命接続が増えて状況を悪化させることがある。
• 解決結果の扱い：LB配下では宛先が変わる前提なので、再解決やリトライの設計を“増幅しない形”にする。

Python

• socketのデフォルト挙動差：IPv4/IPv6の扱いはOS設定や呼び出し方で変わるため、bind先（0.0.0.0/::）の意図を明確にする。
• requests/urllib系の再試行：再試行を安易に増やすと、障害時に接続が増えて一時ポート消費を進めることがある。バックオフ＋上限を設計する。
• プロセス/スレッド増加時の副作用：ワーカー数増で短命接続が増えると、connect側の問題を誘発しやすい。

Node.js（JavaScriptランタイム）

• HTTP Agentのkeep-alive：外向きHTTPが多い場合、keep-aliveやコネクションプールの有無で短命接続量が大きく変わる。
• dns.lookupの扱い：名前解決結果やIPv6/IPv4優先が環境で揺れると、成功/失敗が不安定になりやすい。環境差があるなら方針を統一する。
• 障害時の即時リトライ連打を避ける：イベントループ上で高頻度再試行すると、状況の増幅が起きやすい。

Ruby

• 短命接続の増幅：外部API呼び出しやDB接続を都度張り直す設計は、障害時に接続試行が増えてポート消費を進めやすい。プール・再利用を検討する。
• IPv6/IPv4差：OS設定とアプリの前提がズレると、環境ごとの差が出る。運用方針を決めて揃える。

PHP

• FPMワーカー増による外向き接続増：ワーカー数増＝同時外向き接続が増え、短命接続が多いと一時ポート消費が進みやすい。
• タイムアウト/再試行の設計：外部API障害時に再試行が増えると、状況を悪化させることがある。上限とバックオフが重要。

.NET（C#など）

• HttpClientの使い方：短命に生成・破棄を繰り返すと、接続再利用が効かず短命接続が増えやすい。再利用前提の設計に寄せる。
• DNS/切替の扱い：LB配下で宛先が変わる場合、名前解決や接続再利用の挙動が障害時の“揺れ”につながることがあるため、検証と監視が必要。

---

付録の結論も、第10章と同じです。言語が違っても、結局は「指定は契約」「契約が無いなら前提にしない」に帰結します。環境（RHEL、NetworkManager、コンテナ、クラスタ、経路制御、IPv6方針）とアプリの指定が衝突している場合、一般論の設定メモだけでは限界があります。

「うちの構成だと、どこを固定し、どこを捨てるのが安全か」「再発しない監視・手順・設計書まで含めて整えたい」といった個別案件の整理が必要なら、株式会社情報工学研究所への相談・依頼を検討してください（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983 ／電話：0120-838-831）。