¿Pueden dos proxies inversos compartir los puertos 80 y 443 en un mismo servidor doméstico?
No en la misma IP y protocolo al mismo tiempo, a menos que un proxy sea la única puerta de entrada y reenvíe el tráfico seleccionado al otro, o que cada uno se vincule a una IP diferente.
Esto se convierte en una cuestión real de compatibilidad cuando dos contenedores proxy publican los puertos 80 y 443 del host para pilas de aplicaciones independientes en una sola máquina. Comienza con una ruta o cuenta desechable, conserva disponible el estado anterior funcional y evalúa el diseño según la carga de trabajo original, no según una prueba de conexión puntual.
Identifica quién es propietario del recurso compartido
La opción compatible es un único listener por cada par IP-puerto, con el enrutamiento detrás de él. La opción conflictiva son dos listeners independientes compitiendo por el mismo socket. Registra las versiones, identidades, direcciones, rutas de montaje, permisos y el estado observable actual antes de cambiar cualquiera de las dos opciones.
Las reglas de vinculación de sockets relevantes definen el primer límite de compatibilidad. Úsalas para delimitar la afirmación y, después, verifica el mismo comportamiento en este servidor doméstico exacto, en lugar de tratar una función documentada como prueba de que todo el diseño funciona.
Escribe la regla de decisión antes de probar: el éxito debe producir únicamente que el proxy frontal previsto sea propietario de cada socket público y que cada nombre de host llegue al upstream correcto con el certificado esperado; el fallo incluye que el inicio informe de que la dirección ya está en uso, que el tráfico llegue al proxy equivocado o que TLS termine con el certificado de otro sitio. Esto evita interpretar una conexión parcial o la salida limpia de un comando como compatibilidad integral.
Cambia un listener o una ruta a la vez
Usa un único elemento de control: enumera los listeners actuales, vincula cada proxy a una IP de prueba distinta o coloca uno detrás del otro y, después, prueba el enrutamiento de Host, SNI, WebSocket y certificados. Mantén constantes el cliente, la carga de trabajo, el conjunto de archivos, la cuenta y el momento, para que el componente cambiado sea la única explicación plausible.
Usa el comportamiento de los puertos publicados para elegir la segunda observación importante para esta ruta. Captura ambos lados de la transacción: resolución o ruta, protocolo negociado, identidad del proceso, estado de salida, latencia, bytes transferidos y cualquier evento de recuperación.
Repite la prueba después del evento del ciclo de vida indicado en el título: recreación, reconexión, remontaje, reinicio, conmutación por error o cambio de cliente. Un diseño que solo funciona mientras los sockets, las cachés o las credenciales antiguas permanecen activos no ha superado la prueba.
ss -ltnp '( sport = :80 or sport = :443 )'
docker ps --format '{{.Names}} {{.Ports}}'Usa evidencias observables del enrutamiento para decidir
APROBADO: solo el proxy frontal previsto es propietario de cada socket público y cada nombre de host llega al upstream correcto con el certificado esperado. Guarda las versiones exactas y la topología que produjeron este estado, porque la conclusión se aplica a esas condiciones y no a todas las implementaciones del protocolo.
FALLIDO: el inicio informa de que la dirección ya está en uso, el tráfico llega al proxy equivocado o TLS termina con el certificado de otro sitio. Comprueba las dependencias compartidas, como DNS, MTU, identidad, estado del firewall, latencia del almacenamiento y sesiones en caché, antes de declarar responsable a cualquiera de las dos opciones principales.
EXCEPCIÓN: detén la segunda vinculación pública, restaura el último listener funcional y elige una única puerta de entrada o direcciones de host separadas. No amplíes privilegios, elimines datos de origen, debilites la seguridad del transporte ni sustituyas el almacenamiento funcional hasta que una observación reproducible identifique qué límite falló.
Vuelve a comprobar el aislamiento antes de que regrese el tráfico de producción
Aplica únicamente la acción correspondiente a la opción observada y, después, vuelve a ejecutar la carga de trabajo original. Conserva el diseño solo cuando únicamente el proxy frontal previsto sea propietario de cada socket público y cada nombre de host llegue al upstream correcto con el certificado esperado durante dos ciclos de vida relevantes y bajo la carga simultánea prevista.
Usa las redes de proxy dedicadas para verificar el flujo de trabajo dependiente más cercano. Su comportamiento de acceso, tiempos y recuperación debe permanecer sin cambios mientras el nuevo diseño esté activo.
Detente y vuelve al estado guardado si el inicio informa de que la dirección ya está en uso, el tráfico llega al proxy equivocado o TLS termina con el certificado de otro sitio. Escala el problema con marcas de tiempo, versiones exactas, evidencias de rutas o montajes y la reproducción mínima, en lugar de añadir otra solución alternativa.
Contrasta el resultado con las sustituciones de DNS del proxy inverso para que el riesgo no se traslade simplemente a otra capa de red, identidad, copias de seguridad o almacenamiento.
Por lo tanto, para la propiedad de puertos de dos proxies inversos, la respuesta matizada es el juicio inicial, no un sí incondicional. El estado observable de aprobación es la línea de aceptación; el estado de fallo es la línea de reversión.
Preguntas frecuentes
¿Puede SO_REUSEPORT permitir que proxies no relacionados compartan 443?
No es un diseño seguro de enrutamiento por nombre de host para proxies independientes; usa una única puerta de entrada TLS o IP independientes.
¿Puede un proxy pasar TLS al segundo?
Sí, cuando el enrutamiento se basa en SNI y el proxy descendente gestiona la terminación del certificado para ese nombre de host.
¿Entran en conflicto los listeners IPv4 e IPv6?
Pueden hacerlo, según el comportamiento de los sockets de doble pila y las direcciones de vinculación; inspecciona explícitamente ambas familias de protocolos.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede una galería autoalojada conservar el emparejamiento de las Live Photos de Apple?
Una decisión condicional sobre un servidor doméstico para emparejar Apple Live Photo, con pruebas controladas, interpretación de resultados, reversión y preguntas frecuentes específicas.
¿Puedes importar Google Takeout y las copias de seguridad del teléfono en una sola biblioteca de fotos?
Una decisión condicional sobre un servidor doméstico para la importación combinada de fotos, con pruebas controladas, interpretación de resultados, reversión y preguntas frecuentes específicas.
¿Puede Immich usar una biblioteca externa sin hacerse cargo de los archivos?
Una decisión condicional sobre el servidor doméstico para la propiedad de bibliotecas externas de Immich, con pruebas controladas, interpretación de resultados, reversión y preguntas...
