n8n 2.34.5 - Proxy TLS Hop Options

n8n tagged [email protected] on 12 August 2026. The patch is a single core fix: TLS options now apply per hop when outbound requests go through a proxy. Operators who terminate TLS at an HTTPS forward proxy, or who pin a private CA or client certificate on the target, were handing those options to the wrong peer.

The full release notes and downloads are on the GitHub release page.

A workflow HTTP client that talks through a forward proxy opens two TLS sessions. One handshake is with the proxy. The second is with the target inside the CONNECT tunnel.

Before this patch, target TLS options were passed into the https-proxy-agent constructor. That library uses the constructor bag as connect options for the socket to the proxy. Two failures follow from that mix.

The proxy certificate is checked against the target hostname. An https:// proxy URL then fails the handshake, so CONNECT is never sent. Private CA material and client certificates also never reach the tunnelled session. They are applied to the wrong peer and missing on the right one. That second case hits http:// proxies too.

The release cites pull request 36017 and commit 01a52b4. The undici path is unchanged. Its ProxyAgent is built with timeouts only, no TLS options. Mixed stacks still have two code paths.

The change sits in packages/@n8n/backend-network. buildNodeAgents in node-agents.ts no longer constructs HttpProxyAgent and HttpsProxyAgent with the full agentOptions bag.

It now calls createProxiedHttpAgent and createProxiedHttpsAgent from proxy/proxied-agents.ts. Those helpers keep target TLS fields off the proxy handshake. Tests assert that connectOpts for https://proxy.internal:3128 keeps host and port for the proxy and must not carry servername, ca, cert, key, passphrase, rejectUnauthorized, secureOptions, ciphers, minVersion, or checkServerIdentity.

Transport fields such as keepAlive and timeout still travel with the proxy socket. That is the intended split: socket lifetime stays on the hop that owns the TCP connection. Identity and trust stay on the hop that owns the certificate.

The same helpers are wired into env-proxy-http-agent.ts and env-proxy-https-agent.ts. Environment driven proxy routing therefore follows the same hop rules as an explicit proxy URL. The comment on buildNodeAgents now states that agentOptions describes the connection to the target. Behind a proxy those TLS options travel with the tunnelled session.

The same commit adds sniFor() in http/axios/utils.ts. SNI takes a hostname, never an IP literal, per RFC 6066 section 3. Node also ignores IP values for servername.

sniFor strips IPv6 brackets, then uses net.isIP. If the host is an IPv4 or IPv6 literal, it returns undefined. Call sites in legacy.ts, redirect.ts, buildAgentOptions, and the redirect hop agent builder now go through that helper.

Tests cover https://185.90.154.8/foo and https://[2001:db8::1]/foo. This is adjacent cleanup in the same commit, not a second product feature. Workflows that call APIs by raw IP should no longer advertise a bogus SNI name on the TLS handshake.

Redirect following is part of that path. getBeforeRedirectFn and buildRedirectHopAgents used to copy the next hostname into servername without the IP check. A redirect from a name to an address would have kept the old SNI bug on the next hop.

This is a patch on the 2.34 line. The compare range is [email protected] to [email protected]. The notes list no migration steps and no renamed config keys.

Direct (no proxy) paths already applied TLS to a single peer. The undici proxy path was already constructed without TLS options. The regression surface is the axios plus https-proxy-agent path used by the shared request helpers.

If outbound HTTP nodes fail TLS against an HTTPS forward proxy, or if a private CA or client certificate works direct and fails through a proxy, this hop mismatch is the likely cause. Roll the image or package to [email protected] and retest against the proxy you actually run: HTTP versus HTTPS proxy URL, private CA, client cert, and rejectUnauthorized or skipSslCertificateValidation.

Winners are operators who put a TLS terminating proxy in front of SaaS and internal APIs. Anyone who relied on target trust settings being applied to the proxy handshake will see that stop. That behavior was a bug, not a documented contract.