{"version":"2.1.242","anchor":"proxied-https-connections-verify-the-original-hostname","canonical_anchor":"proxied-https-connections-verify-the-original-hostname","heading":"Proxied HTTPS connections verify the original hostname","tier":"notice","area":"Internals","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.242\/e\/proxied-https-connections-verify-the-original-hostname","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.242","markdown":"### Proxied HTTPS connections verify the original hostname\n\nConnections through an HTTPS proxy now verify the certificate against the host you asked for.\n\n**What**\n\nConnections made through an HTTPS proxy now check the server's certificate against the host you actually asked for, and for non-literal hostnames Claude Code resolves the address itself while still sending the original name for SNI and verification. Two new failure reasons cover a credentials file holding the gateway's TLS pin being a symlink or unreadable.\n\n**Details**\n\n- symlinked credential files are not followed\n- applies to all proxied connections, with no setting to opt out\n\n**Evidence**\n\n`\"the credentials file that keeps the gateway's TLS pin is a symlink, which is not followed\"`\n\n- Area: Internals\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 2\/5"}