Adaptación de su sitio web para nuevas restricciones de acceso a la red local en Microsoft Edge

Última actualización: 1 de octubre de 2025

Las restricciones de acceso a la red local comenzarán a enviarse de forma predeterminada en Microsoft Edge 143. Para obtener más información sobre qué es El acceso a la red local y las motivaciones para requerir permiso de usuario para realizar solicitudes de red local, consulte la especificación Acceso a la red local.

Si tiene un sitio web que necesita conectarse a un servidor que ejecuta localhost o a algún lugar de la red local del usuario (posiblemente a través de una biblioteca de terceros), este documento intenta responder a preguntas comunes y proporcionar instrucciones sobre cómo adaptar su sitio web para que funcione con estas nuevas restricciones.

En muchos casos, las solicitudes de red local deben seguir funcionando como lo hacían antes, pero los usuarios ven una solicitud de permiso la primera vez que se producen en un sitio. En algunos casos, debe ajustar el sitio para que estas solicitudes sigan funcionando (y no se bloqueen como contenido mixto). Por ejemplo, si realiza solicitudes fetch() a un nombre de dominio público, que se resuelve en una dirección de red local, debe etiquetar explícitamente las llamadas fetch() como ir a una dirección local. O bien, si hoy tiene que hospedar su sitio web en HTTP (en lugar de HTTPS) debido al bloqueo de contenido mixto, quiere registrarse en nuestra versión de prueba de Origin para excluir temporalmente su sitio de los requisitos HTTPS para solicitar el permiso LNA.

¿Cuál es el ámbito actual de las restricciones de LNA en Microsoft Edge?

El símbolo del sistema de permisos se desencadena cuando se realiza una conexión a un destino en la red local o localhost. A partir de Microsoft Edge 143, las restricciones de LNA se aplican a:

• Solicitudes de subrecursos
• solicitudes fetch()
• Navegación por subtramas

Las restricciones de LNA no se aplicarán inicialmente a los siguientes tipos de conexión, aunque tenemos previsto incluirlas pronto:

• WebSockets
• WebTransport
• WebRTC

Actualmente no tenemos planes para aplicar restricciones de LNA a la navegación del marco principal. (Aunque un error en nuestro borrador de implementación en Edge 139 y versiones anteriores afectó accidentalmente a la navegación del marco principal).

Actualmente no tenemos planes para aplicar restricciones de LNA a las extensiones. Actualmente, las extensiones que tienen los permisos de host necesarios pueden realizar solicitudes de red local.

Las restricciones de LNA no se aplican a Android WebView. En su lugar, las aplicaciones Android que insertan WebView que realizan solicitudes de red local están sujetas al nuevo permiso de red local de Android.

¿Cómo puedo proporcionar a mis usuarios contexto adicional para el símbolo del permiso de LNA?

Al solicitar un permiso, puede ser beneficioso proporcionar al usuario un contexto adicional en la aplicación web para saber por qué necesita el permiso y para qué lo usa. La API De permisos le permite consultar si un usuario concedió (o denegó) un permiso determinado y, por tanto, personalizar la interfaz de usuario en consecuencia.

Debido a cómo funciona la API de permisos, la consulta del estado del permiso de acceso a la red local devuelve "prompt" independientemente de si la marca de característica LNA está habilitada, si el usuario no tiene concedido o denegado el permiso. La marca de característica está habilitada de forma predeterminada en Microsoft Edge 143, por lo que puede enviar un comportamiento diferente en función de la versión principal en la cadena del agente de usuario.

Para proporcionar más contexto antes de desencadenar el símbolo del permiso de LNA, nuestra guía actual consiste en usar un patrón como el siguiente:

• Si el cliente es Edge < 143, las solicitudes de red local deben funcionar de forma silenciosa.
• Si el cliente es Edge >= 143, consulte la API de permisos (consulte la llamada de ejemplo siguiente)
  • Si se concede el permiso, continúe con el intento de solicitud.
  • Si se deniega el permiso, opcionalmente, muestre la interfaz de usuario para ayudar al usuario a corregir si es necesario.
  • Si el estado del permiso es "prompt", contextualice en la aplicación que se produce un aviso.

Llamada api de permisos de ejemplo:

