Proxy inverso

Qué hace

Recibe el tráfico HTTP (puerto 80) y HTTPS (puerto 443) de tus dominios y lo enruta al servidor de origen correspondiente. Hacia los visitantes habla HTTP/2 y HTTP/1.1; hacia tu servidor de origen preserva los encabezados originales y agrega los X-Forwarded-* estándar para que tu aplicación reconozca la dirección IP real y el protocolo del visitante.

Es el tipo de ruta más general: cualquier servicio que hable HTTP puede quedar detrás de Tero Services y delegarle TLS, WAF, caché y observabilidad.

Cuándo usarlo

• Cualquier dominio que sirva una aplicación web o API y quiera delegar TLS, seguridad y observabilidad al borde.
• Cuando necesitás dirigir distintos paths a distintos servidores de origen (por ejemplo, /api → servicio en Node, / → otro servidor).
• Como punto de entrada uniforme frente a varios servicios internos heterogéneos.

Cómo se configura

Se solicita al equipo de Host Admin, indicando:

• Dominio (por ejemplo, app.miempresa.com).
• Servidor de origen — host:puerto o URL (http://10.0.0.5:3000, https://origen.interna:8443).
• Path opcional si querés segmentar por ruta dentro del dominio.
• Notas del backend: si usa HTTP/2, si requiere un Host específico, o si necesita SNI hacia el origen.

Creada la ruta, apuntá el registro A/AAAA del dominio a la dirección IP de Tero Services; el certificado se emite automáticamente (ver TLS automático).

Encabezados que recibe tu servidor de origen

Encabezado	Valor
X-Forwarded-For	Dirección IP real del visitante
X-Forwarded-Proto	http o https
X-Forwarded-Host	Nombre de dominio original solicitado
X-Tero-Country	Código ISO-2 del país (si tenés geo-bloqueo activo con propagación habilitada)
X-Tero-Request-Id	Identificador único de la solicitud, útil para correlacionar registros

Protocolos soportados

• HTTP/2 y HTTP/1.1 hacia los visitantes (negociado por ALPN).
• WebSockets sobre HTTP/1.1 (HTTP/2 no es el transporte para WebSockets).
• HTTPS hacia el origen: soportado; requiere que el certificado del origen valide contra una cadena conocida, o que se acepte una autoridad de certificación interna provista por Host Admin.

Balanceo y alta disponibilidad

Una ruta puede apuntar a varios servidores de origen con balanceo de carga y conmutación por fallo. Coordinalo con el equipo si tu plan lo requiere; se definen la estrategia de reparto y los chequeos de salud.

Limitaciones

• El puerto 80 se mantiene activo para emitir los certificados; las solicitudes HTTP normales pueden redirigirse con 301 a HTTPS si lo solicitás.
• Para escenarios con requisitos de tránsito estrictos (por ejemplo, que el borde no deba terminar TLS) existen modos alternativos que se coordinan con el equipo.

Preguntas frecuentes

• ¿Soporta varios servidores de origen por dominio? Sí, con balanceo o conmutación por fallo según tu plan.
• ¿Puedo forzar solo HTTPS? Sí, con redirección 301 desde HTTP. El puerto 80 sigue escuchando solo para la emisión de certificados.
• ¿Puede reescribir paths o encabezados hacia el origen? Sí, dentro de lo razonable; indicá las reescrituras necesarias al dar de alta la ruta.