Servidor remoto tras un proxy inverso

1. Cómo funciona

El servidor local corre en el equipo remoto como un servicio, escuchando solo en 127.0.0.1. Delante, en el mismo equipo, un proxy inverso (por ejemplo, Caddy) es la única puerta de entrada desde fuera: cifra la conexión con HTTPS y exige su propia clave. Las peticiones de ZeroChat las reconoce y las pasa al servidor local; el resto puede seguir yendo a otros servicios, como el servidor de modelos.

Hay dos barreras independientes:

• La clave del proxy decide quién llega al equipo. Sin ella, el proxy no deja pasar nada.
• La cuenta del sistema decide quién usa ZeroChat. El servidor local no confía en el proxy: cada petición necesita el token del día, y para obtenerlo hay que identificarse con el usuario y la contraseña de la cuenta que ejecuta zerochat.

Frente al túnel SSH, no hace falta un cliente SSH ni mantener una sesión abierta, y sirve igual desde el móvil, la tablet u otro ordenador.

2. Preparar el equipo remoto

El servidor local como servicio

Arranca zerochat con tu usuario, desde el directorio del proyecto, sin abrir el navegador y sin cerrarse al cerrar la pestaña:

zerochat --no-browser --keep-server

• Escucha solo en el propio equipo: no uses --host con una dirección pública; la única entrada desde fuera es el proxy.
• La cuenta importa: la cuenta con la que arranca zerochat es la que se identifica desde el navegador, y sus permisos son los de las herramientas.
• Sin latido: con --keep-server la página no envía latidos periódicos; relee el estado del servidor al volver a la pestaña.

El proxy inverso

El proxy tiene que hacer tres cosas:

1. Servir HTTPS con un certificado que el navegador acepte, porque la interfaz se carga desde GitHub Pages por HTTPS y el navegador bloquea las conexiones sin cifrar a otros equipos.
2. Comprobar su clave y pasar las peticiones de ZeroChat al servidor local del propio equipo.
3. Permitir las comprobaciones previas de CORS que el navegador hace antes de cada petición, que no llevan la clave.

El servidor local no necesita la clave del proxy: lo recomendable es que el proxy no se la reenvíe.

3. Conectar desde el navegador

1. Abre ZeroChat y abre el panel de Conexión (el icono del enchufe, junto a la rueda de configuración de la barra lateral).
2. Desactiva Conexión local y escribe la dirección del proxy como URL del servidor local: solo el protocolo, el nombre y el puerto, por ejemplo https://mi-servidor:12345.
3. Activa Usar proxy, escribe su clave y pulsa Conectar.
4. Identifícate con el usuario y la contraseña de la cuenta que ejecuta zerochat en el equipo remoto.

• Qué se guarda: la URL y la clave del proxy quedan en la configuración del navegador; el token del día, en su cookie de sesión. La contraseña nunca se guarda.
• La clave solo va a su destino: se envía únicamente a la URL configurada. Si en el mismo navegador abres un zerochat local, esa conexión no la recibe.
• Configuración global: la conexión no forma parte de los perfiles; los perfiles siguen eligiendo el modelo, sus servicios MCP y su navegador.

4. Identificación y seguridad

• Token diario: caduca a medianoche también con el servidor en marcha. La página vuelve entonces a pedir el usuario y la contraseña; el servidor y sus comandos siguen.
• Intentos limitados: tras 5 intentos fallidos seguidos, zerochat rechaza los siguientes durante 15 minutos sin comprobarlos.
• Bloqueo de cuentas del sistema: si el equipo bloquea la cuenta tras varios fallos (por ejemplo, con pam_faillock), deja ese límite por encima del de zerochat. Si no, unos intentos fallidos desde la web podrían bloquear también el inicio de sesión local.
• Herramientas firmadas: cada llamada a una herramienta va firmada para esa sesión y caduca en segundos, aunque alguien vea pasar la petición.

5. Situaciones habituales