iOS アプリの通常の HTTPS リクエストはデバッグ用プロキシに現れるのに、WebSocket のトラフィックが見えないことがあります。まず WebSocket の転送方式を特定します。URLSessionWebSocketTask はセッションレベルのプロキシ構成を利用できますが、独自にソケットを開くライブラリには独自の対応済み統合が必要です。iOS 17+ で生の Network.framework 接続を使う場合は、NWConnection 自身のプロキシコンテキストを構成します。

iOS 17 以降では、明示的な SOCKSv5 プロキシでセッションを作成します。

import Foundation
import Network

@available(iOS 17.0, *)
func makeDebugSession() -> URLSession {
    let configuration = URLSessionConfiguration.default
    let endpoint = NWEndpoint.hostPort(
        host: "192.0.2.10", port: 8889)
    configuration.proxyConfigurations = [
        ProxyConfiguration(socksv5Proxy: endpoint)
    ]
    return URLSession(configuration: configuration)
}

ドキュメント用のアドレスとポートを、既存のデバッグ用プロキシの到達可能な SOCKS リスナーに置き換えます。そのリスナーをプロキシアプリで有効にします。HTTP リスナーは別のポートでもかまいません。

返されたセッションから webSocketTask を作成します。別の URLSession で作成したタスクは、このセッションの上書きを継承しません。空の proxyConfigurations 配列はシステムの既定値を使うのであって、直接経路を明示的に選んだことにはなりません。

到達性と読めるメッセージは別々のマイルストーン

実機の電話には、デバッグ用コンピュータに届くアドレスが必要です。その電話では 127.0.0.1 は電話自身を指します。接続がまったく届かない場合は、リスナーのインターフェースとプロキシが許可するクライアントアクセスを確認します。

SOCKS の経路は接続を運びます。wss の内容を読むには、さらにデバッグツールの TLS 検査設定と端末側の適切な信頼が必要です。証明書ピン留めや別の TLS 実装があると、通信がリスナーに届いてもその検査を妨げることがあります。

接続が確立したら WebSocket のやり取りとメッセージを探します。Socket.IO アプリからのポーリング要求が 1 つだけ見えても、その後の WebSocket 転送が同じ経路を使った証拠にはなりません。この明示的なデバッグ構成は、アプリが想定する開発環境の範囲に留めてください。

関連記事