Docker publicó el puerto. ¿Escucha el proxy allí?
Compruebe el oyente dentro de un contenedor de proxy y la asignación de puerto del host de Docker cuando las conexiones se rechazan o se restablecen.
Un puerto de Docker publicado proporciona una ruta hacia un punto final del contenedor. No inicia el proxy ni cambia la dirección en la que escucha ese proceso.
Para una asignación típica en red puente, compare estos tres valores:
| Parte de la ruta | Valor que inspeccionar |
|---|---|
| Entrada del cliente | La dirección del host y el puerto publicado que contacta el cliente |
| Destino del reenvío | La dirección del contenedor y el puerto que selecciona la asignación |
| Servicio | La dirección y el puerto que el proxy enlaza realmente dentro del contenedor |
Un proxy enlazado solo a 127.0.0.1 dentro del contenedor puede no recibir el tráfico reenviado a su dirección de red. Esto difiere de publicar un puerto del host solo en la loopback del host: eso restringe quién puede llegar a la asignación, mientras que la loopback del contenedor puede impedir que la asignación llegue al servicio.
Elija el oyente interno para el despliegue previsto preservando la publicación restringida del host y el acceso al proxy. La declaración de puerto expuesto de un Dockerfile no inicia un servicio, y un arranque correcto del contenedor no demuestra que el proceso escuche en el destino del reenvío.
Siga hasta dónde llega una conexión fallida. Los rechazos y los restablecimientos varían según la plataforma y la implementación del reenvío, así que ninguno de los dos identifica por sí solo un ajuste. Cuando llegue al servicio, busque un saludo de proxy válido y aplique la versión de SOCKS, la autenticación y la política de destino requeridas. Solo un puerto de host accesible no puede demostrar esas capacidades.