Squid の SO_ORIGINAL_DST エラーを読む

NF getsockopt(SO_ORIGINAL_DST) は元の宛先のルックアップを示します。インターセプト構成では、リダイレクトされた接続が元々どこへ向かっていたのかを Squid が復元する必要があります。

明示的に設定されたブラウザーは、意図してプロキシへリクエストを送ります。Squid リスナーのポートの横に intercept と書かれているからといって、その接続に NAT インターセプトの履歴が付くわけではありません。

したがってこの不一致は、宛先の証明書が問題になるより前に失敗することがあります。

接続がどう届いたかから始める

• アプリケーションにプロキシ アドレスが設定されているなら、本来使うべき通常のフォワード プロキシ リスナーを特定します。
• ゲートウェイが本来は直接の通信をリダイレクトしているなら、それが想定したインターセプト リスナーに届いているか、対応する NAT 設計が必要な宛先情報を保持しているかを確認します。
• 両方のモードがあるなら、失敗しているクライアントが実際にどのアドレスとポートへ接続したかを確認します。

Squid の http_port のドキュメントは違いを明確にしています。モード フラグを省略するとフォワード プロキシ モードになり、intercept は IP 層での NAT インターセプトを前提とします。

次に、トランスポートの安全性は別に扱います。HTTP プロキシは CONNECT による HTTPS を運べます。プロキシへの TLS 接続には、対応するリスナーとクライアント設定が必要です。宛先への通信を復号することは、また別の任意の機能です。

宛先 URL が HTTPS で始まるというだけで証明書生成を有効にする古い「HTTPS 修正」をそのまま真似しないでください。まずクライアントとリスナーの合意を直します。その後になお本当の TLS エラーが残るなら、そのほうが調査しやすいエラーです。