Firefox がバイパスサブネット内のイントラネットホストを依然としてプロキシ経由にする理由
リテラル IP アドレス向けのバイパス範囲は、その範囲に解決されるホスト名を必ずしも除外しません。
Firefox の 「プロキシ不使用」リスト に 192.168.0.0/16 を追加しました。http://192.168.1.20/ を開くと直接接続されますが、http://wiki.office.example/ は依然としてプロキシに到達します。どちらの URL も同じサーバーを指す可能性があります。
重要な違いは、Firefox が照合する宛先文字列です。IP 範囲の例外とホスト名の例外は互換ではありません。アドレス範囲の規則が適用されるかどうかを判断する前に、手動のバイパスリストがすべてのホスト名を解決するものと仮定しないでください。
| 入力した URL | 照合に利用できる情報 |
|---|---|
| http://192.168.1.20/ | リテラル IP アドレス |
| http://wiki.office.example/ | ホスト名 |
イントラネットに専用ドメインがある場合は、名前が解決されうるアドレスを推測するのではなく、適切なホスト名またはドメインの例外を使用してください。無関係な公開サービスはその例外の外に置いてください。1 つのドメインに内部アプリケーションと外部でホストされるアプリケーションの両方が含まれることがあります。
Mozilla の元の説明 は、リテラル IP の照合と、その IP に解決される名前を明確に区別しています。この文書は歴史的なものなので、そこからすべての構文例をコピーする前に、現在のクライアントの動作とポリシーインターフェースを確認してください。
ポリシーに DNS が必要な場合
PAC ファイルは、DNS を意識した判断のための独立した明示的な場所を提供します。ただし、スクリプトの配布、実行、解決に関する障害モードも持ち込みます。長いバイパスリストを見かけ上短くするためではなく、ルーティング要件がそのロジックを必要とするから使ってください。
管理されたインストールでは、Firefox の有効なポリシーも確認してください。ロックされたプロキシポリシー は、ローカルでの編集が経路を決めない理由を説明してくれます。
トラブルシューティングでは、サーバーの最終的な IP だけでなく、入力したリテラル URL を記録してください。ホスト名の URL とリテラルアドレスの URL を比較すると、バイパス判断に利用できる情報が変わり、まさにそのために 2 つのリクエストが異なる経路をたどることがあります。