Red Hat EAFNOSUPPORT (97) 対策: “Address family not supported by protocol” エラー発生時のアドレス指定再確認対策編

【注意書き】本記事は、Red Hat（Linux）環境で発生する EAFNOSUPPORT (97): “Address family not supported by protocol” の一般的な原因整理と切り分け手順を解説するものです。実際の最適解は、OS設定（IPv6有効/無効、名前解決順序、ネットワーク構成）、アプリ実装（socket/getaddrinfoの使い方）、実行環境（コンテナ/仮想化/クラウド）、運用要件（可用性、監視、変更管理）で変わります。個別案件の設計判断や障害対応はリスクが大きいため、必要に応じて株式会社情報工学研究所のような専門家へご相談ください。

　

その接続、なぜ急に死ぬ？「EAFNOSUPPORT(97)」が出る瞬間を正しく言語化する

現場でこのエラーに出会うと、まずこう思いがちです。「プロトコルって言われても…TCPなのかUDPなのか？」「昨日まで動いてたのに何が変わった？」。そしてログには、短い一行だけが残ることが多い。

EAFNOSUPPORT (97) は、Linuxの errno の一つで、直訳すれば「アドレスファミリが（その操作で）サポートされていない」です。ポイントは“アドレス”で、TCP/UDPやポート番号以前に、IPv4/IPv6などの“アドレスの型”が噛み合っていないときに、ソケット層で拒否される類のエラーです。

---

よくある発生箇所は、次のどれかです（アプリやライブラリによって表現は異なります）。

• connect()：接続先アドレスのファミリが不一致、またはOS側でそのファミリを使えない状態
• bind()：待受け（バインド）しようとしたアドレスが、作成したソケットのファミリと不一致
• sendto()：UDPなどで宛先アドレスのファミリが不一致
• 高水準言語の例外：Python/Java/Goなどで、内部的には上記のどれかが失敗している

「分かってくれないよなあ」という話をするなら、運用側から見ると“ネットワーク障害の顔をして、実はアプリとOSの契約違反”という点が厄介です。疎通確認（ping/curl）では問題が見えないのに、特定のプロセスだけ落ちる、という形で出ることがあります。

まず最初に押さえるべきは、EAFNOSUPPORTは“回線断”や“相手が落ちた”という話より前に、ローカルのソケット操作が成立していない可能性が高い、ということです。ここを腹落ちさせるだけで、切り分けのスピードが大きく変わります。

---

本記事では、原因を大きく次の3カテゴリに分けて説明します。

カテゴリ	典型パターン	まず見る観測点
アプリ実装	AF_INET固定/AF_INET6固定、getaddrinfoの使い方が不適切	ログ/例外、ソース、起動引数、環境変数
OS設定	IPv6無効化、名前解決順序、NIC/経路の偏り	sysctl、ip/ss、/etc/resolv.conf、/etc/gai.conf
実行基盤	コンテナでIPv6未提供、Dual-Stack前提の崩壊	namespace、CNI、Pod/NodeのIPファミリ

次章からは、まず“アドレスファミリ”という言葉の正体を、実装目線で具体化します。

　

errno 97 の正体：EAFNOSUPPORTは「IPv4/IPv6の型不一致」を疑うべき設計シグナル

Linuxソケットでは、ソケット作成時に アドレスファミリ（代表例：AF_INET=IPv4、AF_INET6=IPv6）を指定します。ここで指定した型に対して、後続の bind/connect で渡す sockaddr（アドレス構造体）も一致している必要があります。

つまり、雑に言うとこうです。

• AF_INET のソケットに対して、IPv6アドレス（sockaddr_in6）を渡す → 不一致
• AF_INET6 のソケットに対して、IPv4アドレス（sockaddr_in）を渡す → 不一致

この不一致が、EAFNOSUPPORTの最頻出パターンの一つです（実際にはEADDRNOTAVAIL等が出るケースもありますが、いずれにせよ“アドレスの扱い”が主語です）。

---

もう一段、現場でややこしいポイントがあります。IPv6ソケットがIPv4も受けられる（IPv4-mapped IPv6）という挙動が環境や設定で変わる点です。

• IPv6ソケットがIPv4も受けるように見える環境（デフォルトや設定に依存）
• IPv6ソケットがIPv4を受けない環境（net.ipv6.bindv6only 等の影響）

