はじめに
本記事では、AWS上の一般的な構成において「特定のクライアント環境でのみWebSocket接続に失敗する」という事象が発生した場合の、原因切り分けと分析プロセスの一例をケーススタディとして記録します。
CloudFront、ALB、EC2を利用した環境で、クライアントのIPv6設定がどのように影響しうるか、その一つのパターンとしてご参照ください。
内容
- 事象: IPv6が有効なクライアントから、特定のAWS環境上のWebアプリケーションにアクセスするとWebSocket接続に失敗。クライアントのIPv6を無効化すると事象が解消する、という報告があった。
- 分析: 調査の結果、この事象はCloudFrontのオリジン設定が「IPv4 Only」であり、かつクライアントがIPv6でアクセスした場合にのみ発生することが確認された。
- 考察: 特定の構成の組み合わせにおいて、WebSocketハンドシェイクが意図通りに完了しない可能性が示唆された。本件はAWSのサービスの不具合を示すものではなく、構成に起因する事象と捉えられる。
システム構成例と観測された事象
分析対象の環境構成
-
構成:
CloudFront→ALB→EC2 - CloudFrontオリジン設定: ALBへの通信を IPv4 Only に設定
観測された事象
クライアントのネットワーク設定によって、WebSocket接続の成否が変動するケースを想定します。
| クライアントのNW設定 | 想定される通信経路 | WebSocket接続結果（例） |
|---|---|---|
| IPv4 のみ有効 | Client(IPv4) → CF → ALB(IPv4) | 成功 |
| IPv6 のみ有効 | Client(IPv6) → CF → ALB(IPv4) | 失敗（エラー発生） |
| IPv4 + IPv6 両方有効 | （主に成功するが、状況により不安定） | 成功するケースが多い |
この結果からは、クライアントがIPv6でCloudFrontにアクセスし、CloudFrontがオリジンへIPv4で接続する経路において、何らかの接続課題が発生している可能性が推測されます。
原因分析のプロセス（一例）
1. 問題の切り分け
観測された事象に基づき、以下のように仮説を立てて分析を進めます。
-
クライアントがIPv4でアクセスする場合:
Client(IPv4) -> CloudFront -> ALB(IPv4)という経路になり、プロトコルスタックが一貫しているため、問題なく接続できると考えられます。 -
クライアントがIPv6でアクセスする場合:
Client(IPv6) -> CloudFront間の通信は正常に行われます。しかし、CloudFrontからオリジンへの接続がIPv4 Onlyであるため、CloudFrontはクライアントからのリクエストを受けて、オリジンへは新たにIPv4で接続を開始します。この構成において、WebSocketハンドシェイク（Upgrade: websocket）がオリジンまで到達しない、あるいはオリジンからの応答がクライアントまで返らない、といった事象が発生している可能性が考えられます。
「IPv4 + IPv6 両方有効」のクライアントで成功するケースが多いのは、多くのOSやブラウザが持つ接続最適化アルゴリズム（例: Happy Eyeballs）により、接続しにくいIPv6経路から、正常なIPv4経路へフォールバックするためと推測されます。
2. WebSocketハンドシェイクのシーケンス
WebSocket接続は、HTTPリクエストをアップグレードすることで確立されます。
-
クライアント → サーバー:
Upgrade: websocketヘッダーを含むHTTPリクエストを送信。 -
サーバー → クライアント: 要求を承諾する場合、
101 Switching Protocolsを返す。
今回のケースでは、CloudFrontがクライアント（IPv6）とオリジン（IPv4）の間でリクエストを中継する過程で、このハンドシェイクシーケンスが何らかの要因で阻害された可能性があります。
考察とまとめ
分析:
本ケーススタディの環境において、CloudFrontのオリジン設定が「IPv4 Only」の構成では、IPv6でアクセスしてきたクライアントとの間でWebSocket接続が確立しない事象が観測されました。
これは、特定のサービスに不具合があるという単純な話ではなく、アーキテクチャ上のプロトコルの違い（IPv6とIPv4）を中継するポイントで、WebSocketのような特殊なプロトコルが期待通りに動作しない場合がある、という一つの教訓を示しています。
本件から得られる技術的知見
-
中継コンポーネントの挙動理解:
CloudFrontのようなリバースプロキシやCDNは、単純なトラフィック転送以上の役割を担います。クライアントとオリジン間のプロトコル差異を吸収する際、特定のプロトコル（例: WebSocket）では特別な注意や設定が必要になるケースがあることを認識しておくことが重要です。 -
デュアルスタック環境でのテストの重要性:
クライアントがIPv4/IPv6のどちらでアクセスしてくるかによって、AWS内部の通信経路が変化する可能性があります。テストを行う際は、クライアントのネットワーク設定（IPv4のみ、IPv6のみ）を切り替え、各経路での動作を個別に確認することが問題の早期発見に繋がります。 -
問題の切り分けにおけるクライアント設定の有効性:
「IPv6を無効化すると直る」という情報は、単なる回避策ではなく、「IPv4経路とIPv6経路のどこに挙動の差異があるか」を特定するための重要な手がかりとなります。
クラウドの構成要素それぞれの設定が、全体の通信にどう影響するかを体系的に理解し、様々な条件下でのテストを行うことの重要性を示す一例と言えるでしょう。