Reading a Squid SO_ORIGINAL_DST Error

NF getsockopt(SO_ORIGINAL_DST) points toward an original-destination lookup. In an interception setup, Squid needs to recover where the redirected connection was originally going.

An explicitly configured browser sends its requests to the proxy on purpose. That connection does not acquire NAT interception history merely because the Squid listener has intercept written beside its port.

This mismatch can therefore fail before the destination's certificate is relevant.

Start with how the connection arrived

• If the application has a proxy address configured, identify the ordinary forward-proxy listener it should use.
• If a gateway redirects otherwise direct traffic, check that it reaches the intended interception listener and that the supported NAT design preserves the required destination information.
• If both modes exist, check which address and port the failing client actually contacted.

Squid's http_port documentation makes the distinction explicit: omitting a mode flag selects forward-proxy mode; intercept expects IP-layer NAT interception.

Then treat transport security separately. An HTTP proxy can carry HTTPS using CONNECT. A TLS connection to the proxy requires a compatible listener and client configuration. Decrypting destination traffic is another optional capability again.

Do not copy an old “HTTPS fix” that enables certificate generation simply because the destination URL starts with HTTPS. First repair the agreement between the client and the listener. If an actual TLS error remains afterward, it will be a more useful error to investigate.