navigator.permissions.query({ name: "local-network-access" })
.then((result) => {
  console.log(`LNA permission state: ${result.state}`)
});

Nota: La API de permisos siempre devolverá "denegado" cuando se llame desde una página HTTP.

¿Cómo se puede desencadenar mediante programación el símbolo del sistema de permisos?

El símbolo del permiso de LNA no se desencadenará si no se establece una conexión con el punto de conexión remoto. Si es más fácil que el flujo de trabajo desencadene el símbolo del sistema antes de intentar establecer una conexión con el dispositivo local, una manera de hacerlo es realizar una solicitud fetch() a un nombre de host que se pueda comprobar que está en los espacios de direcciones locales o de bucle invertido mediante el examen visual del nombre de host (es decir, localhost o un bucle invertido o un literal de dirección IP local).

En la práctica, esto significa que si está desencadenando un aviso de permiso para las conexiones a localhost, en JavaScript desencadenará una llamada fetch() como se indica a continuación:

fetch("http://localhost")

O bien, si va a desencadenar una solicitud de permiso para una conexión a un dispositivo local, haga lo siguiente:

fetch("https://10.0.0.1")

Algunas notas:

• Funciona en Microsoft Edge 144 o superior
• Si el usuario aceptó (o denegó) el permiso, el usuario no verá otro símbolo del sistema.
• Esto no desencadenará un símbolo del sistema de permisos si el contexto en el que se ejecutó fetch() no necesita el permiso para ponerse en contacto con localhost (o la red local).

¿Cómo puedo realizar solicitudes de red local desde dentro de un iframe?

La realización de una solicitud de red local desde dentro de un iframe requiere que el documento de inserción especifique la marca de directiva local-network-access permissions en el iframe. Por ejemplo, si domainA.example incluye un iframe para domainB.example, debe delegar explícitamente el permiso en el iframe de la siguiente manera:

<iframe src="domainB.example" allow="local-network-access"></iframe>

Cuando se realiza una solicitud de red local desde el documento incrustado, se trata como si el documento de inserción hubiera solicitado el permiso LNA y cualquier decisión de permiso por parte del usuario se asociará al origen del documento de inserción.

Si el documento dentro del iframe navega a otros documentos que también realizan solicitudes de red local, debe especificar todos los orígenes de todos los documentos que posiblemente puedan realizar solicitudes de red local en la marca de directiva de permisos. Para ampliar el ejemplo anterior, si domainB.example navega el iframe a domainC.example y domainB.example y domainC.example realizan una solicitud de acceso de red local, deberá delegar explícitamente el permiso a ambos orígenes de la siguiente manera:

<iframe src="domainB.example" allow="local-network-access domainB.example domainC.example"></iframe>

También puede especificar allow="local-network-access *" para permitir que todos los orígenes que se pueden cargar en el iframe realicen solicitudes de red local (incluso si no sabe necesariamente qué son con antelación). Por ejemplo, esto puede ser útil en casos en los que un iframe puede realizar redirecciones arbitrarias a otro origen (por ejemplo, para sso) antes de redirigir de nuevo a localhost.

Otras cosas a tener en cuenta:

• Tanto la página de inserción como el iframe deben ser contextos seguros para solicitar el permiso LNA.
• Solicitar el permiso LNA desde dentro de un iframe anidado (por ejemplo, domainA.example inserta un iframe para domainB.example, que inserta un iframe para domainC.example, que realiza la solicitud de red local) requiere que todos los iframes especifiquen la marca de directiva de permisos de acceso a la red local.
• La directiva de permisos debe establecerse en iframes que realizan solicitudes de red local, incluso si se omite el símbolo del sistema de permisos a través de la directiva de empresa.

¿Cómo puedo realizar solicitudes de red local desde un trabajo de servicio o un trabajo compartido?

Las solicitudes de red local de Service Workers y Shared Workers se admiten siempre y cuando el origen del trabajo ya tenga concedido el permiso LNA en un contexto de ventana principal. Quiere intentar solicitar el permiso realizando una solicitud de red local inicial desde la ventana principal de la aplicación y, a continuación, los trabajadores pueden usar ese permiso (incluido desde segundo plano).

¿Cómo puedo realizar solicitudes de red local desde un trabajo dedicado?