この差があると、「開発環境では動くのに本番（RHEL）でだけ落ちる」という症状が出ます。つまりEAFNOSUPPORTは、単なるバグではなく、“環境差を吸収できていない設計”を炙り出す信号にもなります。

---

最初の切り分けは、原因追跡というより“不一致を言語化する”ことです。次の2点を、ログや設定から確定させてください。

• アプリはどのファミリのソケットを作っているか？（AF_INET/AF_INET6/AF_UNSPEC）
• 実際に渡している接続先/待受け先アドレスは何か？（IPv4かIPv6か、名前解決で何が返っているか）

この2点が噛み合っているなら、EAFNOSUPPORTは出にくい。逆に言えば、ここが噛み合っていない限り、ネットワーク機器やFWを疑っても前に進みません。

---

次章では、まず“今日の現場で最短で効く”一次切り分けの手順を、コマンド中心に整理します。

　

最初の伏線：IPv4/IPv6・名前解決・バインド先——まず疑うべき3点チェック

「また新しいツール？どうせ運用が増えるだけじゃないの」。その感覚は健全です。EAFNOSUPPORTは、闇雲にツール導入するより、観測点を3つに絞るほうが早いケースが多いです。

まずは次の3点を順番に確認します。ここは“犯人探し”ではなく、“事実の確定”です。

1) OSとしてIPv6を使える状態か（無効化されていないか）

IPv6を前提にした挙動（AAAAが優先される、IPv6でconnectする等）なのに、OS側でIPv6を無効化していると、アプリの実装次第でEAFNOSUPPORT相当の失敗になります。

• sysctlで無効化：net.ipv6.conf.all.disable_ipv6 など
• カーネルパラメータ：ipv6.disable=1（起動時）

確認例（一般的な例）：

• ip -6 addr でIPv6アドレスが付いているか
• sysctl net.ipv6.conf.all.disable_ipv6 等で状態を見る

---

2) 名前解決で何が返っているか（A/AAAA、順序）

アプリがホスト名で接続している場合、裏では getaddrinfo が A/AAAA を引き、優先順で接続候補を試します。ここで AAAA（IPv6）が返るのに、アプリがIPv4固定（AF_INET固定）だと、噛み合わなくなります。

確認例：

• getent ahosts example.com（glibcの名前解決経路に近い見え方）
• dig A example.com / dig AAAA example.com（DNSレコードの事実確認）

特に“社内DNSの運用変更”“LBの設定変更”“DNSのAAAA追加”などは、「アプリ側は変えてないのに急に壊れた」を作りがちです。EAFNOSUPPORTが出たら、まずDNSの返り値の変化を疑う価値があります。

---

3) bind（待受け）先の指定が適切か（0.0.0.0 と :: の混線）

サーバプロセスが落ちる場合、bind()の失敗が原因のことがあります。IPv4で待つなら 0.0.0.0（INADDR_ANY）、IPv6で待つなら ::（in6addr_any）というように、アドレスの“型”を揃える必要があります。

確認例：

• ss -ltnp で実際にどのアドレスファミリでLISTENしているか
• 設定ファイルで listen 0.0.0.0 と listen [::] が混在していないか

---

この章の結論はシンプルです。EAFNOSUPPORTの切り分けは、まず「OSがIPv6を使えるか」「名前解決で何が返るか」「bind/connectの指定が何か」を事実として確定させる。ここまでで、多くのケースは“次に見るべき場所”が自然に決まります。

　

getaddrinfo の罠：AAAAが返るのにAF_INET固定（またはその逆）で起きる設計ミスマッチ

“プロトコルに対応していない”と書かれるので誤解されやすいのですが、実際に多いのは getaddrinfo の結果と、ソケット作成時のファミリ指定が一致していないパターンです。

典型的には次のような状況です。

• DNSにAAAAが追加された（あるいは社内DNSがIPv6を返すようになった）
• アプリは AF_INET固定でsocket() を作っている
• しかし getaddrinfo はAAAA（IPv6）を返し、アプリ側がその結果をうまく落とせない

逆に、アプリがAF_INET6固定で作っているのに、IPv6が無効化されている/提供されていない（コンテナ基盤など）場合も同様に崩れます。

---

“AF_UNSPECで投げて全部試す”は万能ではない

「じゃあAF_UNSPECでgetaddrinfoして、返ってきた順にconnectすればいい」と考えるのは自然です。ただし、現実には次の条件で挙動がブレます。

