Caddy 2.11 en pymes: TLS, proxy y logs con prueba
Guía técnica para usar Caddy 2.11 como proxy de servicios internos: certificados, rutas, permisos, logs, respaldo y prueba de corte.
Un certificado vencido deja de ser un detalle cuando corta turnos, pagos o consultas externas. Caddy 2.11.4, listado en los releases oficiales, puede renovar TLS, enrutar dominios y escribir logs con una configuración corta. Esta guía muestra cómo ponerlo delante de aplicaciones internas sin convertir el proxy en una pieza opaca para gerencia e IT.
Dónde aparece el corte que nadie espera
El síntoma se repite: una app funciona desde la red interna y cae desde internet por certificado vencido, puerto mal abierto o cabecera perdida. En una clínica de Godoy Cruz, el objeto que delata el problema suele ser una etiqueta vieja pegada al router con un dominio escrito a mano. Ese papel resuelve una urgencia y después gobierna producción durante meses. La cifra que corrige la discusión llega de Stack Overflow 2025: HTML/CSS aparece con 61,9 % y JavaScript con 66 % entre todos los respondentes. Muchas herramientas de gestión, tickets, turnos y reportes terminan servidas por HTTP, aunque adentro guarden datos en PostgreSQL o MariaDB. El antagonista es el proxy heredado que nadie puede reproducir. Caddy documenta Automatic HTTPS para obtener y renovar certificados cuando el dominio y la validación están bien configurados. También documenta el bloque reverse_proxy, que recibe una petición y la envía a un servicio interno. La diferencia práctica aparece cuando el equipo puede leer el Caddyfile y reconstruir la ruta.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. Primero, DNS apunta turnos.empresa.com al servidor frontal. Segundo, Caddy recibe la petición por 80 o 443, pide o renueva certificado y decide a qué aplicación interna mandar el tráfico. Tercero, el servicio de destino recibe cabeceras, usuario de sesión y ruta. Cuarto, la aplicación guarda datos en PostgreSQL, MariaDB u otra base según el producto. Quinto, Caddy escribe logs de acceso y error con hora, IP, código HTTP, dominio y destino. Sexto, monitoreo revisa estado del puerto, certificado, latencia y respuestas 5xx; el backup copia Caddyfile, certificados gestionados si corresponde, variables y configuración de servicios. Caddy recibe HTTP y TLS; entrega tráfico hacia aplicaciones definidas por host o ruta. PostgreSQL guarda registros estructurados de la app, no del proxy. El log de Caddy muestra quién entró y qué respondió el servicio. IT administra DNS, firewall, Caddyfile, permisos del sistema y restauración. Si falla Caddy, las apps quedan sin entrada pública. Si falla DNS, el certificado tampoco se valida.
Qué se instala o configura primero
La pila concreta usa una VM Linux, Caddy 2.11, DNS con registros A o CNAME, firewall con 80/443 abiertos, archivos de configuración versionados, servicio systemd, logs rotados y un endpoint interno por aplicación. El primer entregable verificable es un dominio de prueba que responde con TLS válido, proxy a una app interna, log legible y comando de restauración documentado. El costo mensual directo puede quedar entre USD 15 y USD 80, equivalentes a ARS 22.650 y ARS 120.800 al dólar oficial de venta de ARS 1.510. Ese rango cubre VM chica, backup de configuración, monitoreo simple y una restauración mensual. Licencia de Caddy: USD 0 para el binario abierto; soporte, hardening y migración se presupuestan aparte. UMSA suele empezar por inventario: dominios, certificados, puertos, servicios, usuarios que administran DNS y método de vuelta. Una pyme no necesita una consola enorme para saber si el proxy está sano; necesita saber qué dominio cae, qué servicio responde y quién puede tocar la ruta.
Dónde se rompe y cómo probarlo
El primer riesgo aparece con DNS sin dueño. La señal es un dominio que nadie puede cambiar durante una caída. La prueba registra proveedor, cuenta administradora, segundo factor y persona responsable; después cambia un subdominio de prueba y mide el tiempo. El segundo riesgo aparece con rutas mezcladas. La señal es un Caddyfile que manda dos aplicaciones al mismo upstream. La prueba crea un host por app, simula caída de una sola y confirma que la otra siga respondiendo. El tercer riesgo aparece con logs mudos. La señal es un error 502 sin host, ruta ni destino. La directiva de log permite escribir campos útiles; la prueba fuerza un backend apagado y revisa que el evento diga qué servicio falló. El cuarto riesgo aparece con certificados que dependen de puertos cerrados. La señal es una renovación fallida por validación HTTP. La prueba renueva en staging, revisa firewall y guarda el resultado con fecha. El quinto riesgo aparece con restauración parcial. La señal es un Caddyfile respaldado sin variables, unidades systemd ni reglas de firewall. La prueba levanta el proxy en otra VM y sirve un dominio de ensayo. Caddy sirve cuando la organización quiere que cada app tenga entrada, certificado, log y prueba de vuelta. El proxy deja de ser una caja suelta cuando alguien puede leer una ruta, apagar un backend y ver el error correcto.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.