Адаптация веб-сайта для новых ограничений доступа к локальной сети в Microsoft Edge

Последнее обновление: 9 марта 2026 г.

Ограничения доступа к локальной сети по умолчанию начнутся в Microsoft Edge 143. Дополнительные сведения о том, что такое доступ к локальной сети и мотивы, необходимые пользователю для выполнения запросов к локальной сети, см. в спецификации доступа к локальной сети.

Если у вас есть веб-сайт, который должен подключиться к серверу, на котором выполняется localhost или где-то в локальной сети пользователя (возможно, через стороннюю библиотеку), в этом документе содержится попытка ответить на распространенные вопросы и предоставить рекомендации по адаптации веб-сайта для работы с этими новыми ограничениями.

Во многих случаях запросы локальной сети должны продолжать работать, как и раньше, но пользователи видят запрос разрешения при первом появлении на сайте. В некоторых случаях необходимо настроить сайт для этих запросов, чтобы продолжить работу (и не блокироваться как смешанное содержимое). Например, если вы выполняете запросы fetch() к имени общедоступного домена, которое разрешается в адрес локальной сети, необходимо явно пометить вызовы fetch() как поступающие на локальный адрес. Или, если сегодня вам нужно разместить веб-сайт по протоколу HTTP (вместо HTTPS) из-за блокировки смешанного содержимого, вы хотите зарегистрироваться для получения пробной версии origin , чтобы временно исключить ваш сайт из требований HTTPS для запроса разрешения LNA.

Каковы текущие область ограничений LNA в Microsoft Edge?

Запрос разрешений активируется при подключении к месту назначения в локальной сети или localhost. Начиная с Microsoft Edge 143, ограничения LNA применяются к:

• Запросы подресурсов
• запросы fetch()
• Навигация по вложенным кадрам

Ограничения LNA изначально не будут применяться к следующим типам подключений, хотя мы планируем включить их в ближайшее время:

• WebSockets
• WebTransport
• WebRTC

В настоящее время мы не планируем применять ограничения LNA к основной навигации по кадрам. (Хотя ошибка в реализации проекта в Edge 139 и более ранних версиях случайно повлияла на навигацию по главному кадру.)

В настоящее время мы не планируем применять ограничения LNA к расширениям. В настоящее время расширениям с необходимыми разрешениями узла разрешено выполнять запросы локальной сети.

Ограничения LNA не применяются к Android WebView. Вместо этого приложениям Android, которые внедряют WebView, которые выполняют запросы к локальной сети, применяются новые разрешения на локальную сеть Android.

Как предоставить пользователям дополнительный контекст для запроса на разрешение LNA?

При запросе разрешения может быть полезно предоставить пользователю дополнительный контекст в веб-приложении о том, почему вам нужно разрешение и для чего вы его используете. API разрешений позволяет запрашивать, предоставил ли пользователь (или отклонул) данное разрешение, и таким образом настроить пользовательский интерфейс соответствующим образом.

Из-за того, как работает API разрешений, запрос на состояние разрешения доступа к локальной сети возвращает "prompt" независимо от того, включен ли флаг функции LNA, если пользователю не предоставлено или отказано в разрешении. Флаг компонента включен по умолчанию в Microsoft Edge 143, поэтому вы можете отправлять различные действия в зависимости от основной версии в строке агента пользователя.

Чтобы предоставить дополнительный контекст перед активацией запроса на разрешение LNA, в настоящее время мы используем шаблон, подобный следующему:

• Если клиент — Edge < 143, запросы локальной сети должны работать автоматически.
• Если клиент — Edge >= 143, запросите API разрешений (см. пример вызова ниже).
  • Если разрешение предоставлено, продолжите попытку запроса.
  • Если разрешение запрещено, при необходимости отобразите пользовательский интерфейс, чтобы помочь пользователю исправить ситуацию при необходимости.
  • Если состояние разрешения — "запрос", контекстуализируйте в приложении запрос.

Пример вызова API разрешений:

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

Примечание. API разрешений всегда будет возвращать значение "отказано" при вызове с HTTP-страницы.

Как программно активировать запрос на разрешение?

Запрос на разрешение LNA не активируется, если подключение к удаленной конечной точке не установлено. Если вашему рабочему процессу проще активировать запрос разрешений, прежде чем пытаться установить подключение к локальному устройству, то один из способов обойти это — сделать запрос на выборку() к имени узла, который можно проверить, находится в локальных адресных пространствах или в диапазоне адресов на замыкание на себя путем визуального изучения имени узла (т. е. localhost или замыкания на себя или локального IP-адреса).