• OSのIPv6有効/無効
• 名前解決の経路（/etc/nsswitch.conf、DNS、/etc/hosts）
• アドレス選択（RFCの優先順位に基づく実装、/etc/gai.confの影響）
• アプリが“最初の1個だけ使う”実装になっている（フォールバックしない）

このため、設計としては「返ってきた候補を試す」だけでなく、試した事実をログに残すことが重要になります。EAFNOSUPPORTは、失敗した“理由”がログに残らないと、翌年また同じ事故が起きます。

---

現場で効く観測：glibc経路に近い見え方で確認する

DNSのdig結果だけで判断すると、実際のアプリの名前解決経路とズレることがあります（/etc/hosts優先、mDNS、LDAP等が絡む場合）。RHEL系で現場的に使いやすいのは、次の確認です。

• getent hosts ホスト名（最低限の確認）
• getent ahosts ホスト名（A/AAAAの列挙と順序の確認に有用）

そして、接続失敗時には「どのアドレス（v4/v6）を試したのか」「それぞれの結果はどうだったのか」をログに出せる設計が、運用品質を底上げします。

---

この章の帰結は、設計の話に着地します。EAFNOSUPPORTを“たまたまの障害”として扱うと再発します。名前解決結果（A/AAAA）とソケットファミリ（AF_INET/AF_INET6）を一致させる、そして候補の試行と失敗理由をログ化する。ここまで揃うと、同じ種類の事故が“調査不能”になりません。

　

bind/connect の再点検：0.0.0.0 と ::、指定IPの“型ズレ”を潰す（再発を減らす実務）

「設定は変えてないのに落ちた」と言われたとき、現場はこう思いますよね。“それ、誰がどこで変更したの？”。でもEAFNOSUPPORTは、変更がなくても環境が返すアドレス（A/AAAA）や優先順が変わるだけで発火します。

この章では、アプリ（あるいはミドルウェア）の設定と実装で頻出する“型ズレ”を潰します。見てほしいのは次の2箇所です。

• 待受け（bind/listen）：どのアドレスにバインドしているか（0.0.0.0 / :: / 特定IP）
• 接続（connect）：接続先がホスト名か、IP直書きか（IPv4/IPv6の混在）

---

待受け側：0.0.0.0 と :: は“似ているが別物”

IPv4で全IF待受けは 0.0.0.0（INADDR_ANY）、IPv6で全IF待受けは ::（in6addr_any）です。問題は、設定ファイルやコードの中で、この2つが曖昧に扱われやすいことです。

意図	典型設定/指定	ズレたときの症状
IPv4で待受け	0.0.0.0 / 特定IPv4	IPv6アドレスで来た接続は想定外（別経路で失敗）
IPv6で待受け	:: / 特定IPv6	環境や設定によりIPv4を受けない（v6only）／挙動差が出る
両対応（Dual-Stack）	IPv4/IPv6双方で待受け（明示的に二重でlisten等）	片方だけ設定して“両方のつもり”になっていると事故る

ここで重要なのは、「IPv6ソケット1本でIPv4も受けられる」という挙動が、環境や設定（例：v6only関連）で変わり得る点です。つまり「開発機では1本で動いた」が「RHEL本番では片側が落ちる」を作ります。

---

接続側：IP直書きとホスト名の“混在”が地雷になる

接続先をホスト名で書くなら、名前解決の結果（A/AAAA）に追従する設計が必要です。一方、運用で「とりあえずIP直書き」にすると、次の矛盾が生まれます。

• 設定A：ホスト名（AAAAが返る） → アプリはIPv6で繋ぎに行く
• 設定B：IPv4直書き（A相当） → アプリはIPv4で繋ぎに行く

同じサービスでも、クライアントや環境変数、設定ファイルの差でA/Bが混在し、障害時に“再現しない”状態を作ります。現場が一番困るやつです。

---

現場での“まずこれ”チェック（短時間で事実を固定する）

次の観測で、待受けと接続のファミリ不一致を素早く確定できます。

• ss -ltnp：LISTENしているアドレスが 0.0.0.0 なのか :: なのか
• ss -tnp：接続しようとしている宛先がIPv4/IPv6どちらか（失敗直後の状態確認）
• ip addr / ip -6 addr：そもそもそのIFに該当ファミリのアドレスがあるか

