Guía y solución de problemas del puerto localhost 127.0.0.1:57573
Ejecuta un pequeño script de Flask. Pega `http://127.0.0.1:57573` en el navegador. Dos resultados posibles: la página se carga o la terminal se ilumina en rojo con `ECONNREFUSED` y el navegador muestra el triste icono de un enchufe desconectado.
Ninguno de los dos resultados es misterioso. La dirección tiene dos partes: 127.0.0.1 es la interfaz de bucle invertido IPv4 y 57573 es un puerto que el sistema operativo seleccionó casi al azar de su grupo de puertos altos. Esta guía analiza ambas partes. Veremos por qué tantos servidores locales terminan en un puerto como este y repasaremos los seis problemas que pueden surgir antes de que se establezca la conexión. Al final, sabrá cómo vincular un servicio a la interfaz correcta, ver qué está escuchando en un puerto, solucionar conflictos de puertos y bloqueos del firewall, y proteger el servidor local antes de conectarlo a internet.
Qué significa 127.0.0.1:57573 en lenguaje sencillo
Tres partes. La dirección IP 127.0.0.1 es la interfaz de bucle invertido IPv4. Los dos puntos indican "y en este puerto". 57573 es el puerto en sí, ubicado en el rango de números altos que ningún servicio ampliamente implementado posee de forma permanente.
Conéctate a ella y el kernel enrutará el paquete directamente a tu máquina local. Sin tarjeta de red. Sin conmutador. Sin conexión a través de ningún cable. La dirección permite que un proceso se comunique con otros procesos en el mismo host sin exponer nada a una red externa. Esa es la esencia del bucle de retorno.
La reserva es anterior a la mayoría de los desarrolladores que la utilizan. La RFC 1122, sección 3.2.1.3, bloqueó permanentemente todo el bloque 127.0.0.0/8, con sus 16.777.216 direcciones, allá por 1989. El Registro de Direcciones de Propósito Especial IPv4 de la IANA, regido por la RFC 6890 y actualizado por la RFC 8190, marca el mismo bloque como no reenviable, no enrutable globalmente y reservado por protocolo. Cualquier proceso que escuche en 127.0.0.1 solo ve tráfico de su propio host. Cualquier paquete proveniente del exterior que reclame una dirección de origen 127 se descarta silenciosamente. Los expertos en redes llaman a esos paquetes "marcianos".
El nombre "localhost" es simplemente un nombre de host más fácil de recordar para la misma idea. Abre el archivo `/etc/hosts` en macOS o Linux, o `C:\Windows\System32\drivers\etc\hosts` en Windows, y verás esta línea cerca del principio: `127.0.0.1 localhost`.
La dirección Loopback: cómo localhost enruta a su máquina.
127.0.0.1 es la más conocida. Pero no es la única. Todo el bloque 127.0.0.0/8, con sus más de dieciséis millones de direcciones, funciona como un bucle. En Linux, se puede hacer ping a 127.42.42.42. Funciona. La mayoría usamos 127.0.0.1 por inercia, pero el bloque más amplio es importante al leer las reglas de iptables o auditar una imagen reforzada. (Desde hace años circula en el IETF un borrador que propone recuperar la mayor parte del bloque 127/8 para uso unicast. No se ha adoptado).
El lado IPv6 es más ligero. Una sola dirección, `::1`, definida en RFC 4291. Sin /8. Sin reservas. Si su servicio se enlaza solo a `::1`, cualquier intento de 127.0.0.1 no tendrá éxito, y viceversa. En un sistema Linux moderno y en macOS, `localhost` se resuelve en ambas direcciones, por lo que el navegador suele intentar primero con `::1`, falla y luego recurre a otra. Esto se manifiesta como un pequeño pero perceptible retraso. Si se fija a una sola dirección dentro del script, la ambigüedad desaparece.
El kernel gestiona los paquetes de bucle invertido en una interfaz virtual. Linux la denomina `lo` y macOS, `lo0`. Los comandos `ip link show` e `ifconfig lo0` la mostrarán. El mismo cortafuegos que controla todo lo demás también controla el bucle invertido, por lo que una configuración de cortafuegos agresiva puede interrumpir el tráfico local. Hablaremos de esto con más detalle en las próximas secciones.
En resumen, para el desarrollo: 127.0.0.1 es la interfaz más segura a la que conectarse. Nada fuera de tu máquina puede acceder a ella. Los contenedores y las máquinas virtuales tienen su propio bucle de retorno, separado del del host, lo que suele confundir a la mayoría de los desarrolladores la primera vez que esperan que 127.0.0.1 dentro de un contenedor Docker acceda automáticamente a un servicio en el portátil.
¿Por qué el puerto 57573? Explicación de los rangos de números de puerto de IANA.
El puerto 57573 no tiene nada de especial. El sistema operativo o el framework lo utilizaron porque estaba libre. Para comprender por qué aparece un número tan grande con tanta frecuencia, hay que analizar cómo la IANA divide el espacio de puertos de 16 bits. Todo el esquema se encuentra en el RFC 6335 y en el Registro de Nombres de Servicio y Números de Puerto de Protocolo de Transporte de la IANA.
| Rango | nombre de IANA | Ejemplos |
|---|---|---|
| 0–1023 | Sistema / puertos conocidos | 22 SSH, 80 HTTP, 443 HTTPS, 53 DNS |
| 1024–49151 | Puertos de usuario/registrados | 3306 MySQL, 5432 Postgres, 8080 alt-HTTP |
| 49152–65535 | Dinámico / privado / efímero | Asignado automáticamente por el sistema operativo, nunca registrado en IANA. |
49152–65535 es el rango que IANA recomienda para puertos efímeros. Los núcleos reales a menudo discrepan. Linux viene con 32768–60999 por defecto (`sysctl net.ipv4.ip_local_port_range`). Windows, desde Vista, ha usado 49152–65535. La era de XP usaba 1025–5000, un rango estrecho que consumía puertos bajo carga y producía famosas interrupciones. macOS se apega a la especificación de IANA. El puerto 57573 se ajusta a todos los valores predeterminados modernos. Ese simple hecho explica la mayor parte de por qué aparece en los registros de desarrollo.
Cuando tu código hace `app.run(port=0)` en Flask, o `server.listen(0)` en Node, el sistema operativo elige cualquier puerto libre de su rango dinámico local. En una computadora portátil Linux, eso significa cualquier puerto entre 32768 y 60999. El puerto 57573 se encuentra cómodamente dentro de ese rango. Lo mismo sucede con las herramientas de asignación automática: Vite (que deliberadamente estableció por defecto 127.0.0.1 en 2022 para evitar que los desarrolladores filtraran servidores en redes wifi de cafeterías), webpack-dev-server, VS Code Live Server, Jupyter, puentes de controladores de Selenium, Playwright, el depurador `--inspect=0` de Node. Todos ellos simplemente le piden al kernel un puerto alto libre y usan el que encuentren.
Si el puerto 57573 aparece en un rastreo de pila, la respuesta más sencilla suele ser la correcta. O bien algún proceso se configuró allí a propósito, o bien un framework solicitó "cualquier puerto libre" y el kernel eligió este. El puerto 57573 en sí no presenta ningún problema. La mayoría de los frameworks locales de pruebas y desarrollo consideran todo el rango alto como un entorno seguro y aislado, ya que ningún servicio público depende de él.
Vinculación de un servidor a 127.0.0.1 vs 0.0.0.0 vs ::1
Si eliges el destino de enlace incorrecto, obtendrás errores extraños. Tres definiciones que debes tener claras.
La dirección 127.0.0.1 enlaza únicamente la interfaz de bucle invertido IPv4. Es accesible desde la misma máquina en cualquier cliente IPv4. Nunca desde fuera.
::1 enlaza únicamente el bucle de retorno IPv6. La misma idea, pero solo para clientes IPv6 en el mismo equipo.
La dirección IP 0.0.0.0 enlaza todas las interfaces IPv4 del dispositivo. Cualquiera que se conecte a su máquina puede acceder a ella, incluidos los teléfonos en la misma red Wi-Fi, los pares VPN y (con redireccionamiento de puertos) la internet pública.
Para el desarrollo diario, usa la interfaz 127.0.0.1. Es la única interfaz donde los firewalls, las políticas de VPN y las exposiciones accidentales dejan de ser un problema. Flask, FastAPI y Express la usan por defecto.
La gente tiende a usar 0.0.0.0 desde tres lugares diferentes, según mi experiencia. Pruebas en un teléfono a través de la LAN. Pruebas dentro de Docker. Siguiendo un tutorial cuyo autor copió y pegó la configuración predeterminada incorrecta. Cada uno tiene una forma más segura de hacerlo. Para pruebas en LAN, enlaza a la IP específica de la LAN y agrega una regla de firewall temporal. Para Docker, enlaza 0.0.0.0 dentro del contenedor, pero publica en el host con `docker run -p 127.0.0.1:8080:8080 …`. Para tutoriales, ignora la línea 0.0.0.0 y fija la dirección a 127.0.0.1 a menos que tengas una razón real.
Un fragmento de código Flask bastante simple muestra la configuración predeterminada segura:
```
desde matraz importar Matraz
aplicación = Flask(__name__)
@app.route("/")
def index():
devolver "¡Hola, localhost!"
if __name__ == "__main__":
app.run(host="127.0.0.1", port=57573)
```
Inspeccionando el puerto 57573 con netstat, lsof y ss
Algo está escuchando en el puerto 57573 y no tienes ni idea de qué es. El comando depende de tu sistema operativo. Memoriza esta breve lista y la usarás durante años.
| Sistema operativo / shell | Dominio | Notas | |
|---|---|---|---|
| Linux (moderno) | `ss -tlnp \ | grep :57573` | Reemplaza netstat. Muestra el proceso si se ejecuta como root. |
| Linux (versión anterior) | `netstat -tlnp \ | grep :57573` | Es posible que net-tools no se pueda instalar en imágenes pequeñas. |
| macOS | `lsof -i :57573` | Lo mismo ocurre en Linux. Incluye procesos y usuarios. | |
| Símbolo del sistema de Windows | `netstat -ano \ | findstr :57573` | La columna PID se asigna al Administrador de tareas. |
| Windows PowerShell | `Get-NetTCPConnection -LocalPort 57573` | Más limpio, programable |
Salida típica de Linux:
```
$ ss -tlnp | grep 57573
ESCUCHAR 0 4096 127.0.0.1:57573 0.0.0.0:* usuarios:(("python3",pid=18432,fd=4))
```
Seis campos, de izquierda a derecha. Estado. Cola de envío. Cola de recepción. Dirección local. Dirección del par. El proceso. PID 18432 en este caso. `kill 18432` en Unix. `Stop-Process -Id 18432` en PowerShell. Listo. Si solo querías que el puerto volviera a funcionar, esa es la solución completa.
¿Y si no aparece nada? En ese caso, nadie está escuchando, lo cual, en sí mismo, es información útil. Ese error del navegador que ves constantemente, "Conexión rechazada", suele significar precisamente eso: tu servidor no funciona. Falló al iniciarse o nunca se conectó a la dirección que escribiste.
Errores comunes de conexión y su significado
Seis cosas. Esa es la lista completa de fallos que verá en 127.0.0.1:57573. Lea la cadena de error y seleccione un cubo.
`EADDRINUSE`, "Dirección ya en uso" o "El puerto 57573 ya está asignado" significan lo mismo. Otra aplicación está usando el puerto. Los comandos de inspección de la sección anterior te indican cuál es. Finalízala o simplemente usa un puerto diferente para tu servicio. Herramientas como netstat o lsof completan la tarea en una sola línea.
`ECONNREFUSED`, la cadena de "Conexión rechazada" más amigable, indica: TCP llegó al kernel, pero nadie respondió. Tu servidor falló al iniciarse o nunca se conectó. Revisa la terminal donde lo ejecutaste. El rastreo de errores está ahí mismo.
Los mensajes `ETIMEDOUT` y "Connection timed out" indican que los paquetes se pierden silenciosamente. En 127.0.0.1, esto no debería ocurrir nunca. Si sucede, la causa suele ser una regla del firewall, un agente VPN o alguna herramienta de protección de endpoints. Desactívelos uno por uno, vuelva a intentarlo y repita el proceso.
El error `EACCES` ("Permiso denegado") aparece al intentar enlazar a un puerto inferior a 1024 sin permisos de administrador. Utilice un puerto alto como el 57573 o ejecute el binario como administrador. La tercera opción no existe.
Los errores `EAI_NONAME` y otros errores DNS indican que el nombre de host no se resolvió. El archivo hosts debería asignar `localhost` a 127.0.0.1. Es posible que un cliente VPN lo haya modificado. También es posible que un administrador de sistemas haya distribuido una imagen defectuosa. Abra el archivo hosts y confirme que `127.0.0.1 localhost` es la primera línea que no es un comentario.
El último, el más astuto. Tras un apagado limpio, el kernel bloquea el socket en TIME_WAIT durante aproximadamente dos minutos. Reinicia el servidor rápidamente y verás el mensaje "Dirección ya en uso" aunque nadie esté escuchando. Tres soluciones: esperar, configurar `SO_REUSEADDR` en tu archivo bind o simplemente cambiar a un puerto diferente. La mayoría optamos por cambiarlo.
Lee la cadena de error. Selecciona el cubo. Aplica la solución. El ciclo completo suele finalizar en menos de un minuto.
Configuración del firewall que bloquea el puerto 57573
En teoría, el tráfico de bucle invertido siempre está permitido. En la práctica, las reglas del cortafuegos a veces lo impiden. Los sospechosos habituales en 2026:
- El Firewall de aplicaciones de macOS con la opción "Bloquear conexiones entrantes" configurada en modo estricto. Añada el binario propietario del puerto 57573 a la lista de permitidos en Configuración del sistema → Red → Firewall.
- Un perfil del Firewall de Windows Defender no coincide. Una nueva herramienta para desarrolladores te pide permiso para acceder. Instintivamente, haces clic en Cancelar. Se bloquea silenciosamente. Abre `wf.msc`, elimina la regla de denegación y acepta la solicitud la próxima vez.
- Linux ufw o iptables con políticas predeterminadas más estrictas. `ufw status verbose` muestra las reglas. `ufw allow from 127.0.0.1` abre la interfaz loopback explícitamente. La mayoría de las distribuciones ya permiten `lo` por defecto, pero algunas imágenes reforzadas no.
- Una VPN corporativa o un agente de confianza cero intercepta el tráfico. Algunos agentes actúan como proxy para las conexiones locales a través de un oyente en el espacio de usuario y manipulan silenciosamente el bucle de retorno. Desactive el agente durante un minuto para confirmarlo.
- Antivirus o protección de endpoints. Los productos EDR a veces bloquean los binarios de desarrollo que se vinculan a puertos altos hasta que se incluyan en la lista blanca.
En cualquier entorno corporativo gestionado, es probable que se produzca al menos uno de estos problemas. El proceso de diagnóstico es el mismo: compruebe la configuración del cortafuegos y, a continuación, ejecute `curl http://127.0.0.1:57573` desde la misma consola que inició el servidor. ¿Funciona Curl pero falla el navegador? Está accediendo a la interfaz incorrecta (a menudo `::1` en lugar de 127.0.0.1) o se está aplicando una política de acceso a la red privada. ¿También falla Curl? El kernel o el cortafuegos están interceptando el paquete antes de que llegue a su código. Los desarrolladores web y los administradores de red comparten estos consejos en wikis internas porque los síntomas parecen idénticos hasta que se repiten.
Localhost en Docker, WSL y GitHub Codespaces
Tres situaciones en las que localhost deja de comportarse como se espera.
Docker primero. Dentro de un contenedor, 127.0.0.1 es la interfaz de bucle invertido del contenedor . No la tuya. Así que si tu portátil ejecuta un servicio en 127.0.0.1:57573, el contenedor no puede acceder a él con esa misma dirección. Nunca. La puerta de enlace del host reside en otro lugar: `host.docker.internal` en Mac y Windows, o alguna IP de puente en Linux. La dirección inversa (servicio del contenedor, host que llama) necesita una bandera de publicación. `docker run -p 127.0.0.1:57573:57573 my-image`. Elimina `-p` y el puerto simplemente no existe fuera del contenedor.
WSL2 tiene su propia personalidad. El modo de red espejo (opcional en Windows 11 22H2 y posteriores, mediante `[wsl2] networkingMode=mirrored`) comparte la pila de red del host con la máquina virtual WSL. En ese modo, un servicio en 127.0.0.1:57573 dentro de WSL responde en Windows en la misma dirección. El modo NAT predeterminado sigue reenviando puertos, pero solo para cadenas `localhost`, no siempre para la dirección literal 127.0.0.1. También hay un error conocido y molesto, registrado como Microsoft WSL #40169. El modo espejo bloquea silenciosamente grandes segmentos de puertos altos. Los intentos de enlace en 127.0.0.1 fallan con `WinError 10013`, que Python informa como `PermissionError`. Cuando un puerto se niega a enlazar en Windows sin una razón aparente, verifique esto primero.
GitHub Codespaces y VS Code Remote SSH funcionan en sentido contrario. Reenvían los puertos automáticamente. Si inicias un servidor dentro de un Codespace en 127.0.0.1:57573, el editor abre un túnel que expone ese puerto en una URL única de github.dev. La pestaña del navegador que abres en tu portátil se comunica con esa URL, no con 127.0.0.1, y la solicitud pasa a través del túnel de vuelta al espacio de trabajo.
El nombre del punto final parece el mismo, pero la ruta que sigue el paquete es completamente diferente en cada entorno. Dedicar cinco minutos a averiguar en qué entorno te encuentras te ahorra veinte minutos viendo un mensaje de "conexión rechazada".
HTTPS en Localhost: Mejores prácticas para un desarrollo local seguro
Los navegadores modernos y muchas API exigen HTTPS incluso para el desarrollo local. Los service workers, la geolocalización, la API del portapapeles y cualquier cookie marcada como «Segura» no funcionan con HTTP sin cifrado. Hay una excepción: 127.0.0.1, que el navegador ya considera un contexto seguro. Esta excepción cubre la mayoría de los usuarios que realizan desarrollo ocasionalmente. Para todo lo demás, utilice TLS localmente.
La herramienta más limpia, con mucha diferencia, es mkcert, escrita por Filippo Valsorda. Ejecútala una vez con `mkcert -install`, luego `mkcert localhost 127.0.0.1 ::1`, y obtendrás un certificado `localhost+2.pem` más una clave. Apunta tu servidor de desarrollo a este par de certificados. El navegador mostrará un candado limpio sin advertencias, porque mkcert instaló una CA raíz local en tu sistema y en los almacenes de confianza de Firefox. Let's Encrypt no puede emitir un certificado real para `127.0.0.1`, ya que no hay un dominio que validar, por lo que una CA local es la solución estándar.
Otros patrones que vale la pena conocer:
- Para realizar pruebas automatizadas, utilice un servicio de DNS mágico (`nip.io`, `sslip.io`, `traefik.me`, `localhost.direct`) para convertir una IP en un nombre de host real como `127.0.0.1.nip.io`. Let's Encrypt o ZeroSSL pueden certificarlos, e incluso `localhost.direct` publica un certificado comodín preemitido.
- Vincula tu servicio a 127.0.0.1, no a 0.0.0.0, para que el certificado (que cubre `127.0.0.1`) coincida realmente.
- Mantén los certificados de desarrollo fuera de Git. Por defecto, mkcert los guarda en tu directorio de trabajo. Añade el par a `.gitignore` inmediatamente.
- Rote la CA local cada pocos meses. El comando `mkcert -uninstall` la elimina.
- Si utilizas un proxy corporativo MITM, ten en cuenta que este intercambiará tus certificados. Deshabilita el proxy en `127.0.0.1` si tus herramientas lo permiten.
Los navegadores también tienen una regla especial que conviene conocer. Según la especificación de contextos seguros del W3C, `http://127.0.0.1`, `http://localhost` y `http://[::1]` se consideran "potencialmente confiables", lo que permite que una página HTTPS las acceda sin activar un bloqueo de contenido mixto. Esta excepción está pensada específicamente para el desarrollo local.
Localhost no es una barrera de seguridad como suelen suponer los desarrolladores. Los navegadores pueden ser engañados para acceder a él desde sitios web arbitrarios mediante la reconfiguración de DNS, donde un sitio malicioso resuelve su nombre de host a 127.0.0.1 y permite que JavaScript en la página del atacante se comunique con servicios locales bajo el origen del sitio original. El caso canónico de Zoom de 2019 (CVE-2019-13450) es el ejemplo paradigmático. Zoom instaló un servidor web oculto en `localhost:19421` en macOS para que los enlaces de las reuniones pudieran iniciar la aplicación de escritorio, y cualquier sitio web podía acceder a él para unir forzosamente al usuario a una reunión con la cámara encendida. Aproximadamente 4 millones de Macs se vieron afectados, además de trece clientes de marca blanca distribuidos con el mismo motor. Chrome 142, lanzado a finales de 2025, reemplazó el antiguo sistema de Acceso a Red Privada por el Acceso a Red Local. Las páginas públicas ahora necesitan una solicitud de permiso explícita antes de poder acceder a direcciones de bucle invertido o privadas, lo que elimina la mayoría de las técnicas automatizadas por Singularity de NCC Group. Un aviso de Straiker de 2025 documentó el mismo ataque contra servidores del Protocolo de Contexto de Modelo (MPP) que se ejecutan localmente, lo que se ha convertido en una superficie de rápido crecimiento a medida que los desarrolladores ejecutan más agentes LLM en bucle invertido. Vincule estrictamente a 127.0.0.1, requiera autenticación, verifique el encabezado `Origin` y evite CORS comodín en las API de desarrollo. Estas cuatro prácticas detectan la mayoría de estos ataques.
Consejos para la resolución de problemas y una lista de verificación de diagnóstico rápido.
Cuando 127.0.0.1:57573 se niega a responder, revise esta breve lista antes de sospechar de magia más profunda.
1. Confirma que el servidor esté funcionando. Revisa la terminal desde donde lo iniciaste. Si falló, el registro de errores estará ahí mismo.
2. Confirma que está vinculado a 127.0.0.1, no a 0.0.0.0 ni a ::1 solamente. La mayoría de los frameworks imprimen la dirección de enlace al iniciar. Lee la línea.
3. Prueba con `curl -v http://127.0.0.1:57573` desde la misma terminal. ¿Funciona Curl? El problema está en el navegador, no en el servidor.
4. Averigüe quién es el propietario del puerto. Linux, `ss -tlnp | grep :57573`. macOS, `lsof -i :57573`. Windows, `netstat -ano | findstr :57573`.
5. ¿El proceso incorrecto lo está utilizando? Finalícelo y luego reinicie el servidor.
6. ¿No hay nada escuchando? Mira el registro de inicio. `EACCES` significa puerto privilegiado. `EADDRINUSE` generalmente significa TIME_WAIT obsoleto.
7. Prueba con el formato IPv6. `curl http://[::1]:57573`. Si funciona `127.0.0.1` o `::1` y el otro no, tu servicio es de pila única.
8. Prueba con un puerto diferente: pasa `--port 12345` (o el que sea) y reinicia. ¿Funciona con el nuevo puerto? Tienes un conflicto específico de puerto.
9. Desactive la VPN, el antivirus y los agentes de punto final durante un minuto. Si el número 57573 empieza a responder, significa que alguno de ellos estaba consumiendo el tráfico.
10. Reiniciar, o al menos reiniciar la interfaz de red. Casi nunca es la solución. Elimina los sockets obsoletos y el estado bloqueado del firewall cuando nada más funciona.
Para la mayoría de los problemas de desarrollo, los primeros cuatro pasos de solución de problemas permiten identificar la causa del fallo de conexión. El resto abarca los casos realmente extraños, donde una discrepancia en la dirección IPv6, sockets obsoletos o una capa de firewall restrictiva ocultan el verdadero problema. Lea el mensaje de error y luego siga la lista de pasos.
Una nota relevante para Plisio. Al integrar los webhooks de un procesador de pagos de criptomonedas, la pasarela necesita una URL pública a la que pueda enviar solicitudes POST. Las facturas de Plisio aceptan una `callback_url` en la carga útil de la API, y el sistema envía actualizaciones de estado a ese endpoint. Su servidor local en 127.0.0.1:57573 es inaccesible desde internet pública por definición, por lo que la solución estándar es un túnel. En 2026, las opciones más comunes son ngrok (Personal $8/mes, Pro $20/mes), Cloudflare Tunnel (gratis hasta 50 usuarios en Zero Trust) y Tailscale Funnel (gratis para uso personal, equipos de pago desde $6/usuario/mes). Cada uno toma un nombre de host público y reenvía el tráfico a la dirección 127.0.0.1:57573 de su computadora portátil. Los SDK de Plisio para Python, PHP y Node incluyen una función auxiliar `validate_callback` que verifica el `verify_hash` de HMAC-SHA1 sobre el cuerpo JSON ordenado, por lo que una vez que el túnel está configurado, el mismo controlador funciona de forma idéntica tanto en desarrollo como en producción.