На практике это означает, что если вы активируете запрос разрешений для подключений к localhost, то в JavaScript активируйте вызов fetch() следующим образом:

fetch("http://localhost")

Если вы активируете запрос на разрешение для подключения к локальному устройству, выполните следующие действия:

fetch("https://10.0.0.1")

Несколько примечаний:

• Работает в Microsoft Edge 144 или более поздней версии
• Если пользователь принял (или отклонул) разрешение, он не увидит другого запроса на разрешение.
• Это не активирует запрос разрешений, если контексту, в котором был выполнен fetch(), не требуется разрешение на связь с localhost (или локальной сетью).

Как выполнять запросы локальной сети из iframe?

Для выполнения запроса локальной сети из iframe требуется, чтобы в документе внедрения был указан флаг политики разрешений для доступа к локальной сети в iframe. Например, если domainA.example включает iframe для domainB.example, необходимо явно делегировать разрешение для iframe следующим образом:

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

Когда запрос локальной сети выполняется из внедренного документа, он обрабатывается так, как если бы внедренный документ запросил разрешение LNA, и любое решение о разрешении, принятое пользователем, будет привязано к источнику внедренного документа.

Если документ внутри iframe переходит к другим документам, которые также выполняют запросы локальной сети, необходимо указать все источники всех документов, которые могут выполнять запросы локальной сети по флагу политики разрешений. Чтобы расширить приведенный выше пример, если domainB.example переходит в iframe к domainC.example и domainB.example и domainC.example выполняет запрос на доступ к локальной сети, необходимо явно делегировать разрешение обоим источникам, как показано ниже.

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

Вы также можете указать allow="local-network-access *", чтобы разрешить всем источникам, которые могут загружаться в iframe, выполнять запросы локальной сети (даже если вы не обязательно знаете, что они будут заранее). Например, это может быть полезно в тех случаях, когда iframe может выполнять произвольные перенаправления к другому источнику (например, для единого входа) перед перенаправлением обратно на localhost.

Обратите внимание на другие моменты:

• Страница внедрения и iframe должны быть безопасными контекстами , чтобы запросить разрешение LNA.
• При запросе разрешения LNA из вложенного iframe (например, domainA.example внедряет iframe для domainB.example, который внедряет iframe для domainC.example, который выполняет запрос локальной сети), требует, чтобы все iframe указали флаг политики разрешений на доступ к локальной сети.
• Политика разрешений должна быть задана для iframe, которые выполняют запросы локальной сети, даже если вы обходите запрос разрешений с помощью корпоративной политики.

Как выполнять запросы локальной сети от рабочей роли службы или общей рабочей роли?

Запросы локальной сети от рабочих ролей обслуживания и общих рабочих ролей поддерживаются при условии, что источнику рабочей роли уже предоставлено разрешение LNA в контексте главного окна. Вы хотите попытаться запросить разрешение, выполнив первоначальный запрос локальной сети из главного окна приложения, и затем ваши сотрудники смогут использовать это разрешение (в том числе из фона).

Как выполнять запросы локальной сети от выделенной рабочей роли?

Выделенные рабочие роли принадлежат только существующему главному окну, поэтому запросы локальной сети от выделенной рабочей роли активируют запрос на разрешение LNA в окне владения.

Как избежать блокировки запросов локальной сети как смешанного содержимого?

При использовании LNA некоторые запросы локальной сети теперь исключаются из блокировки смешанного содержимого, что позволяет сайтам HTTPS отправлять запросы локальной сети к этим конечным точкам HTTP:

