Kafka Through a Proxy: Bootstrap Works, Broker Connections Fail

A bootstrap connection can succeed while the Kafka client still cannot produce or consume. Bootstrap servers help the client discover the cluster; they are not necessarily the only endpoints it will contact.

Broker metadata contains addresses used for later connections. If those names or ports are unreachable through the intended proxy route, the first successful connection does not solve the rest of the job.

Read the advertised endpoints

Compare the bootstrap address with the broker addresses the client actually receives. A public bootstrap alias can lead to private advertised names, and forwarding one local port does not automatically rewrite every address in metadata.

Also identify the client implementation's supported proxy path. A Java system SOCKS property is not a guarantee that a library's NIO-based transport uses the JDK Socket proxy mechanism. Check the actual Kafka client and network integration rather than assuming every Java socket honors the same setting.

A proxy-aware client needs an allowed route to the relevant broker endpoints. A network-level arrangement needs corresponding reachability and name resolution. Those are different designs, neither supplied merely by listing a proxy as a bootstrap server.

Keep security protocol and authentication settings separate. A proxy can establish a TCP path while TLS identity, SASL authentication, or broker authorization still fails.

For diagnosis, note which endpoint failed and whether it came from static configuration or returned metadata. That distinction narrows the problem much more than repeatedly changing an endpoint that was already reachable.