本稿では、Chromium Edge / Google Chrome の Proxy 経由時のネットワークのトラブルシューティングにも利用できる NetLog (net-export ログ) の基本を紹介します。基本的に Chromimum Edge を基に話しますが、ほとんどのケースで Google Chrome にも適用できると思います。今回は Windows OS のケースのみ記載します。

前提 : Proxy 設定

一般的な Windows OS の設定のプロキシセットアップページ、もしくは、インターネットオプションの設定で設定することが多いです。

もしくは、他のパターンとしては Edge 固有の設定である ProxySettings のポリシーで Edge 固有で設定したいプロキシ設定を実施します。

もし、前者の OS 側の設定やインターネットオプションではなく、後者の Edge のポリシーで設定している場合には、ポリシー自体が正常に設定できているかどうかは以下の edge://policy で確認可能です。

1. NetLog 取得・ログを開く

具体的な取得手順は net-export の使い方 (Japan Developer Support Internet Team Blog) で edge://net-export/ (Chrome の場合は chrome://net-export/) を開き、net-export の NetLog を取得開始・任意のサイトにアクセス再現・取得終了まで行います。

取得後、保存された JSON ファイルを netlog-viewer - https://netlog-viewer.appspot.com/ で開きます。左側に表示されるセクションを以下で紹介します。

なお、詳細は紹介しませんが、Wireshark による New Microsoft Edge のトレース取得方法にあるように "SSLKEYLOGFILE" 付きで、一緒に netsh や Wireshark でネットワークトレースを取得しておくとより効率的かつ網羅的にネットワークのログを見ることができるので同時に取得することをおすすめします。

2. Import セクション

[Build] カラムで Edge のバージョンが最新版であることを確認します。

3. Proxy セクション

Proxy セクションで設定されているプロキシ (Original proxy settings) と、実際に取得期間中に適用されたプロキシ設定 (Effective proxy settings) をそれぞれ確認します。PAC を利用している場合は PAC のアクセス先の URL や、プロキシを使用していない場合 (DIRECT 接続の場合) は　”Use DIRECT connections” と表示されます。

例えば、直接 PAC 指定しているものの、自動検出 (Auto-detect) による取得によって、意図した直接指定した PAC ではない場所から別の PAC を持ってきている場合には、Original proxy settings と Effective proxy settings で異なる PAC の取得先が表示されることが想定されます。

4. Events セクション (HTTP プロキシの利用の場合を想定)

例えば、HTTP_STREAM_JOB_CONTROLLER ソースの HTTP_STREAM_JOB_CONTROLLER_PROXY_SERVER_RESOLVED イベントでは、以下のように該当 URL へのアクセスに対してどの Proxy サーバーの接続先を利用したかどうかを具体的に確認する事が可能です。

もし Proxy を利用しているつもりが、以下のように DIRECT 接続になっている場合には、あらためてプロキシ設定が適切にされているかを確認することをおすすめします。

SOCKET ソースでは、TRANSPORT_CONNECT_JOB イベントではなく HTTP_PROXY_CONNECT_JOB イベントへのリンクも確認できます。

加えて、SOCKET ソースの TCP_CONNECT イベントの remote_address も宛先が Proxy になっていることが確認できます。

また、SOCKET ソース内から HTTP_STREAM_JOB ソースに遷移できる場合、HTTP_STREAM_JOB ソースに遷移します。さらに HTTP_STREAM_JOB ソース内で URL_REQUEST ソースに遷移できる場合、URL_REQUEST ソースに遷移します。ここでは、例えば正常系のレスポンスと比較して、HTTP レスポンスがアプリ側ではなく、例えば 503 等のエラーコードでかつエラーメッセージも Proxy 等の中間機器が返していると疑われるようなレスポンスが Proxy 側から返ってきていそうな場合は、Proxy 側の観点で何故その応答を Proxy が返却したか中間機器側での調査に移ります。

参考 : HTTP プロキシ経由で HTTP/2 や HTTPS アクセスした場合

ご参考までに、HTTP プロキシ (not HTTPS プロキシ) を利用した HTTP/2 アクセスの場合には HTTP2_SESSION のソースでどの Proxy を設定しているか確認できます。直接アクセスの場合は proxy = "DIRECT" と表示されます。ソース一覧内の該当 HTTP2_SESSION 項目の Description 欄でも簡易的に確認できます。

また、HTTP プロキシを利用した際の上記のような HTTP/2 や HTTPS の SOCKET イベントでは、通常の SSL_CONNECT や SSL_HANDSHAKE_MESSAGE_SENT の前に、HTTP_TRANSACTION_TUNNEL_SEND_REQUEST や HTTP_TRANSACTION_TUNNEL_READ_HEADERS イベントが存在することが想定されます。

具体的には、各イベントで、事前に CONNECT メソッドで Proxy へのトンネルを張って、結果的に成功している状況 (HTTP/1.1 200 Connection established) も確認できます。

ご参考までに、net-export から離れますが、SSLKEYLOGFILE で復号した場合のトレースを Wireshark で見た場合にも、以下のように該当する一連の TCP ストリームを見ることができます。

おわり

本稿ではあくまで一部のパターンの紹介や重要と思われる基本項目のみのご紹介ですが、少しでも Microsoft Edge の Proxy 関連のネットワークのトラブルシューティング時のご参考になれば幸いです。