「また監視項目増えるのか…」と感じるのは自然です。ただ、EAFNOSUPPORTは“型の不一致”が再発条件なので、設定レビューのチェックリストに落とすだけで、障害の再現性が上がります。

---

この章のまとめは、“曖昧さを残さない”です。待受けはIPv4/IPv6のどちらで、接続は何を解決し、どの順に試すのか。ここを仕様として固定すると、EAFNOSUPPORTは「たまに出る謎のエラー」から「設計で管理できる現象」に変わります。

　

OS設定の落とし穴：disable_ipv6・名前解決順序・経路で“選ばれるアドレス”が変わる

EAFNOSUPPORTの厄介さは、アプリが同じでもOSの設定差で結果が変わるところです。現場エンジニアの本音としてはこうですよね。「“環境依存です”って言われるのが一番つらい」。

ここでは、Red Hat系を含むLinuxで“選ばれるアドレス”に影響する代表的な要素を、運用で触りがちな順に整理します。

---

1) IPv6を無効化していないか（意図せず使えない状態）

IPv6が無効化されていると、AAAAが返っても接続できない／そもそもIPv6ソケットが期待通り動かない、といった状況になります。無効化の方法は複数あり、運用のどこかで入っていることがあります（過去の脆弱性対応、テンプレート適用、セキュリティベースライン等）。

• sysctl（例：net.ipv6.conf.all.disable_ipv6）
• カーネル起動パラメータ（ipv6.disable=1 等）
• ネットワーク管理（NetworkManager等）側の設定方針

重要なのは「無効化が正しい/悪い」ではなく、アプリの前提と一致しているかです。IPv6を使わない方針なら、アプリもDNSもそれに揃える（AAAAを返さない、AF_INET固定、など）必要があります。

---

2) 名前解決の順序（OSが“どっちを先に試すか”）

ホスト名からアドレスを解決する場合、OS（正確にはライブラリと設定）が、IPv4とIPv6のどちらを優先するかに影響します。ここでの観測は「DNSに何があるか」だけでは足りないことがあります。

• /etc/hosts：ローカル固定の影響（運用で応急処置すると残りやすい）
• /etc/nsswitch.conf：名前解決の経路（files/dns等）
• /etc/resolv.conf：参照DNS、searchドメイン、タイムアウト
• /etc/gai.conf：アドレス選択（優先順位）に影響し得る

現場で効く確認としては、前に出した getent ahosts のように、アプリに近い経路で「何がどの順で出るか」を見るのが有効です。

---

3) 経路（ルーティング）とインターフェース：到達可能性の差が“挙動差”になる

IPv6アドレスが付いていても、IPv6のデフォルトルートがない／到達性がない、という環境は現実にあります。アプリがIPv6を優先して試す設計だと、ここで“まずIPv6で失敗してからIPv4へフォールバック”の挙動になり、タイムアウトや遅延が増えます。

この状態そのものは、必ずしもEAFNOSUPPORTを直接出すわけではありません。しかし、運用上は「最初に選ばれたアドレスが何だったか」を確定させないと、“同じ接続失敗”が別のエラーとして見えるようになります。調査コストが上がる典型です。

観測の基本は次です。

• ip -6 route：IPv6のルーティングが成立しているか
• ip route：IPv4側との違い
• ss -tnp：どの宛先に向けて試行しているか

---

この章の結論は、環境差を“設計で吸収するか、方針で排除するか”です。Dual-Stackにするなら、名前解決・優先順・経路を含めて整合させる。IPv4のみで行くなら、DNS/設定/実装をIPv4前提に寄せて曖昧さをなくす。一般論としてはここまでですが、実際は組織のネットワーク方針・セキュリティ基準・更改計画が絡むので、個別案件では専門家に相談して設計判断を固めるのが安全です。

　

firewalld/SELinuxで混線する類似症状：EAFNOSUPPORTと“別の失敗”を同時に切り分ける

ここは現場の感情から入ります。障害対応で一番しんどいのは、「原因が一個じゃない」ときです。「なんか最近、FW厳しくなったよね」「SELinuxの通知増えたよね」——そういう背景があると、EAFNOSUPPORTも全部そこに吸い込まれます。

ただ、事実として押さえておきたいのは次です。