Los trabajos dedicados pertenecen estrictamente a una ventana principal existente, por lo que las solicitudes de red local de un trabajo dedicado desencadenan el símbolo del permiso de LNA en la ventana propietaria.

¿Cómo puedo evitar que mis solicitudes de red local se bloqueen como contenido mixto?

Con LNA, algunas solicitudes de red local ahora están exentas del bloqueo de contenido mixto, lo que permite que los sitios HTTPS realicen solicitudes de red local a estos puntos de conexión HTTP:

• Dominios .local (por ejemplo, http://printer.local)
• Literales de IP privada (por ejemplo, http://192.168.0.1/)

Además, al usar la API fetch(), puede especificar la opción targetAddressSpace para marcar que una solicitud está destinada a la red local o a la dirección de bucle invertido. Por ejemplo:

• fetch(''http://domainA.example, {targetAddressSpace: 'local'}) funcionan si domainA.example se resuelve en una dirección IP local como 192.168.10.1
• fetch(''http://domainB.example, {targetAddressSpace: 'loopback'}) funcionará si domainB.example se resuelve en la dirección de bucle invertido 127.0.0.1

Todos ellos estarán exentos del bloqueo de contenido mixto.

¿Cómo puedo realizar solicitudes de red local desde una página HTTP?

Para solicitar el permiso LNA, un sitio servido a través de HTTPS (es decir, LNA requiere un contexto seguro). Sin embargo, debido a las complejidades de la realización de solicitudes de red local, donde a veces los destinos no admiten actualmente HTTPS de confianza pública, esto significa que estas solicitudes de red local HTTP podrían bloquearse como contenido mixto.

Aunque LNA intenta crear excepciones para los casos comunes (consulte la sección anterior sobre "¿Cómo puedo evitar que mis solicitudes de red local se bloqueen como contenido mixto?"), puede que no sea sencillo adaptar el sitio para evitar problemas con el contenido mixto.

Si necesita más tiempo para cambiar el sitio para usar HTTPS o encuentra problemas de bloqueo con las excepciones de contenido mixto de LNA, ya que están implementadas actualmente en Microsoft Edge, puede registrarse para obtener una prueba de origen para permitir temporalmente que el sitio HTTP solicite el permiso LNA.

Nota: El token de prueba de origen se debe servir a través de encabezados HTTP. Esta prueba de origen no admite tokens entregados a través de metaetiquetas ni mediante programación a través de JS.

¿Cómo puedo mantener mejor la compatibilidad entre exploradores?

Dado que diferentes exploradores están implementando estas restricciones en momentos diferentes, es posible que tenga que implementar alguna lógica de detección de agentes de usuario para maximizar la compatibilidad.

La principal diferencia de compatibilidad entre un explorador que admite la nueva especificación de acceso a la red local y otro que aún no está relacionado con el contenido mixto. En los exploradores que admiten LNA, el acceso a la red local y el permiso LNA, solo están disponibles desde orígenes seguros. Se produce un error en las solicitudes de orígenes no seguros.

En los exploradores que aún no admiten la especificación de LNA, es probable que la mayoría del acceso a la red local se haya realizado desde un origen no seguro para evitar que las solicitudes inseguras a los recursos locales se identifiquen como contenido mixto.

Si actualmente sirve la página a través de HTTP debido a este bloqueo de contenido mixto, es posible que desee servir una redirección a HTTPS para Microsoft Edge 143 y versiones posteriores, pero seguir sirviendo a otros exploradores a través de HTTP (hasta que también envían restricciones de LNA y las excepciones de contenido mixto).

Si solo realiza solicitudes de red local a localhost, ya debería poder atender el sitio a través de HTTPS, ya que localhost se considera un origen seguro según la especificación de contenido mixto y no se bloqueará como contenido mixto.

Durante el lanzamiento de Microsoft Edge, puede inscribirse en una prueba de origen para habilitar temporalmente el símbolo del permiso de LNA en los orígenes no seguros (HTTP). Obtenga más información sobre la inscripción en las pruebas de origen. Esta versión de prueba de origen solo estará disponible a través de Microsoft Edge 146 (que está programado para ir al canal estable en marzo de 2026). Los usuarios de la versión de prueba de origen deben intentar migrar a HTTPS antes de ese momento.

¿Cómo puedo probar el permiso LNA en EdgeDriver/Selenium/etc.?

El permiso de acceso a la red local se puede administrar a través de WebDriver/EdgeDriver. Consulte la documentación de Selenium sobre la funcionalidad específica de Edge y la documentación de Microsoft Edge sobre el uso de WebDriver para automatizar Microsoft Edge. Para administrar permisos específicamente, consulte la especificación de comandos y protocolos setPermissions de WebDriver.

¿Cómo puedo desencadenar el símbolo del sistema de LNA en mis pruebas locales?

Dado que las restricciones de LNA aún no se aplican a las solicitudes locales→locales o locales→loopback, las configuraciones de desarrollo locales típicas (como ejecutar un servidor en localhost) no desencadenarán el símbolo del sistema de permisos en Microsoft Edge.

Sin embargo, puede ser útil que el símbolo del permiso se desencadene en las pruebas locales; por ejemplo, si está trabajando en personalizar la interfaz de usuario para agregar más contexto antes del aviso o para ayudar a los usuarios a recuperarse si han denegado el permiso (consulte ¿Cómo puedo proporcionar a mis usuarios más contexto para el símbolo del permiso de LNA? Arriba).

Microsoft Edge proporciona dos maneras de que una página se trate como si se tratara desde una dirección pública:

• El encabezado Content-Security-Policy: treat-as-public-address en el documento HTML hace que ese documento se trate como si se tratara desde una dirección pública.
• La marca de línea de comandos --ip-address-space-overrides se puede usar para forzar que las direcciones IP específicas se traten como un espacio de direcciones específico (público, local o bucle invertido).

Ejemplo de marca de invalidación de espacio de direcciones: El servidor de desarrollo local principal se ejecuta en 192.168.10.11, que luego realiza solicitudes a un servidor independiente que se ejecuta en 192.168.10.12. Puede pasar --ip-address-space-overrides=192.168.10.11:0=public al ejecutar Microsoft Edge para forzar que 192.168.10.11 se trate como una dirección pública (un puerto de 0 significa "aplicar a todos" puertos"). Después, cuando se realicen solicitudes al servidor que se ejecuta en 192.168.10.12, se tratarán como solicitudes de red local y desencadenarán el símbolo del permiso.

¿Cómo puedo evitar desencadenar la solicitud de LNA en mis pruebas automatizadas?

Las restricciones de LNA aún no se aplican a las solicitudes locales→ locales o locales→loopback, pero algunas configuraciones de pruebas basadas en explorador pueden implicar servidores locales que podrían provocar que se desencadene el símbolo del sistema de LNA. Si esto es inesperado y no coincide con el recorrido del usuario real que está probando (por ejemplo, el sitio de producción solo realizaría solicitudes a servicios públicos), puede configurar Microsoft Edge para que trate las direcciones IP específicas como públicas mediante la marca de línea de comandos --ip-address-space-overrides=ip-address>:<port>=<address-space y, por tanto, las solicitudes a ellas desde sitios públicos no desencadenarán el símbolo del sistema LNA.

Puede especificar un puerto de 0 para aplicar la invalidación a todos los puertos de esa dirección IP. Puede especificar varias reglas de invalidación, separadas por comas (por ejemplo, ip-address-space-overrides=192.168.0.1:8080=public,10.0.1.20:0=loopback). Puede encontrar la gramática completa de la marca aquí.

Ejemplo: el servidor de almacenamiento provisional se ejecuta en 23.220.75.232 (una dirección IP pública), pero realiza solicitudes a un servicio que se ejecuta internamente en 10.0.1.108 (una dirección IP privada). En producción, este servicio se ejecuta en una dirección IP pública, por lo que no se espera que los usuarios reales vean el símbolo del sistema de LNA. En el aprovechamiento de pruebas automatizadas para este servicio, se pasa la marca de línea de comandos --ip-address-space-overrides=10.0.1.108:0=public para que todas las conexiones a esa dirección IP se consideren públicas y no se desencadene ningún símbolo del sistema LNA en las pruebas.

Cómo determinar por qué LNA bloquea un sitio

Cada vez que una aplicación web intenta acceder a los recursos considerados como en la red local, se desencadena un mensaje para permitir que el usuario permita o bloquee dicha solicitud:

Permitir el acceso normalmente desbloquea la funcionalidad que espera la aplicación web. Actualmente, cuando el intento de acceso a la red local va a (o procede de) un iframe entre orígenes que se considera que está en la red local, la exención de la aplicación web (ya sea manualmente o a través de la directiva de grupo) no funcionará.

Este escenario de iframe suele ir acompañado de un error de consola de DevTools:

Access to fetch at 'http://127.0.0.1:8080/data' from origin 'https://example.com'  

has been blocked by CORS policy: Permission was denied for this request to access the `unknown` address space. 

Identificación de los hosts de nivel superior y entre orígenes definidos para el iframe. Aunque se recomienda adaptar una aplicación web afectada para agregar el permiso "acceso a la red local" en el iframe, es posible que esto no sea posible sin control directo sobre el código de la aplicación web.

Algunas bibliotecas usadas en aplicaciones web que se pueden usar dentro de iframes entre orígenes ya han publicado correcciones para admitir los permisos de LNA necesarios, como MSAL-browser, incluidos en la versión 4.26.1 o posterior.

Cómo mitigar el impacto de los iframes entre orígenes

Cuando se considera que los hosts de nivel superior o iframe están en la red local, en función de condiciones de red específicas, la única manera de mitigar el impacto sin realizar cambios en el código es usar la configuración de directiva LocalNetworkAccessRestrictionsTemporaryOptOut .

Hay planes para proporcionar dos opciones de configuración de directiva adicionales para superar este escenario, una para permitir que los iframes entre orígenes hereden el permiso LNA de host de nivel superior y otro para excluir un espacio de direcciones determinado de que se considere una red local (como el intervalo de direcciones NAT de nivel de operador ). La documentación se actualiza cuando Microsoft Edge proporciona compatibilidad oficial con estas directivas.

¿Cómo puedo proporcionar comentarios sobre LNA en general?

Registre un problema con sus comentarios en el repositorio de especificaciones de acceso a la red local en GitHub.

¿Cómo puedo notificar errores en la implementación de LNA de Microsoft Edge?

Para problemas específicos de la implementación de Microsoft Edge de Acceso a red local, use los canales de comentarios de Microsoft Edge o póngase en contacto con Soporte técnico de Microsoft para clientes empresariales.

[Enterprise] Cómo permitir listas de permitidos o direcciones URL de lista de bloqueo para solicitudes de red local

Hay dos directivas empresariales para LNA: LocalNetworkAccessAllowedForUrls y LocalNetworkAccessBlockedForUrls. Se pueden usar para permitir solicitudes de red local desde una dirección URL sin mostrar el símbolo del permiso o para impedir que una dirección URL pueda realizar solicitudes de red local.

Estas directivas también admiten caracteres comodín con la sintaxis de patrón de dirección URL .

La directiva LocalNetworkAccessAllowedForUrls se aplica al origen de nivel superior del sitio que realiza la solicitud. Si el acceso de red local real se realiza dentro de un iframe incrustado en esa página (o en un iframe anidado), todos los iframes deben establecer la marca de directiva de permisos.

[Enterprise] He establecido LocalNetworkAccessAllowedForUrls, pero todavía tengo problemas

Si ha establecido la directiva LocalNetworkAccessAllowedForUrls correctamente, pero las aplicaciones siguen sin funcionar, es probable que tenga que corregir los iframes. Vea la sección anterior titulada "¿Cómo puedo realizar solicitudes de red local desde dentro de un iframe?"

También hay una directiva empresarial temporal, LocalNetworkAccessRestrictionsTemporaryOptOut, que permite a las empresas no participar en todas las restricciones de LNA. Esta directiva es temporal y se quitará después de Edge 152.

Nota: Estas directivas se pueden configurar mediante directiva de grupo (a través de plantillas de ADMX), Microsoft Intune (mediante el catálogo de configuración) u otras soluciones de Mobile Administración de dispositivos (MDM). Para obtener más información sobre cómo configurar directivas de Microsoft Edge, consulte Configuración de las directivas de Microsoft Edge.