Reemplazar nginx con Go: ¿vale la pena en 2026?
Un desarrollador que aprendía Go decidió reemplazar nginx en su VPS con un proxy inverso que escribió desde cero. El resultado, publicado el 20 de mayo de 2026, está corriendo en producción en niixlabs.com bajo el nombre apexproxy: soporte TLS automático vía Let’s Encrypt, routing por host y path, load balancing y un dashboard TUI en tiempo real. Sin certbot, sin nginx.conf.
En 30 segundos
- niixdan reemplazó nginx con un proxy escrito en Go que hoy está en producción en niixlabs.com (mayo 2026).
- apexproxy tiene routing por host/path, wildcard subdomains, TLS automático y dashboard TUI con métricas en vivo.
- La configuración es YAML legible en vez de nginx.conf, lo que redujo los errores de setup del autor.
- Lo que todavía falta: hot-reload sin cortar conexiones, rate limiting y health checks activos.
- Go no es más rápido que nginx en throughput puro, pero tiene latencias más predecibles en cargas mixtas.
Por qué nginx se vuelve incómodo en la práctica
Nginx es un proxy inverso probado durante más de 20 años. Eso nadie lo discute. El problema aparece en el día a día: cada vez que tocás la configuración, terminás leyendo la documentación de nuevo para recordar por qué proxy_set_header Connection 'upgrade' tiene que ir ahí y no en otro bloque, o por qué una directiva dentro de location no hereda lo que definiste en server.
La sintaxis de nginx.conf es un lenguaje que conocés a medias. No es que sea malo, es que fue diseñado para otra época donde la configuración la tocaba una vez al año el sysadmin de turno. Hoy los equipos de desarrollo la modifican seguido, y cada cambio es una sesión de arqueología.
niixdan lo planteó exactamente así: quería un sistema donde “la configuración se pareciera a lo que estaba haciendo”. Eso es un problema de legibilidad, no de rendimiento.
Go como lenguaje ideal para escribir servidores de red
Ponele que querés manejar 10.000 conexiones simultáneas. En Go, eso son goroutines: livianas, gestionadas por el runtime, sin el overhead de threads del sistema operativo. La stdlib ya trae httputil.ReverseProxy, que hace el trabajo grueso de proxying con soporte para WebSockets y HTTP/2. Relacionado: soluciones de automatización DevOps.
Lo que más importa para deployment es que Go compila a un binario único. Sin dependencias de runtime, sin “pero en mi máquina funciona”. Copiás el binario al VPS y listo. Comparado con nginx, que en algunos sistemas necesita módulos adicionales, configuración de systemd, certbot aparte y ajustes de permisos, la diferencia operacional es real.
El garbage collector de Go tiene latencias predecibles si lo configurás bien (GOGC, GOMEMLIMIT). No es C, pero para la mayoría de los casos de proxy con lógica de negocio, el GC no es el cuello de botella.
Características de un reverse proxy moderno: qué debería poder hacer
Un proxy para producción necesita más que “reenviar requests”. El estándar mínimo hoy incluye:
- Routing por host y path con prioridad configurable (para evitar ambigüedades entre rutas)
- Wildcard subdomain matching (*.dominio.com apuntando a distintos backends)
- Load balancing con al menos round-robin pesado e ip-hash para sesiones sticky
- TLS automático sin certbot: Let’s Encrypt integrado, renovación automática
- Certificados por ruta (útil cuando tenés dominios custom de clientes)
- Observabilidad: tráfico en vivo, latencia por ruta, bandwidth consumido
Lo interesante es que apexproxy toca todos esos puntos. Lo que todavía no tiene, según el propio autor: hot-reload sin bajar conexiones, rate limiting (token bucket está en el roadmap), backend lookup dinámico via Redis, y health checks que detecten backends caídos proactivamente. El core funciona. El resto es deuda técnica declarada. Esto se conecta con lo que analizamos en consideraciones de arquitectura web moderna.
Apexproxy: configuración YAML vs nginx.conf
La apuesta principal de apexproxy es la legibilidad. En vez de nginx.conf con bloques anidados y directivas que saben a dialecto propio, la configuración es YAML estándar. Instalás con:
go install github.com/niix-dan/apexproxy@latest
Y arrancás con:
apex start --config ./apex.yaml
El TUI dashboard es la feature más llamativa: muestra tráfico en vivo, latencia y bandwidth por ruta, sin necesidad de Grafana ni Prometheus. Para un VPS personal o un proyecto pequeño, eso es suficiente visibilidad sin infraestructura adicional.
¿Y qué pasó cuando lo pusieron en producción real? Funciona. niixlabs.com está corriendo sobre esto desde mayo 2026. No es un benchmark controlado, es un sitio real con tráfico real. (Que sea el sitio del propio autor ayuda, porque puede ver qué pasa en el momento.)
Comparativa de rendimiento: Go vs nginx
Acá viene lo importante: reemplazar nginx con Go no es gratis en throughput puro. Los benchmarks de reverse proxies en Go, Rust y C muestran que nginx sigue ganando en requests por segundo cuando la carga es predecible y el workload es estático. La distancia varía según el hardware y el tipo de carga, pero en escenarios simples nginx tiene entre 10% y 30% más throughput.
El área donde Go compite mejor: latencia en percentil 95 y 99. En cargas mixtas (requests pesados y livianos mezclados), el event loop de nginx puede generar picos de latencia. Go con goroutines aísla mejor el trabajo. Para APIs que mezclan endpoints rápidos y lentos, eso importa.
| Criterio | nginx | Proxy en Go (apexproxy) |
|---|---|---|
| Throughput máximo (estático) | Mayor en benchmarks | 10-30% menor en cargas simples |
| Latencia p99 (carga mixta) | Más variable | Más predecible con tuning de GC |
| Configuración | nginx.conf (curva alta) | YAML (más legible) |
| TLS | Requiere certbot externo | Let’s Encrypt integrado |
| Deployment | Múltiples dependencias | Binario único |
| Observabilidad built-in | Logs básicos, módulos extra | Dashboard TUI nativo |
| Ecosistema / documentación | 20 años de wiki y Stack Overflow | Proyecto nuevo, docs en crecimiento |
| Lógica de negocio en proxy | Complejo (Lua, módulos C) | Go nativo, fácil de extender |
Cuándo reemplazar nginx está justificado (y cuándo no)
Hay casos donde escribir tu propio proxy en Go tiene sentido real:
- El proxy necesita lógica de negocio: autenticación, transformación de requests, routing condicional por claims del JWT.
- El equipo ya trabaja en Go y quiere una herramienta que puedan mantener sin cambiar de lenguaje.
- Es un proyecto personal o startup chica donde la deuda técnica de “no tenés health checks” es manejable.
- Querés aprender cómo funciona un proxy por adentro (que es exactamente el caso de niixdan).
Eso sí: hay situaciones donde esta decisión sale cara.
Si tenés alta carga y necesitás la estabilidad comprobada de 20 años de nginx en producción, escribir tu propio proxy es un riesgo que no se justifica. Si el equipo no tiene experiencia en Go, agregar un binario custom que nadie más entiende es un problema operacional. Y si el proyecto crece más rápido de lo que podés agregar features al proxy (rate limiting, health checks, hot-reload), vas a quedar corriendo detrás. Sobre eso hablamos en ejecutar servicios sin dependencias externas.
Para VPS y proyectos personales con deploy en donweb.com u otro proveedor, un proxy en Go propio puede ser perfectamente suficiente. Para e-commerce con tráfico real en horarios pico, todavía conviene nginx o Caddy.
Qué está confirmado / Qué todavía no
Confirmado en producción (mayo 2026)
- Routing por host y path con prioridad configurable
- Wildcard subdomain matching
- Load balancing: weighted round-robin, ip-hash, single backend
- TLS automático vía Let’s Encrypt (sin certbot)
- Certificados por ruta
- Dashboard TUI con tráfico en vivo, latencia y bandwidth por ruta
En el roadmap pero no disponible aún
- Hot-reload sin bajar conexiones existentes
- Rate limiting (token bucket)
- Backend lookup dinámico via Redis
- Health checks que detecten backends caídos proactivamente
Errores comunes al escribir un proxy inverso en Go
Copiar headers sin filtrar
El error más común: pasarle todos los headers del request original al backend sin limpiar. Cabeceras como X-Forwarded-For pueden ser falsificadas por el cliente. Si tu backend confía en esas cabeceras para autenticación o rate limiting, tenés un problema de seguridad. Tenés que sobrescribirlas explícitamente en el proxy antes de hacer el forward.
No manejar WebSocket correctamente
Si alguna vez configuraste WebSocket con nginx, sabés que la magia está en esos dos headers: Upgrade y Connection. En Go pasa lo mismo. httputil.ReverseProxy no maneja el upgrade de WebSocket por defecto. Si tu backend usa WS y no implementás el hijacking de la conexión, el cliente recibe un error 502 sin mensaje claro. La solución está documentada en la stdlib pero hay que agregarla explícitamente.
Confiar en que el binario único “no necesita monitoreo”
La simplicidad del deploy de Go (un binario, sin dependencias) lleva a subestimar el monitoreo. Nginx tiene 20 años de integraciones con Prometheus, Grafana, y sistemas de alertas. Un proxy en Go custom tiene lo que vos le codificás. El dashboard TUI de apexproxy sirve para ver en vivo, pero si el proceso se cae a las 3am, necesitás alertas configuradas aparte. No des por sentado que simplicity en deployment es simplicity en operación.
Preguntas Frecuentes
¿Es posible reemplazar nginx con una aplicación escrita en Go?
Sí, y ya hay casos en producción. niixdan reemplazó nginx con apexproxy en niixlabs.com en mayo de 2026. Go tiene todo lo necesario en su stdlib para construir un proxy inverso funcional: httputil.ReverseProxy, soporte TLS nativo, y concurrencia con goroutines. La pregunta no es si es posible, sino si es conveniente para tu caso específico. Ya lo cubrimos antes en privacidad y seguridad en infraestructura.
¿Cuáles son las ventajas de escribir tu propio proxy inverso?
Control total sobre la lógica: podés agregar autenticación, transformar requests, o hacer routing condicional en Go puro sin plugins ni módulos externos. El deploy es un binario único sin dependencias. Y la configuración puede ser tan legible como quieras diseñarla. La desventaja es que asumís el mantenimiento de una pieza crítica de infraestructura.
¿Cómo se compara el rendimiento de un proxy en Go versus nginx?
Nginx tiene mayor throughput en workloads estáticos y simples, con diferencias de entre 10% y 30% en benchmarks controlados. Go es más predecible en latencias de percentil alto (p95, p99) en cargas mixtas. Para la mayoría de los proyectos medianos, la diferencia de throughput no es el factor determinante. El cuello de botella suele estar en el backend, no en el proxy.
¿Qué características debe tener un reverse proxy en Go para producción?
Mínimo indispensable: TLS automático (Let’s Encrypt o similar), routing por host y path, manejo correcto de WebSocket, limpieza de headers de seguridad, y algún mecanismo de observabilidad. Antes de considerarlo listo para carga real, también necesitás health checks activos sobre los backends y hot-reload sin bajar conexiones. Estas dos últimas no las tiene apexproxy todavía.
¿Qué sintaxis es mejor para configurar un proxy: YAML o nginx.conf?
Depende del equipo. YAML es más legible para developers que ya trabajan con Docker Compose o Kubernetes. nginx.conf tiene más poder expresivo para configuraciones complejas, pero requiere conocer la sintaxis específica del lenguaje de nginx. Para proyectos nuevos en equipos de desarrollo, YAML gana en mantenibilidad. Para sysadmins con años de experiencia en nginx, la curva está al revés.
Conclusión
Que alguien ponga en producción un proxy escrito desde cero en Go demuestra que la barrera de entrada para reemplazar nginx bajó bastante. La stdlib de Go hace el trabajo pesado, el binario único simplifica el deploy, y el TLS automático elimina la dependencia de certbot.
Dicho esto: apexproxy es una herramienta nueva con deuda técnica declarada. Sin hot-reload ni health checks activos, no está lista para todo. Nginx sigue siendo la opción más segura para cargas altas con equipos que no quieren mantener infraestructura propia.
Donde tiene sentido probar este enfoque es en proyectos donde el proxy necesita lógica de negocio, o donde el equipo ya trabaja en Go y quiere una sola herramienta para todo. Para VPS personales y startups chicas, la propuesta vale la pena explorarla. Para el resto, nginx o Caddy siguen siendo la apuesta más conservadora.
Fuentes
- niixdan en Dev.to — I replaced nginx with a reverse proxy I wrote in Go (mayo 2026)
- kanywst en Dev.to — Go vs Rust vs C: Deep Dive into Reverse Proxy Performance
- Edgar Hernández en Medium — Mi viaje creando un reverse proxy en Go (parte 1)
- Jones Charles en Dev.to — Build Network Proxies and Reverse Proxies in Go: A Hands-On Guide
- KeepCoding — Guía de nginx.conf: sintaxis y configuración