• EAFNOSUPPORTは“アドレスファミリ不一致”が主語で、通信の前段（ローカルのソケット操作）で起きやすい
• firewalldは主にパケット通過を制御するため、典型的には別のエラー（タイムアウト等）になりやすい
• SELinuxは権限・ポリシー違反で止めるため、典型的には権限系（Permission denied等）になりやすい

つまり、EAFNOSUPPORTそのものをFW/SELinuxだけで説明できるケースは多くありません。とはいえ、障害時は複数の問題が同時に出るので、混線した状態を手早く整理するのが大事です。

---

症状を“エラー種別”で切り分ける（最短で迷いを減らす）

観測される失敗	主に疑う領域	次の一手（例）
EAFNOSUPPORT	アドレスファミリ不一致、IPv6無効化、名前解決結果と実装のズレ	getent/ss/ip、設定とソケット実装の確認
タイムアウト（到達しない）	FW/経路/相手側待受け/セキュリティグループ等	疎通、FWルール、経路、LISTEN確認
Permission denied / EACCES系	SELinux/権限/特権ポート/ケーパビリティ	AVCログ、getenforce、ポート割当の見直し

この表の意図は、「FWやSELinuxを疑うな」ではありません。“同じ画面の中に複数の失敗が並ぶとき、優先順位をつける”ための道具です。

---

firewalldの確認（混線をほどく最低限）

通信が絡む障害で、firewalldの状態を“見ない”のは危険です。ただし、EAFNOSUPPORTを見ているときは、firewalldは主因というより同時要因として扱う方が現場的に早いことが多いです。

• 許可ポート/サービスの確認：firewall-cmd --list-all
• ゾーンやインターフェースの紐付け：運用方針により差が出る

重要なのは、待受けがIPv4/IPv6どちらなのか（ss -ltnp）と、firewalldの許可がどちらを想定しているかを一致させることです。

---

SELinuxの確認（“原因っぽいが別件”を早期に外す）

SELinuxが原因の場合、典型的には監査ログ（AVC）に痕跡が残ります。アプリ側のログが曖昧でも、監査ログは比較的“事実”が取りやすいことがあります。

• 現在のモード確認：getenforce
• 監査ログの確認：ausearch -m avc -ts recent（環境により利用可否あり）

「とりあえずPermissiveにして動いたからOK」とすると、長期的に事故ります。EAFNOSUPPORTの本筋（アドレスファミリ不一致）と、SELinuxによる拒否（権限・ポリシー問題）は、別の論点として切り分けて対処するのが安全です。

---

この章のまとめは、“混線をほどく”です。EAFNOSUPPORTはアドレスファミリ不一致が主語。FW/SELinuxは同時に問題を起こし得るが、エラーの性質から優先順位を付けると調査が速くなります。ここまでの一般論で確定できない場合、ネットワーク設計・運用ポリシー・セキュリティ基準が絡むので、個別案件として株式会社情報工学研究所のような専門家に切り分け設計から相談するのが現実的です。

　

コンテナ/仮想化で増えるパターン：Dual-Stack未対応と「基盤が提供していないIPv6」を踏む

ここは現場の“ため息ポイント”です。開発はローカルPCやVMで動いていた。CIも通っていた。なのに本番のコンテナ基盤に載せた瞬間、急にEAFNOSUPPORTが出る。こういうとき、現場の頭の中はだいたい同じです。「また基盤差か…」「結局、誰が何を保証しているんだっけ？」。

結論から言うと、コンテナやKubernetesでは“ホストOSが持つネットワーク能力”と“コンテナ/Podに提供されるネットワーク能力”が一致しないことがあります。このズレが、アドレスファミリの不一致（またはIPv6が使えない状態）を引き起こし、アプリの実装によってはEAFNOSUPPORT相当の失敗として表面化します。

---

よくあるズレ①：ホストはIPv6有効だが、コンテナネットワークはIPv4のみ

ホスト側でIPv6が使えても、コンテナのネットワーク（bridge、CNI、Podネットワーク）がIPv4のみで構成されていることは珍しくありません。その状態で、接続先ホスト名のDNSにAAAAがあり、アプリがIPv6を優先して試す設計だと、次のような流れになります。

• DNSでAAAAが返る（IPv6候補がある）
• アプリはまずIPv6でconnectしようとする
• コンテナ側にIPv6の到達性がない、あるいはIPv6が提供されていない
• フォールバックがない/不十分だと、失敗がそのまま障害になる