• Домены .local (например, http://printer.local)
• Частные IP-литералы (например, http://192.168.0.1/)

Кроме того, при использовании API fetch() можно указать параметр targetAddressSpace, чтобы отметить, что запрос предназначен для локальной сети или адреса замыкания на себя. Пример

• fetch(''http://domainA.example, {targetAddressSpace: 'local'}) работает, если domainA.example разрешается в локальный IP-адрес, например 192.168.10.1
• fetch(''http://domainB.example, {targetAddressSpace: 'loopback'}) будет работать, если domainB.example разрешается в адрес замыкания на себя 127.0.0.1

Все они будут исключены из-за блокировки смешанного содержимого.

Как выполнять запросы локальной сети со страницы HTTP?

Чтобы запросить разрешение LNA, сайт обслуживается по протоколу HTTPS (т. е. для LNA требуется безопасный контекст). Однако из-за сложности выполнения запросов локальной сети, когда иногда назначения в настоящее время не поддерживают общедоступный доверенный ПРОТОКОЛ HTTPS, это означает, что эти HTTP-запросы локальной сети могут быть заблокированы как смешанное содержимое.

Хотя LNA пытается вырезать исключения для распространенных случаев (см. выше раздел "Как избежать блокировки запросов локальной сети как смешанного контента?"), возможно, не так просто адаптировать свой сайт, чтобы избежать проблем со смешанным содержимым.

Если вам требуется больше времени для переключения сайта на использование HTTPS или возникают проблемы с блокировкой исключений смешанного содержимого LNA, которые в настоящее время реализованы в Microsoft Edge, вы можете зарегистрироваться для получения пробной версии источника , чтобы временно разрешить сайту HTTP запрашивать разрешение LNA.

Примечание: Маркер пробной версии источника должен обслуживаться через заголовки HTTP. Эта пробная версия источника не поддерживает маркеры, доставляемые с помощью метатегов или программно через JS.

Как лучше всего поддерживать совместимость между браузерами?

Так как разные браузеры развертывают эти ограничения в разное время, может потребоваться реализовать некоторую логику обнаружения агента пользователя, чтобы обеспечить максимальную совместимость.

Основное различие в совместимости между браузером, поддерживающим новую спецификацию доступа к локальной сети, и браузером, который еще не относится к смешанному содержимому. В браузерах, поддерживающих LNA, доступ к локальной сети и разрешение LNA доступны только из безопасных источников. Запросы из небезопасных источников завершаются сбоем.

В браузерах, которые еще не поддерживают спецификацию LNA, скорее всего, доступ к локальной сети осуществлялся из небезопасного источника, чтобы избежать небезопасных запросов к локальным ресурсам, которые идентифицируются как смешанное содержимое.

Если в настоящее время вы обслуживаете страницу по протоколу HTTP из-за блокировки смешанного содержимого, может потребоваться отправить перенаправление на HTTPS для Microsoft Edge 143 и более поздних версий, но продолжайте обслуживать другие браузеры по протоколу HTTP (пока они также не поставляют ограничения LNA и исключения смешанного содержимого).

Если вы отправляете запросы только к localhost, вы уже сможете обслуживать свой сайт по протоколу HTTPS, так как localhost считается безопасным источником в спецификации смешанного содержимого и не будет заблокирован как смешанное содержимое.

Во время развертывания Microsoft Edge вы можете зарегистрироваться в пробной версии источника , чтобы временно включить запрос на разрешение LNA для небезопасных источников (HTTP). Дополнительные сведения о регистрации в пробных версиях источника. Эта исходная пробная версия будет доступна только через Microsoft Edge 146 (который планируется перейти на стабильный канал в марте 2026 г.). Пользователи исходной пробной версии должны стремиться к переходу на HTTPS до этого времени.

Как проверить разрешение LNA в EdgeDriver/Selenium/etc.?

Разрешением на доступ к локальной сети можно управлять с помощью WebDriver или EdgeDriver. Ознакомьтесь с документацией selenium по функциональным возможностям Edge и документацией по Microsoft Edge по использованию WebDriver для автоматизации Microsoft Edge. Сведения об управлении разрешениями см. в статье Команда и спецификация протоколаWebDriver setPermissions.

Как активировать запрос LNA в локальном тестировании?

Так как ограничения LNA еще не применяются к локальным→локальным или локальным запросам→loopback, типичные локальные настройки разработки (например, запуск сервера на локальном узле) не активируют запрос разрешений в Microsoft Edge.

Однако это может быть полезно для запуска запроса разрешений в локальном тестировании, например, если вы работаете над настройкой пользовательского интерфейса для добавления дополнительного контекста перед запросом или для помощи пользователям в восстановлении, если они отказано в разрешении (см. раздел Как предоставить пользователям дополнительный контекст для запроса разрешений LNA? Выше).

Microsoft Edge предоставляет два способа обработки страницы так, как если бы она обслуживалась из общедоступного адреса:

• Заголовок Content-Security-Policy: treat-as-public-address в HTML-документе приводит к тому, что документ обрабатывается так, как если бы он обслуживался из общедоступного адреса.
• Флаг командной строки --ip-address-space-overrides можно использовать для принудительной обработки определенных IP-адресов как определенного адресного пространства (общедоступного, локального или замыкания на себя).

Пример флага переопределения адресного пространства: Основной локальный сервер разработки работает на сервере 192.168.10.11, который затем отправляет запросы на отдельный сервер под управлением 192.168.10.12. Вы можете передать --ip-address-space-overrides=192.168.10.11:0=public при запуске Microsoft Edge, чтобы принудительно обрабатывать 192.168.10.11 как общедоступный адрес (порт 0 означает "применить ко всем" портам"). Затем при выполнении запросов к серверу, работающему в версии 192.168.10.12, они будут обрабатываться как запросы локальной сети и активировать запрос на разрешение.

Как избежать запуска запроса LNA в автоматическом тестировании?

Ограничения LNA пока не применяются к локальным→ или локальным запросам→loopback, но некоторые настройки тестирования на основе браузера могут включать локальные серверы, которые могут вызвать запуск запроса LNA. Если это непредвиденное и не соответствует реальному пути взаимодействия пользователя, которое вы тестируете (например, рабочий сайт будет отправлять запросы только к общедоступным службам), вы можете настроить Microsoft Edge для обработки определенных IP-адресов как общедоступных с помощью флага командной строки --ip-address-space-overrides=ip-address>:<port>=<address-space , и поэтому запросы к ним с общедоступных сайтов не будут запускать запрос LNA.

Вы можете указать порт 0, чтобы применить переопределение ко всем портам на этом IP-адресе. Можно указать несколько правил переопределения, разделенных запятой (например, ip-address-space-overrides=192.168.0.1:8080=public,10.0.1.20:0=loopback). Полную грамматику флага можно найти здесь.

Пример. Промежуточный сервер работает на сервере 23.220.75.232 (общедоступный IP-адрес), но выполняет запросы к службе, которая выполняется внутренне на 10.0.1.108 (частный IP-адрес). В рабочей среде эта служба работает на общедоступном IP-адресе, поэтому реальные пользователи не должны видеть запрос LNA. В средстве автоматического тестирования для этой службы вы передаете флаг командной строки --ip-address-space-overrides=10.0.1.108:0=public, чтобы все подключения к этому IP-адресу считались общедоступными и при тестировании запрос LNA не активируется.

Как определить, почему сайт заблокирован LNA

Каждый раз, когда веб-приложение пытается получить доступ к ресурсам, которые считаются в локальной сети, запускается запрос, позволяющий пользователю разрешить или заблокировать такой запрос:

Разрешение доступа обычно разблокирует функциональные возможности веб-приложения. В настоящее время, когда попытка доступа к локальной сети собирается (или происходит из) меж-исходного iframe, который считается в локальной сети, исключение веб-приложения (вручную или с помощью групповой политики) не будет работать.

Этот сценарий iframe обычно сопровождается ошибкой консоли 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. 

Определение узлов разных источников и узлов верхнего уровня, определенных для iframe. Хотя рекомендуется адаптировать затронутое веб-приложение для добавления разрешения "доступ к локальной сети" в iframe, это может быть невозможно без прямого контроля над кодом веб-приложения.

Некоторые библиотеки, используемые в веб-приложениях, которые могут использоваться в iframes разных источников, уже выпустили исправления для поддержки необходимых разрешений LNA, например MSAL-browser, включенных в версию 4.26.1 или более поздней.

Как снизить влияние на iframes разных источников

Если узлы верхнего уровня или iframe считаются в локальной сети в зависимости от конкретных условий сети, единственный способ снизить влияние без изменения кода — использовать LocalNetworkAccessRestrictionsTemporaryOptOut параметр политики.

В Microsoft Edge 146 Stable доступны следующие дополнительные политики для устранения сценариев, в которых ограничения доступа к локальной сети влияют на iframes разных источников:

• LocalNetworkAccessIpAddressSpaceOverrides — позволяет администраторам определять диапазон IP-адресов как общедоступный, локальный или замыкающийся на себя.

• LocalNetworkAccessPermissionsPolicyDefaultEnabled — позволяет iframes cross-origin наследовать разрешение на доступ к локальной сети, определенное LocalNetworkAccessAllowedForUrls политикой для узлов или доменов верхнего уровня.

Политику LocalNetworkAccessIpAddressSpaceOverrides также можно использовать для обработки диапазона адресов NAT уровня оператора (CGN) как общедоступного, если это требуется для определенных сетевых конфигураций. Например, чтобы исключить диапазон адресов CGN, настройте политику со значением:

100.64.0.0/10=public

Руководство по политике для распространенных сценариев доступа к локальной сети

Как правило, в зависимости от сценария, вызывающего ограничение доступа к локальной сети, следует использовать следующие параметры политики.

1. Сценарии IP-адресов CGN

   Если проблема вызвана тем, что IP-адрес NAT уровня оператора (CGN) классифицируется как локальный, следует использовать политику LocalNetworkAccessIpAddressSpaceOverrides для реклассификации диапазона адресов CGN как общедоступного.

2. Сценарии локальных IP-адресов

   Если проблема вызвана фактическим локальным IP-адресом, использование политики LocalNetworkAccessAllowedForUrls для исключения домена верхнего уровня может устранить проблему, если:

   • Веб-сайт не содержит iframes из разных источников.
   • Веб-сайт содержит межкрепные iframe-кадры, которые включают local-network-access разрешение iframe в коде сайта.

3. Сценарии iframe с несколькими источниками без необходимых разрешений

   Если межуровневый iframe не включает local-network-access разрешение iframe, проблему можно устранить только с помощью следующих способов:

   • Обновите код веб-сайта, чтобы добавить local-network-access разрешение на необходимые iframes с несколькими источниками.
   • Использование политики LocalNetworkAccessPermissionsPolicyDefaultEnabled вместе с политикой LocalNetworkAccessAllowedForUrls для разрешения узла или домена верхнего уровня.

Руководство по тестированию для корпоративных сред

Чтобы разместить эти параметры политики в вашей среде, определите план тестирования перед широким развертыванием. В качестве общей базовой базы можно использовать следующие шаги:

• Проверьте, какие узлы разрешаются в диапазон адресов CGN, и определите веб-сайты, на которых они используются.

• Если настроена политика LocalNetworkAccessAllowedForUrls , временно удалите из нее все записи (за исключением записей, необходимых для SharePoint или OneDrive). Затем используйте политику LocalNetworkAccessIpAddressSpaceOverrides , чтобы реклассифицировать адресное пространство CGN как общедоступное, если применимо.

• Протестируйте затронутые веб-сайты и, если отображается запрос на доступ к локальной сети, возможно, потребуется разрешить работу узла верхнего уровня с помощью политики LocalNetworkAccessAllowedForUrls .

• Для веб-сайтов, где проблема сохраняется (то есть запрос LNA был разрешен, но сайт по-прежнему завершается ошибкой, если не используется политика отказа), рассмотрите возможность включения политики LocalNetworkAccessPermissionsPolicyDefaultEnabled вместе с LocalNetworkAccessAllowedForUrls .

• Протестируйте эти конфигурации с помощью репрезентативной группы пользователей из разных отделов, которые используют различные веб-приложения, и настройте конфигурацию политики при необходимости.

Как я могу предоставить отзыв о LNA в целом?

Отправьте сообщение о проблеме с отзывом в репозиторий спецификации доступа к локальной сети на сайте GitHub.

Как сообщить об ошибках в реализации LNA Microsoft Edge?

Для устранения проблем, связанных с реализацией microsoft Edge доступа к локальной сети, используйте каналы обратной связи Microsoft Edge или свяжитесь с служба поддержки Майкрософт для корпоративных клиентов.

[Enterprise] Url-адреса списка разрешений или списка блокировок для запросов локальной сети

Существует две корпоративные политики для LNA: LocalNetworkAccessAllowedForUrls и LocalNetworkAccessBlockedForUrls. Их можно использовать, чтобы разрешить запросы локальной сети из URL-адреса без отображения запроса на разрешение или запретить URL-адресу выполнять запросы локальной сети.

Эти политики также поддерживают подстановочные знаки с синтаксисом URL-шаблона .

Политика LocalNetworkAccessAllowedForUrls применяется к источнику верхнего уровня сайта, выполняющего запрос. Если фактический доступ к локальной сети осуществляется внутри iframe, внедренного на этой странице (или во вложенный iframe), все iframe должны задать флаг политики разрешений.

[Enterprise] Я настроил LocalNetworkAccessAllowedForUrls, но у меня по-прежнему возникают проблемы

Если вы правильно настроили политику LocalNetworkAccessAllowedForUrls , но приложения по-прежнему не работают, скорее всего, вам потребуется исправить iframes. См. раздел выше с заголовком "Как выполнять запросы локальной сети из iframe?"

Существует также временная корпоративная политика LocalNetworkAccessRestrictionsTemporaryOptOut, которая позволяет предприятиям отказаться от всех ограничений LNA. Эта политика является временной и будет удалена после Edge 152.

Примечание. Эти политики можно настроить с помощью групповая политика (с помощью шаблонов ADMX), Microsoft Intune (с помощью каталога параметров) или других решений для мобильных Управление устройствами (MDM). Дополнительные сведения о настройке политик Microsoft Edge см. в разделе Настройка параметров политики Microsoft Edge.