Una conexión bootstrap puede funcionar mientras el cliente de Kafka sigue sin poder producir ni consumir. Los servidores bootstrap ayudan al cliente a descubrir el clúster; no son necesariamente los únicos puntos finales con los que se conectará.

Los metadatos del broker contienen direcciones que se usan para conexiones posteriores. Si esos nombres o puertos no son accesibles por la ruta de proxy prevista, la primera conexión correcta no resuelve el resto del trabajo.

Lee los puntos finales anunciados

Compara la dirección bootstrap con las direcciones de broker que el cliente recibe realmente. Un alias bootstrap público puede llevar a nombres anunciados privados, y reenviar un solo puerto local no reescribe automáticamente todas las direcciones de los metadatos.

Identifica también la ruta de proxy que admite la implementación del cliente. Una propiedad SOCKS del sistema Java no garantiza que el transporte basado en NIO de una biblioteca use el mecanismo de proxy de Socket del JDK. Comprueba el cliente de Kafka real y la integración de red en lugar de suponer que todos los sockets Java respetan la misma configuración.

Un cliente consciente del proxy necesita una ruta permitida a los puntos finales de broker correspondientes. Una disposición a nivel de red necesita la conectividad y la resolución de nombres correspondientes. Son diseños distintos y ninguno se obtiene solo listando un proxy como servidor bootstrap.

Mantén separadas la configuración del protocolo de seguridad y la de autenticación. Un proxy puede establecer una ruta TCP mientras la identidad TLS, la autenticación SASL o la autorización del broker siguen fallando.

Para diagnosticar, anota qué punto final falló y si proviene de la configuración estática o de metadatos devueltos. Esa distinción acota el problema mucho más que cambiar repetidamente un punto final que ya era accesible.

Artículos relacionados