このとき出るエラーはEAFNOSUPPORTだけに限りません（到達性がないならタイムアウト系になることもあります）。ただし、アプリがIPv6前提でソケットを作り、IPv4のアドレス構造体を渡してしまうなど、“型ズレ”が混ざるとEAFNOSUPPORTが顔を出しやすくなります。

---

よくあるズレ②：Kubernetesはシングルスタック運用なのに、アプリはDual-Stack前提

KubernetesにはIPv4のみ、IPv6のみ、Dual-Stackといった構成があり、クラスタやCNIの設定に依存します。ここで起きがちなのが、

• クラスタ（Podネットワーク）はIPv4のみ
• 一方で社内DNS/外部DNSはAAAAも返す
• アプリ（またはライブラリ）が“Dual-Stack想定の実装”になっている

という構図です。つまり、アプリは「IPv6で行けるはず」と判断する材料（AAAA）を持っているのに、実行基盤は「IPv6は提供していない」。この矛盾は、構成管理が曖昧だと本番で初めて顕在化します。

---

よくあるズレ③：コンテナ内のsysctlや権限が制約され、期待したネットワーク設定にできない

「じゃあコンテナ内でIPv6を有効化すれば？」と思うのは自然です。ただ、コンテナでは権限や名前空間の制約で、期待通りにsysctlが反映されないことがあります。また、ホスト側でIPv6が無効化されている場合、コンテナ側だけで解決できないこともあります。

この手の問題は、アプリ実装の修正だけではなく、基盤側の提供範囲（IPv6提供有無、Dual-Stack対応、CNIの設定）と、DNSが返す情報（A/AAAA）を含めて整合させる必要があります。

---

実務の着地点：基盤の“提供能力”を仕様として明文化する

コンテナ/仮想化でのEAFNOSUPPORT対策は、気合いでログを追うより先に、次の問いを仕様として固定すると進みます。

• 本番基盤はIPv6を提供しているのか？（Pod/コンテナから外部への到達性まで含む）
• DNSはAAAAを返す運用なのか？（返すなら、アプリはそれを前提にしてよいのか）
• アプリはIPv4-onlyかDual-Stackか？（“たぶん両方”をやめる）

「現場は止められない」「移行コストは増やしたくない」という本音があるなら、なおさらです。基盤・DNS・アプリの責任分界を曖昧にすると、障害が“運用の負債”として残り続けます。

　

ログで確定させる：strace/ss/ip/getentで「実際に何が選ばれたか」を証拠にする

EAFNOSUPPORTが厄介なのは、原因が“推測”で語られやすい点です。「IPv6が怪しい」「DNSが怪しい」。それ自体は方向性として正しいことも多いのですが、障害対応を早く終わらせるには、“実際に何を選んで失敗したか”を証拠として残すのが最短です。

ここでは、Red Hat系のLinux運用で取りやすい観測を、目的別に整理します。ポイントは、アプリの主張ではなく、OSが見た事実を拾うことです。

---

目的	観測コマンド例	分かること
名前解決の事実	getent ahosts <host>	A/AAAAの列挙と順序（glibc経路に近い見え方）
待受けの事実	ss -ltnp	LISTENしているアドレスがIPv4(0.0.0.0等)かIPv6(::等)か
接続試行の事実	ss -tnp	どの宛先（v4/v6）へ向けて接続しようとしているか
IP/経路の事実	ip addr / ip -6 addr / ip route / ip -6 route	そのホスト（またはnamespace）がIPv4/IPv6を持ち、到達可能な経路があるか
システムコールの事実	strace -f -e trace=network -p <pid>	socket()/connect()/bind()がどのファミリで呼ばれ、何で失敗したか

---

“再現させた直後”の黄金パターン：3点を1セットで記録する

障害は再現しないことがあります。だからこそ、再現した瞬間に“セット”で証拠を取る設計が大事です。運用手順としては次の3点を同じタイムスタンプで残すのが強いです。

• getent ahosts（その瞬間に何が返っていたか）
• ss -ltnp / ss -tnp（待受けと接続がどのファミリだったか）
• strace（networkのみ）（OSが見た失敗理由が何か）

「そんなの毎回やるのは無理」と感じるのも自然です。だからこそ、プロセスに組み込むなら、障害時だけ実行する簡易スクリプト化や、SREのランブックに落とし込むのが現実的です。

---

