VPN がページ途中で切れた：バックグラウンドのリクエストはまだ出ていくのか

タブにはトンネルが切れる前のダッシュボードがまだ表示されています。状態の数字は止まり、小さなスピナーは回り続け、アドレスバーには一時間前に開いたアプリが残っています。切断後に何も触っていないのに、ページは今も独自のスケジュールでサーバーに届こうとしているかもしれません。見落とされがちなのはここです。単に見えているだけのページと、今もリクエストを送っているページは外から見ると同じで、ネットワークログに現れるのは片方だけです。

ページがあなたなしで始める仕事

四つの仕組みが、読み込まれた文書を忙しくさせ続けます。繰り返しタイマーは数秒ごとに状態呼び出しを再実行できます。タブに戻って再び表示されたときに fetch が発火することがあります。WebSocket やサーバー送信イベントで作られたライブチャネルは、独自のバックオフ計画で再接続を試みることがあります。サイトが登録したサービスワーカーは、目の前にタブがなくても、キューに入った同期のために起きることがあります。

どれもクリックを必要とせず、どれも文書を再読み込みしません。アドレスバー、スクロール位置、表示されている値はすべてそのままです。変わるのはネットワーク側だけです。新しい試行のそれぞれは、それが始まる瞬間に出される新しい判断です。

この区別が重要なのは、見えているページがローカルに保存されているからです。すでに描かれたピクセルは、次のリクエストが成功したかどうかを何も語りません。スピナー付きで固まったグラフは、いまリクエストが失敗しているページの普通の見た目です。画面を読むと分かるのは数分前にサーバーが言ったことであり、いまブラウザが何をしているかではありません。

以前のページ読み込みがルートを保持しない理由

ページ読み込みの中の何も、文書をトンネルに結びつけません。ルーティングはパケットごとに、送信の時点で、パケットが出ていくときに存在するテーブルから解決されます。トンネルのインターフェースが消えると、その検索はトンネルのルートに一致しなくなります。物理アダプターに落ちるか、何も見つからないかは、クライアントが何を残したかによります。

繰り返しのコールバックは普通のスケジュールされたタスクです。HTML 標準のタイマーの節は、それらがどうキューに入るかを説明し、間隔を正確な周期の約束ではなく最小の遅延として扱います。そのためバックグラウンドのタブは、コードが求めるよりもはるかに少ない頻度でポーリングできます。試行が少ないことは試行がないことと同じではなく、タブを前面に戻すのはそれらがまとめて起きるよくある瞬間です。

失敗ポリシーはどこに落ちるか

クライアントのブロックは、ページが取得されたときではなく、接続が試みられたときに評価されます。通常のアクセスがまだ許可されていれば、再試行は物理リンクを通って平文で出ていくことがあります。ポリシーがトンネルの復帰までそのトラフィックを保持するなら、試行は接続の時点で失敗し、ページは数秒後に再試行できるかもしれないエラーを表示します。

どちらになるかは二つの詳細で決まります。一つ目はクライアントが対応する適用範囲です。デバイス全体のブロック、トンネルアダプターに限ったブロック、除外付きのルールセットのいずれかです。二つ目は、宛先が以前に追加した除外（ローカルプリンター、キャプティブポータル、ストリーミングサービス）に入るかどうかです。

アプリケーション層の暗号化はこれを何も変えません。HTTPS はブラウザとサーバーの間のバイトを守りますが、どのインターフェースがそれを運ぶかは語りません。ページは完全に暗号化されていても間違った経路から出ていくことがあり、狭いブロックが許すのはまさにそれです。

使い捨てページによる統制された確認

自分で管理するホストと、それを呼ぶ以外に何もしないページを使い、実際のデータが関与しないようにします。ターミナルから、切断の前後で経路を採取します。

curl -sS --max-time 5 -o /dev/null -w '%{http_code} %{remote_ip}\n' https://probe.example.net/ping

トンネルを上げた状態で実行し、次にトンネルを下げて再び実行します。トンネルが下がっている間に公開アドレスから返答があれば、直接経路が開いていると分かります。タイムアウトや接続拒否は、ポリシーが保持していると分かります。クライアントが再接続した後にもう一度繰り返し、当然と決めつけずにトンネル経路が戻るのを見ます。

ブラウザでは、ネットワークパネルが二つの問いを分けます。Fetch/XHR に絞り、次に開始元の列を読みます。タイマーやスクリプトが開始し、その前にナビゲーションが記録されていない項目は、再読み込みではなくバックグラウンドの試行です。その開始時刻をトンネルが切れた瞬間と比べます。トンネルが消えても項目が保留のままなら、そのリクエストはもう存在しない経路で待っています。

サーバー側の証拠は、ブラウザが示す何よりも強いものです。タイムスタンプと送信元アドレスのあるリクエストログは、パケットが届いたことを証明します。ブラウザの項目は Cookie、トークン、完全な URL を含みうるので、質問に必要な項目だけを残し、どこかに貼る前に残りを伏せます。

答えをどう扱うか

トンネルが下がっている間にバックグラウンドの試行が成功し続けるなら、ブロックは想定より狭く、その隙間は機密作業をクライアントに任せる前に塞ぐ価値があります。失敗するなら、ポリシーは仕事をしており、固まったページは見た目だけの問題です。いずれにせよ、タブを一つ閉じることはデバイス全体の制御ではありません。他のタブ、他のブラウザ、他のアプリはそれぞれ自分の仕事を予定に入れています。

取る価値のある次の一歩は、追加した除外とその理由を列挙すること、クライアントがトンネル範囲のトラフィックだけを遮断するのか全トラフィックを遮断するのかを確かめること、サーバーログを開いたままバックグラウンドのリクエストを一つ最初から最後まで観察することです。この三つの答えで、「VPN が切れたのに何かがつながったまま」という報告の中身の大半は説明できます。