Safariの検索クリックをリダイレクト経由で追跡する

検索結果が、名前に挙げたページへ直接リンクしていることはほとんどない。クリックはリダイレクタ、同意のための中間ページ、サインインサービスを通過することがあり、各ホップは単独で失敗しうる別々のリクエストだ。SafariのNetworkタブはその順序を見える状態に保つが、クリックの前に記録を始めた場合に限る。有用な証拠は最初に失敗したURLであり、結果に表示されたアドレスではない。

クリックの前に記録を開始する

タブでWeb Inspectorを開き、検索結果に触れる前にNetworkへ切り替える。Preserve Logを有効にすると、ページを置き換えるナビゲーションを越えて一覧が残る。既存の項目を消去し、それからちょうど一度クリックする。ページの読み込み後に始めた記録では、必要なリクエストをすでに失っている。

個人データのないページを使い、比較の間ずっとブラウザプロファイルとVPNの状態を変えない。途中でどちらかを変えると、二つの経路は比較できなくなる。

リダイレクトを順に読む

行を上から下へ読み、ステータスコードを追う。Locationが別のホストを指す301や302は目的地ではなくホップだ。その後に続くリクエストは、独自の名前解決、TLSハンドシェイク、ポリシー検査を伴う新しいナビゲーションである。コンテンツが届くまでにクリックがいくつのホストに触れるかを数える。

WebKitのNetworkタブガイドはリクエスト記録とPreserve Logオプションの挙動を説明しており、まばらな一覧を解釈する前に読む価値がある。行が欠けているのは通常、記録の開始が遅れたか、service workerがキャッシュから応答したためであり、ブラウザがホップを飛ばしたわけではない。

直接アクセスと比較する

同じプロファイルと同じネットワークで、意図した最終ページへ直接入力または貼り付けて二回目の取得を行う。二つの一覧が分かれる最初の行から比較する。クリックした経路が、直接の経路が決して接しない中間業者で失敗するなら、問題はその中間業者にある。両方が同じoriginに到達し、片方だけが拒否されるなら、アカウントの状態やリクエストの詳細の方がよい手がかりだ。

二つの記録をタイムスタンプ付きで並べて保つ。時間の差は因果の証明ではないが、次にどのサービスを調べるかを絞り込む。失敗した行がどのホストに属していたかを記録するのは、同じブラウザの症状でも段階ごとに所有者が異なるからだ。直接の取得も失敗するなら、クリック経路は差異要因ではない。

失敗の段階を正確に特定する

行のエラー文言は、サイトがブロックされているという一般論より具体的だ。名前解決の失敗、決して完了しない接続、TLSエラー、HTTPステータスは、四つの異なる所有者を持つ四つの異なる段階である。その段階を一般的な失敗ではなく言葉で記録すれば、エスカレーション先は明らかになる。

Pingとtracerouteはホストに関する手がかりを加えられるが、ブラウザのリダイレクト連鎖を再生するわけでも、HTTPSリクエストの成功を証明するわけでもない。ホストへのpingが成功していても、同じホストでTLSエラーが併存することがある。ウェブリクエストの記録を主要な証拠とし、後続のネットワーク試験は補助的な詳細として扱う。

トークンを漏らさずトレースを共有する

トレースを書き出す前や貼り付ける前に、すべてのURL、ヘッダー、クエリパラメータを見直す。リダイレクト連鎖はセッション識別子、メールアドレス、同意状態、署名付きリンクを運ぶことが多い。そうした値は置き換えるか削り、調査に本当に必要なorigin、ステータス、時刻は残す。

最初に失敗したリクエスト、その前のホップ、リダイレクトのステータスを引き渡す。この三点があれば、次の担当者は完全なトレースを読まず、アカウントにも触れずに、あなたの経路を再現できる。