Red, puertos y DNS

Puertos

Puerto	Dónde	Para qué
`8080/tcp`	servidor	dashboard y API (conviene publicarlo detrás de HTTPS)
`8443/tcp`	servidor	los agentes se conectan con TLS mutuo (sólo hacia el servidor)
`51820/udp`	todos los nodos	malla WireGuard entre nodos
`80/tcp`, `443/tcp`	nodos de ingress	tráfico de las apps y desafíos ACME

Los workers sólo necesitan conexiones salientes hacia el servidor (8443) y UDP entre nodos. Un nodo detrás de NAT puede unirse sin --endpoint: los demás nodos no pueden iniciarle conexiones, pero él los alcanza (el keepalive mantiene el túnel).

Exponer el plano de control: dashboard y agentes son dos puertas

El servidor atiende dos cosas distintas, y conviene que tengan nombres distintos:

Qué	Puerto	Qué lo usa	Cómo se publica
Dashboard, API, login OAuth y webhooks	`8080/tcp`	personas y GitLab	detrás de HTTPS: un proxy o un túnel (p. ej. Cloudflare Tunnel) en un nombre como `cp.ejemplo.com`
Listener de agentes	`8443/tcp`	los `cloudweb-agent` de los nodos	directo, en un nombre como `agents.ejemplo.com`

Los agentes no pueden pasar por un proxy HTTP ni por un túnel que termine el TLS (Cloudflare proxy, Cloudflare Tunnel, la mayoría de los balanceadores L7): se autentican con un certificado de cliente (TLS mutuo) que esos intermediarios no reenvían. El nombre de los agentes tiene que apuntar directo al servidor:

Un registro A solo DNS (en Cloudflare: nube gris, sin proxy) hacia la IP pública del servidor.
8443/tcp abierto (o redirigido en el router) hacia el servidor, y 51820/udp para la malla.
CLOUDWEB_PUBLIC_HOSTS con ese nombre primero: el comando de unión usa el primero y el certificado del listener cubre todos.
```
CLOUDWEB_PUBLIC_HOSTS=agents.ejemplo.com,192.168.0.80
```

Con una IP dinámica, hace falta DDNS para mantener ese registro al día (TTL bajo, p. ej. 60 s).

Cuidado: un nombre que sí pasa por el proxy (como el del dashboard) puede responder también en :8443. Cloudflare, por ejemplo, acepta ese puerto y lo entrega al túnel, así que https://cp.ejemplo.com:8443 muestra el dashboard, no el listener de agentes. Un nodo unido con ese nombre falla de forma confusa. Usá siempre el nombre de los agentes, que es el que muestra el comando de Nodos → Generar token de unión.

El endpoint WireGuard de cada nodo se fija al unirse (--endpoint, por defecto la IP del nodo con el puerto 51820). Para cambiarlo hay que dar de baja el nodo (node.sh --uninstall) y volver a unirlo.

Dominio base y DNS

Las apps usan <app>.<dominio-base>. Creá un registro wildcard apuntando a la IP pública de tus nodos de ingress:

*.apps.example.com.   A   203.0.113.10

Con varios nodos de ingress, agregá un registro A por cada IP (balanceo por DNS).

Para un dominio propio de una app (www.cliente.com) creá un CNAME a <app>.<dominio-base> o un registro A a las IPs de ingress; el dashboard lo verifica y activa el TLS.

TLS

auto (por defecto): certificados de Let's Encrypt emitidos por host cuando el DNS ya apunta al nodo. Necesita 80/tcp y 443/tcp accesibles desde internet y un --acme-email.
internal: CA local de Caddy; para redes privadas y pruebas (los navegadores mostrarán aviso).
off: sólo HTTP.

HTTP se redirige a HTTPS automáticamente. Un host que no corresponde a ninguna app recibe 404.

Comunicación entre nodos

Todo el tráfico entre nodos (instancias, imágenes, proxy de ingress) viaja por la malla WireGuard cifrada; cada nodo recibe una subred 10.77.N.0/24 y su dirección 10.77.N.1. El rango 10.77.0.0/16 no debe solaparse con tus redes privadas.