straceで見るべきポイント（“どの型を渡したか”に集中する）

straceを使う目的は、膨大なログを眺めることではありません。EAFNOSUPPORTでは、次の2つが分かれば十分なことが多いです。

• socket() が AF_INET で作られているのか、AF_INET6 で作られているのか
• connect()/bind() に渡している宛先/待受けが、そのファミリと一致しているのか

ここが一致していないなら“型ズレ”が主因です。一致しているのに失敗するなら、IPv6の無効化や基盤の提供範囲、名前解決順序など、上流の設計・運用条件に論点が移ります。

---

この章の帰結は、「推測を終わらせる」ことです。EAFNOSUPPORTを調査するときは、何が選ばれ、何が渡され、何で落ちたかを証拠化すると、議論が“責任の押し付け”ではなく“設計の修正”に変わります。次章では、その設計修正をチェックリストとしてまとめます。

　

帰結：アドレス指定を“契約”にすると障害が減る——再発防止チェックリストと一般論の限界

ここまで読んで「結局、IPv6を切ればいいの？」「いやDual-Stackで行くべき？」と感じた人もいると思います。正直、その迷いは健全です。現場の本音としては、“正解が一つじゃない話を、障害の夜に判断させないでほしい”んですよね。

だからこの章の結論は、技術論というより運用設計です。EAFNOSUPPORTの再発を減らすには、アドレスの扱いを「その場のノリ」ではなく、契約（仕様）に落とします。つまり、基盤・DNS・アプリの前提を一致させ、曖昧さを残さない。

---

再発防止チェックリスト（設計として固定する項目）

• 本番はIPv4-onlyかDual-Stackか（方針を明文化し、例外条件も書く）
• DNSはAAAAを返すのか（返すなら、どのサービスが対象か／返さないなら、なぜ返さないのか）
• アプリは接続先をホスト名にするかIP直書きにするか（混在させない。混在するならルール化する）
• サーバの待受けはIPv4/IPv6のどちらか、両方か（両方なら“明示的に両方待つ”設計を採る）
• 名前解決結果（候補）を試すロジック（最初の1個だけで決めない／失敗理由をログ化する）
• 障害時の証拠採取手順（getent/ss/ip/strace をセットで残す）

---

運用で効く“最低限のログ設計”

押し売りのツール導入より、まずログの出し方を整えるほうが費用対効果が高いことが多いです。EAFNOSUPPORTを再発させないために、最低限ログに残したいのは次です。

• 接続先がホスト名なら、解決されたアドレス一覧（v4/v6）と、どれを選んだか
• 待受けなら、実際にbindしたアドレス（0.0.0.0なのか::なのか、特定IPなのか）
• 失敗時は、失敗したアドレスとerrno（EAFNOSUPPORT等）を記録する

これだけで、次に同じ事故が起きても「再現しない」「議論が噛み合わない」を大幅に減らせます。

---

一般論の限界：方針（IPv4-only/Dual-Stack）は“組織の事情”とセットで決まる

ただし、ここから先は一般論だけでは決めきれません。IPv6を使う/使わないは、単に技術の好みではなく、

• 社内ネットワークの方針（アドレス設計、ルーティング、監視）
• セキュリティ基準（FW/IDS/ログ保全、変更管理）
• 基盤の提供範囲（Kubernetes/CNI、クラウドLB、DNS運用）
• 止められない既存システムの制約（レガシー、依存関係）

と結びつきます。つまり、技術的に正しそうでも、運用と契約条件に合わないと“現場の負債”になります。

だから最後は自然にここに着地します。読者が具体的な案件・契約・システム構成で悩んだときは、個別条件（基盤、DNS、アプリ、運用）を踏まえて設計判断を固める必要があります。一般論のチェックリストで迷いが減った段階で、株式会社情報工学研究所のような専門家に相談し、現場の事情に合う最短ルート（方針・実装・運用手順）を一緒に決めるのが、結果としてコストとリスクを下げます。

　

付録：主要プログラミング言語別の注意点（EAFNOSUPPORT/アドレスファミリ不一致を起こさない実装・運用）

最後に、「同じ設計ミスが、言語が違うだけで形を変えて再発する」ことを防ぐために、主要言語ごとの注意点を整理します。ここで言いたいのは“言語の優劣”ではなく、各言語・標準ライブラリが持つ流儀（名前解決、アドレス選択、フォールバック）を理解しておくと、EAFNOSUPPORT系の事故が減るということです。

