セミコロンで区切られた PAC の結果は、次の順に代替経路を提供します:

return "PROXY proxy-a.example:8080; PROXY proxy-b.example:8080";

ポリシーが要求する実際の HTTP エンドポイントを使用してください。パブリックプロキシが許可されるパブリック宛先のテストでは、HTTP プロキシのリストが候補を提供します。A が失敗した後、適切な場合にブラウザーは B を試せます。トラフィックが A を経てから B を通ることはありません。チェーンにはクライアントまたはプロキシサーバー側の別個のサポートが必要です; curl の SOCKS から HTTP へのチェーン は、サポートされている構成の 1 つです。

スクリプトの可用性とプロキシの可用性

クライアントはまず使用可能な PAC スクリプトを取得する必要があります。戻り値に 2 台目のプロキシがあっても、スクリプトのダウンロードに失敗し、使用可能なキャッシュ コピーを持たないブラウザーは助かりません。

評価後、ブラウザーは返された経路の中から選択します。PAC リファレンスが順序付き形式を定義しており、どの障害でフォールバックするか、失敗した候補をいつまで記憶するかはブラウザーが決めます。動作中のプロキシ経由で受け取った HTTP エラーは、自動的に別の経路を起動しません。

直接接続という選択肢

; DIRECTを追加すると、どちらのプロキシも使わない経路が許可されます。これはローミング ポリシーに適することがありますが、該当するトラフィックが常に承認された出口を使用するという要件とは矛盾します。

障害報告では、スクリプトを取得できたか、該当 URL に対するその結果、ブラウザーが試した代替経路を記録してください。これらの観察により、スクリプト配信、評価、プロキシ接続のどこで障害が起きたかを特定できます。

関連記事