“Solicitud bloqueada. Este host no está permitido”: Guía rápida de la lista blanca de Host-Header para Vite, Rails, Django, Angular y Next.js

Empiezas un túnel, pegas la URL pública en un navegador y, en lugar de tu aplicación, obtienes un error plano. En un proyecto Vite se lee Blocked request. This host ("your-name.tunnel.example.com") is not allowed. En Rails obtienes una respuesta 403 Prohibido. En Django es un 400 Petición incorrecta. En el servidor de desarrollo de Angular es de nuevo el mensaje de Vite. En Next.js tu página puede cargarse, pero las solicitudes de desarrollo bajo /_next/* quedan bloqueadas.

Ninguna de estas situaciones es un fallo del túnel. Tu servidor de desarrollo recibió una solicitud para un hostname que nunca había visto y se negó a responder. Esta guía es una hoja de trucos por framework: la configuración exacta, qué acepta, cuál es la predeterminada y cómo configurarlo de forma segura. También explica por qué un subdominio estable del túnel convierte esto de una molestia recurrente en una única línea de configuración.

Por qué los servidores de desarrollo comprueban la cabecera Host

Cada solicitud HTTP lleva una cabecera Host que nombra el sitio con el que el navegador cree que está hablando. Históricamente, muchos servidores de desarrollo la ignoraban. Eso se convirtió en un problema debido al DNS rebinding. Una página web hostil se carga desde un dominio controlado por un atacante, el DNS del atacante empieza a responder con 127.0.0.1, y el navegador ahora trata tu servidor local como parte del origen del atacante. La página del atacante puede leer lo que devuelve tu servidor de desarrollo, incluido el código fuente.

Comprobar la cabecera Host frente a una lista blanca cierra esa puerta, porque el dominio del atacante no está en la lista. Rails describe su middleware como una salvaguarda contra DNS rebinding. La documentación de Vite dice que dejar su verificación amplia permite que cualquier sitio web descargue tu código fuente y contenido mediante DNS rebinding.

El costo es que un hostname de túnel legítimo también queda “desconocido” hasta que lo incluyas en la lista.

Un detalle específico de Vite importante para los túneles. La verificación de host de Vite se omite cuando el propio servidor de desarrollo sirve HTTPS. Muchos túneles terminan TLS en su borde y envían HTTP en claro a tu máquina, y en esa configuración la verificación aún se aplica.

Diagnóstico rápido: ¿qué capa te está bloqueando?

Framework	Configuración	Lo que ves
Vite	server.allowedHosts	403 con Blocked request. This host (...) is not allowed.
Rails	config.hosts	403 Prohibido; una página de depuración en desarrollo, un cuerpo vacío en otro caso; una línea Blocked hosts: en el registro
Django	ALLOWED_HOSTS	DisallowedHost (un SuspiciousOperation), devuelto como 400 Bad Request
Angular (dev server)	allowedHosts en angular.json	El mismo mensaje de Vite
Next.js	allowedDevOrigins	La página puede renderizar, pero los recursos de desarrollo como /_next/webpack-hmr quedan bloqueados, con una advertencia Blocked cross-origin request to Next.js dev resource en la terminal

Una regla útil: si el texto del error nombra el host y te indica qué añadir, la solicitud llegó a tu framework y el túnel está funcionando. Estás corrigiendo la configuración, no la red.

Semántica de comodines de un vistazo

Los frameworks no están de acuerdo en lo que significa un “wildcard”, y ahí es donde aparecen la mayoría de las sorpresas.

Framework	Sintaxis	¿Coincide con el dominio base?	¿Coincide con subdominios anidados?
Vite	.example.com	Sí	Sí (cualquier profundidad, según la documentación)
Rails	.example.com	Sí	Una etiqueta en la fuente actual; versiones anteriores eran más laxas
Django	.example.com	Sí	Sí (“cualquier otro subdominio”)
Next.js	*.example.com	No	No (exactamente una etiqueta)
Next.js	**.example.com	No	Sí (una o más etiquetas)
Angular dev server	igual que Vite	Sí	Sí

Cualquiera que uses, prueba un hostname de túnel real antes de asumir que un patrón funciona.

Vite: server.allowedHosts

Vite documenta server.allowedHosts como string[] | true, por defecto []. Por defecto acepta localhost, cualquier dominio bajo .localhost, y todas las direcciones IP. Todo lo demás devuelve 403.

La verificación llegó con la corrección para el aviso GHSA-vg6x-rcgg-rjx6 (CVE-2025-24010). El registro de cambios 6.0.9 enumera una verificación de Host-header que introdujo server.allowedHosts. Las versiones fijas del aviso son 6.0.9, 5.4.12 y 4.5.6. Por eso las actualizaciones a menudo activan el error en configuraciones que funcionaban durante meses.

// vite.config.js
import { defineConfig } from 'vite'

export default defineConfig({
  server: {
    allowedHosts: ['my-app.tunnel.example.com'],
  },
})

Un par de detalles útiles:

• Punto inicial. Una cadena que empieza con . permite ese hostname sin el punto más todos sus subdominios. Según la documentación, .example.com cubre example.com, foo.example.com y foo.bar.example.com. Hazlo solo para un dominio que posees.
• Nunca añadas un dominio de nivel superior como .com. La documentación advierte que cualquiera puede registrar un dominio y a qué resuelve.
• Variable de entorno. Configurar __VITE_ADDITIONAL_SERVER_ALLOWED_HOSTS añade hosts sin tocar el archivo de configuración. Separa varios hosts con comas. Esto es útil en CI, o en un repositorio compartido donde no quieras que se comente un nombre de túnel personal.
• vite preview es independiente. El servidor de vista previa tiene su propia preview.allowedHosts. Por defecto toma el valor de server.allowedHosts, así que configúralo explícitamente solo si ambos deben diferir. Lee el texto de error para ver a qué bloque apunta.
• Configuración relacionada: server.cors. El mismo aviso cambió el manejo de CORS de Vite. El valor por defecto ahora permite solo orígenes estilo localhost, y la documentación advierte que server.cors: true permite que cualquier sitio descargue su código fuente.
• Frameworks basados en Vite. Nuxt toma la opción bajo vite.server.allowedHosts en nuxt.config.ts. El panel de administración de Strapi 5 también corre sobre Vite. La propia entrada de Strapi dice que su configuración de desarrollo ahora establece allowedHosts: true internamente, así que en una versión actual de Strapi actualizar podría ser la solución. Si ves “edit vite.config.js” pero no tienes ese archivo, busca una clave vite en la configuración de tu framework.

Si la página carga pero el recargado en caliente falla, permitir el host soluciona la carga inicial, pero la sustitución de módulos en caliente usa un WebSocket. Los túneles que reescriben puertos pueden romperlo, y la guía de Strapi señala esto para ngrok, Cloudflare Tunnel y los reenviadores de puerto de VS Code. Las guías de Vite enumeran las configuraciones de WebSocket bajo server.ws, incluido clientPort, que anula el puerto al que el navegador se conecta. En las versiones actuales de Vite las opciones antiguas server.hmr quedan deprecated en favor de server.ws. En versiones antiguas de Vite todavía las encontrarás bajo server.hmr.

El atajo que verás en foros es allowedHosts: true. Volveremos a por qué es un valor por defecto problemático.

Rails: config.hosts

Rails llama a esto Autorización de Host, implementada por ActionDispatch::HostAuthorization. En desarrollo la lista blanca por defecto es .localhost, .test, y todas las direcciones IPv4 e IPv6. En otros entornos config.hosts está vacío por defecto. Cuando está vacío, el middleware no hace nada, por lo que la verificación solo impacta en desarrollo o cuando ya has configurado hosts tú mismo.

# config/environments/development.rb
config.hosts << "my-app.tunnel.example.com"

Qué te dice la fuente:

• Cadenas coinciden con el host con un puerto opcional. Una cadena que empieza con un punto (como .example.com) coincide con el dominio raíz más un subdominio. En la fuente actual eso es una etiqueta opcional ([a-z0-9-]+\\.), así que prueba nombres anidados como a.b.example.com antes de asumir que pasan. Las versiones anteriores usaban un patrón más laxo, por lo que el comportamiento puede variar entre versiones de Rails.
• Expresiones regulares, rangos IP y lambdas son aceptadas. Las entradas se comparan con ===, así que una lambda te da checks dinámicos. Las cadenas y las expresiones regulares obtienen el manejo de puerto y punto inicial, y una lambda no.
• X-Forwarded-Host también se verifica. El middleware bloquea una solicitud si ya sea Host o el último valor de X-Forwarded-Host no está permitido, lo que importa cuando hay un proxy delante.
• Exclusión por ruta. config.host_authorization = { exclude: -\u003e(request) { request.path =~ /healthcheck/ } } omite la verificación para solicitudes coincidentes, como sondas de salud de balanceadores.
• La respuesta es 403 Forbidden, y los hosts bloqueados se registran a nivel de error. El cuerpo contiene información de depuración solo si config.consider_all_requests_local es verdadero. De lo contrario está vacío, lo que puede hacer que los bloques de producción parezcan un misterio.
• Mantén Rails parcheado. Entradas con punto inicial combinadas con encabezados cuidadosamente manipulados de X-Forwarded-Host fueron objeto de avisos en el pasado, incluido CVE-2021-22881.

Debido a que un config.hosts vacío desactiva la verificación, config.hosts.clear es el equivalente de Vite a true. Trátalo de la misma manera.

Django: ALLOWED_HOSTS

Django introdujo ALLOWED_HOSTS en la versión 1.4.4 (2 de febrero de 2013) como corrección de seguridad para envenenamiento de la cabecera Host. En 1.4.4 el predeterminado era ['*'] por compatibilidad. Hoy el predeterminado es una lista vacía.

Con DEBUG = False, una lista vacía hace que cada solicitud falle con Bad Request (400). Con DEBUG = True y una lista vacía, la documentación actual dice que el host se valida contra ['.localhost', '127.0.0.1', '[::1]'], por lo que un hostname de túnel falla incluso en modo de depuración.

Ese comportamiento de depuración tiene su historia. Versiones anteriores omitían la verificación bajo DEBUG=True, lo que permitía ataques de DNS rebinding (CVE-2016-9014). Django lo solucionó en 1.10.3, 1.9.11 y 1.8.16.

# settings.py
ALLOWED_HOSTS = ["my-app.tunnel.example.com"]

• Coincidencia exacta. Los nombres se comparan con la cabecera Host sin distinguir mayúsculas/minúsculas y sin el puerto. Un punto final (forma FQDN) se elimina antes de la comparación.
• Punto inicial como comodín. .example.com coincide con example.com, www.example.com y cualquier otro subdominio. La documentación describe solo dos formas de comodines, el punto inicial y un * (coincide con todo). No documentan *.example.com.
• USE_X_FORWARDED_HOST. Si está habilitado, Django valida X-Forwarded-Host en lugar de Host.
• Advertencia de omisión. La validación ocurre en get_host(). El código que lee el encabezado desde request.META lo omite.

Un detalle adicional: una vez que la página se carga a través del túnel, los envíos de formularios aún pueden fallar la verificación CSRF de origen de Django. El origen del navegador es la URL del túnel, y Django debe estar de acuerdo. Agrega el origen completo, incluido el esquema, a CSRF_TRUSTED_ORIGINS. Esa configuración admite comodines de subdominio como https://*.example.com. Si tu túnel reenvía HTTP en claro, también verifica si SECURE_PROXY_SSL_HEADER es apropiado. Actívalo solo cuando el proxy controle de forma fiable la cabecera X-Forwarded-Proto.

Angular: allowedHosts en angular.json

El servidor de desarrollo moderno de Angular corre sobre Vite, así que obtienes el error de Vite, pero no hay un vite.config.js para editar. El CLI de Angular añadió una opción de dev-server allowedHosts (solicitud #29466, enero de 2025) tras pasar a Vite 6.0.9 o posterior. La documentación de CLI la describe como los hosts a los que responderá el servidor de desarrollo, y dicen que configura la opción de Vite con el mismo nombre.

"serve": {
  "builder": "@angular/build:dev-server",
  "options": {
    "allowedHosts": ["my-app.tunnel.example.com"]
  }
}

El builder basado en Webpack (`@angular-devkit/build-angular:dev-server`) toma la misma opción en el mismo lugar. Las pruebas de la CLI confirman tres comportamientos: un host listado pasa, y `true` permite cualquier host, y una matriz vacía rechaza hosts desconocidos. La CLI también expone la configuración como `--allowed-hosts`.

Angular tiene una segunda comprobación de host, no relacionada, y es fácil confundirla con la primera. La validación del servidor para renderizado del lado del servidor (SSR) no usa la redacción de Vite, y sus mensajes no emplean la misma terminología:

• Host http://localhost:4200/ is not allowed. You can configure allowedHosts option. Los desarrolladores reportaron esto en ng serve para proyectos SSR tras parche (issue #33184).
• URL with hostname "..." is not allowed. Please provide a list of allowed hosts in the "allowedHosts" option in the "CommonEngine" constructor. Desarrolladores reportaron esto tras @angular/ssr 21.1.5. Lo vieron detrás de un balanceador, donde el validador vio una dirección IP interna en lugar del nombre público (issue #32616).

Para SSR, allowedHosts puede configurarse en el constructor de CommonEngine, en opciones de compilación en angular.json, o a través de la variable de entorno NG_ALLOWED_HOSTS. Los reporteros usaron la variable para resolver el caso de localhost. Un reportero señaló que la opción acepta nombres de host exactos o un prefijo comodín como *.domain, no patrones arbitrarios. Si tu mensaje de error difiere de la frase de Vite, estás en esta segunda capa, y editar serve.options no lo arreglará.

La lista blanca de SSR ya ha sido parcheada. CVE-2026-50168 (GHSA-xrxm-cp7j-8xf6) es una vulnerabilidad de bypass en @angular/platform-server, corregida en 22.0.0-rc.2, 21.2.15, 20.3.22 y 19.2.23. Si dependes de la validación de host de SSR, mantente en una versión parcheada.

Next.js: allowedDevOrigins

Next.js difiere de una forma importante: no es una lista blanca de cabecera Host. Bloquea las solicitudes entre orígenes cruzados a recursos y endpoints de desarrollo. Coincide solo con el nombre de host del encabezado Origin de la solicitud, y recurre al nombre de host de Referer para las solicitudes no-CORS como scripts. Esquema, puerto y ruta se ignoran, así que escribe entradas sin https:// y sin puerto.

// next.config.js
module.exports = {
  allowedDevOrigins: ['my-app.tunnel.example.com'],
}

El servidor de desarrollo ya permite localhost, sus subdominios y el nombre de host con el que fue iniciado. Cualquier otro nombre de host necesita una entrada. La documentación oficial usa un túnel como ejemplo de un nombre de host que lo requiere.

Los comodines son más estrictos de lo que podrías esperar:

Entrada	Coincide	No coincide
my.dev	my.dev	team.my.dev
*.my.dev	team.my.dev	my.dev, team.eu.my.dev
**.my.dev	team.my.dev, team.eu.my.dev	my.dev

* representa exactamente una etiqueta y ** una o más. ** funciona solo al inicio de un patrón, y sustituciones parciales como team-*.my.dev no están soportadas. Como ninguna comodín coincide con el dominio base, lista la cima por separado si la necesitas.

La opción tiene una historia corta que explica por qué publicaciones anteriores no están de acuerdo. Llegó con la corrección de seguridad para CVE-2025-48068 en Next.js 15.2.2 y 14.2.30. El aviso describe la corrección como una opción que requiere configuración de allowedDevOrigins, y las versiones tempranas solo avisaban. Un cambio implementado en marzo de 2026 (pull request #91507) eliminó el valor de aviso por defecto y convirtió la verificación en predeterminada, y la documentación actual lo describe así. Si usas una versión anterior, la documentación de tu versión se aplica.

Si tu página se renderiza a través de un túnel pero el comportamiento interactivo falla, y la terminal muestra una advertencia Blocked cross-origin request to Next.js dev resource, esto es tu configuración. Mantén Next.js parcheado también. CVE-2026-27977 permite que Origin: null eluda la protección de origen del WebSocket en next dev desde 16.0.1 hasta la corrección en 16.1.7, incluso cuando allowedDevOrigins estaba configurado.

Por qué un subdominio estable significa que lo configuras una vez

Las listas de permitidos son exactas por diseño, así que el costo real depende de con qué frecuencia cambia tu hostname público.

Con un túnel desechable que entrega un hostname aleatorio en cada inicio, editas la lista de permitidos cada sesión. Cada edición también es un cambio de configuración que puede terminar en un commit, y cada compañero tiene un nombre diferente. Esa fatiga es la que hace que allowedHosts: true termine en repositorios.

Con un subdominio reservado y estable, el hostname se conoce antes de iniciar el túnel. Añades my-app.tunnel.example.com a la lista blanca una vez, lo confirmas, y cada compañero, cada ejecución de CI y cada proveedor de webhooks apunta al mismo nombre. El error con el que empezaste este artículo deja de ocurrir. La misma estabilidad ayuda a todo lo demás ligado al hostname: URIs de redirección OAuth, endpoints de webhooks, orígenes de CSRF confiables y marcadores guardados.

Si un hostname es personal y no compartido, déjalo fuera del repositorio y léelo desde una variable de entorno:

// vite.config.js
server: {
  allowedHosts: process.env.TUNNEL_HOST ? [process.env.TUNNEL_HOST] : [],
}

# config/environments/development.rb
config.hosts << ENV["TUNNEL_HOST"] if ENV["TUNNEL_HOST"]

El mismo patrón funciona en settings.py con os.environ y en next.config.js con process.env.

La trampa de allowedHosts: true

Deshabilitar la verificación es una línea en cada framework anterior: Vite’s true, Rails’ config.hosts.clear, Django’s '*', o true en Angular’s dev-server option. Resuelve el error al instante, y es por eso que se extiende.

La documentación de Vite es directa: establecer server.allowedHosts en true permite que cualquier sitio envíe solicitudes a tu dev server mediante ataques de DNS rebinding, permitiendo que descarguen tu código fuente y contenido. Recomienda siempre usar una lista explícita. Has desactivado el único control que existía para detener eso.

Dos errores relacionados son fáciles de cometer:

1. Permitir un sufijo compartido. Añadir el dominio compartido de un proveedor de túneles, como .ngrok-free.app, a la lista extiende la confianza a un dominio que no controlas. La guía de Vite recomienda añadir solo hosts cuyo resolution controlas, o cuyo propietario puedas confiar. Prefiere tu propio hostname completo, o un dominio que tú poseas.
2. Permitir todo “solo para la demo.” Los dev servers duran más que las demos. Mantén el hostname explícito.

Una lista de verificación para copiar y pegar

1. Lee el error. ¿Nombra el host y la configuración? Entonces corrige la configuración, no el túnel.
2. Copia exactamente el hostname desde la URL pública, sin esquema ni puerto.
3. Agrégalo en el lugar correcto: server.allowedHosts, config.hosts, ALLOWED_HOSTS, allowedHosts en angular.json, o allowedDevOrigins.
4. Reinicia el dev server. Las configuraciones de archivo de configuración por lo general se leen al iniciar.
5. Si la página se carga pero el recargado en caliente o los envíos de formularios fallan, revisa las configuraciones de WebSocket HMR (Vite), CSRF_TRUSTED_ORIGINS (Django), o las advertencias de recursos de desarrollo (Next.js).
6. Reserva un subdominio estable para que esto sea la última vez que lo edites.
7. Verifica desde fuera de tu red, por ejemplo, con un teléfono con datos móviles, no solo desde tu máquina.
8. Nunca cometas true, '*' o un sufijo de proveedor compartido.

Preguntas frecuentes

¿Por qué mi aplicación funciona en localhost pero no a través de un túnel?

En localhost la cabecera Host es localhost, y eso es permitido por defecto por cada framework anterior. A través de un túnel es el nombre de host público, que no está en ninguna lista por defecto.

¿Es aceptable alguna vez allowedHosts: true?

Solo en una máquina y red que controles por completo, por un corto tiempo, sin nada sensible en el proyecto. Aun así, un hostname explícito cuesta una línea y evita el riesgo.

¿Necesito permitir también el puerto?

No. Django coincide con los hostnames sin el puerto, Rails tolera un puerto opcional, y las entradas de Next.js deben escribirse sin uno.

¿El error menciona vite.config.js pero mi framework no tiene ese archivo? ¿Qué hago?

Busca una clave de paso: vite.server.allowedHosts en Nuxt, la configuración de Vite de Strapi (o actualiza Strapi), y allowedHosts en angular.json para Angular.

¿Esto afecta a producción?

Estas son configuraciones del dev-server para Vite, Angular y Next.js. Rails y Django son diferentes. ALLOWED_HOSTS de Django se aplica en producción, y config.hosts de Rails se aplica en cualquier entorno donde la configures.

Referencias

• Vite, Server Options y Preview Options
• Vite advisory GHSA-vg6x-rcgg-rjx6
• Rails API, ActionDispatch::HostAuthorization y pull request #33145
• Django, Settings: ALLOWED_HOSTS and CSRF_TRUSTED_ORIGINS, 1.4.4 release notes y 2016 security releases
• Angular CLI, ng serve options, pull request #29466, issue #33184 y issue #32616
• Angular advisory GHSA-xrxm-cp7j-8xf6
• Next.js, allowedDevOrigins, advisory GHSA-3h52-269p-cp9r, pull request #91507 y CVE-2026-27977
• Strapi, Fixing “Blocked request. This host is not allowed” in Strapi 5
• Nuxt example, Fixing ‘Blocked request’ When Exposing a Nuxt 3 Dev Server Through ngrok