また、これらは一般論です。実際には、Red Hat側のIPv6有効/無効、DNS運用（A/AAAA）、コンテナ基盤の提供範囲、監視・ログ保全要件などが絡むため、個別案件では株式会社情報工学研究所のような専門家と一緒に、要件→設計→実装→運用手順まで整合させるのが安全です。

---

言語	起きがちな落とし穴	実務での対策（要点）
C / C++	AF_INET固定のsocket()にIPv6結果を渡す、sockaddr構造体の取り違え、v6only挙動差を想定しない	getaddrinfo(AF_UNSPEC)→返却リストを順に試行、sockaddrを正しく扱う、ログに選択アドレスとerrnoを残す
Python	socket.getaddrinfoの結果を1件だけ使う、ホスト名とIP直書きが混在、コンテナでIPv6未提供なのにAAAA優先	getaddrinfo結果を複数試行（失敗理由も記録）、待受けはIPv4/IPv6の方針を明確化、例外にerrnoを含めて保存
Java	InetAddressの解決順（IPv6優先など）を意識せず本番で挙動差、JVMプロパティ/OS設定差を吸収できていない	本番のアドレス方針（IPv4-only/Dual-Stack）を決め、ログに解決結果を出す、環境差（OS設定・DNS）を前提にテスト
Go	net.Dialの“便利さ”に依存しすぎて、DNS/基盤差での失敗時に原因が見えない	接続先の解決結果・試行経路をログ化、IPv4/IPv6の方針を明文化、コンテナ/クラスタのIP提供範囲を確認
Rust	std::netの抽象化で“何が選ばれたか”がアプリログに残らない、外部クレートで挙動が変わる	解決アドレスと試行順を明示的に記録、失敗時はOSエラー（errno）を保存、運用手順に観測コマンドを組み込む
Node.js	dns.lookup結果・接続先のファミリ選択が見えにくい、環境依存でIPv6側に寄って落ちる	接続前に解決結果（A/AAAA）をログ化、接続失敗時の例外情報を詳細化、IPv4/IPv6方針を構成として固定
C# / .NET	Dns/Socketの抽象化で原因が隠れる、AddressFamilyの指定ミス、複数候補の扱いが不十分	AddressFamilyの整合性を担保、複数アドレス候補を試行しログ化、例外時にOSエラー情報を保持
PHP	stream_socket_client等での失敗理由がアプリ側ログに残らない、DNS/IPv6の環境差で突然失敗	名前解決結果を別途記録、接続先（ホスト名/IP）のルールを統一、運用でgetent/ssの証拠採取を定義

---

共通の注意点：言語をまたいで再発する“3つの負債”

言語が違っても、EAFNOSUPPORT系を呼び込む根はだいたい同じです。次の3つが揃うと、障害対応が長引きます。

• 方針が曖昧：IPv4-onlyなのかDual-Stackなのか、DNSはAAAAを返すのかが決まっていない
• 実装が“暗黙の1択”：解決結果の先頭だけ使う／フォールバックしない／選択したアドレスをログに残さない
• 基盤の提供範囲が不明：コンテナ/クラスタ/ネットワークでIPv6が「あるのかないのか」「どこまで到達できるのか」が設計書にない

これを避けるために、技術的には難しいことをする必要はありません。「何を前提にするか（契約）」「アプリが何を選んだか（ログ）」「本番が何を提供するか（基盤仕様）」を揃えるだけで、EAFNOSUPPORTの“謎”はかなり減ります。

---

最後に：一般論で止めるべき場所と、相談すべきタイミング

この記事で示したチェックリストや観測手順は、一次切り分けとして有効です。ただし、現実のBtoB環境では、DNS運用変更・ネットワーク更改・セキュリティ基準・コンテナ基盤の制約・可用性要件が絡み、「技術的に正しい」だけでは決められない局面が必ず出ます。

読者が具体的な案件（契約条件、監視/ログ要件、クラウド/オンプレ混在、Kubernetes導入、IPv6方針）で悩んだときは、一般論の延長で無理に決めず、株式会社情報工学研究所へ相談し、現場条件に合わせた“再発しない設計と運用”を一緒に固めることをおすすめします。障害対応の夜に判断を迫られる回数を減らすことが、結局いちばんのコスト削減になります。