ERR_QUIC_PROTOCOL_ERROR: что это и как исправить в Chrome и Edge

Что такое ERR_QUIC_PROTOCOL_ERROR?

ERR_QUIC_PROTOCOL_ERROR означает, что QUIC-соединение Chrome с сайтом оборвалось, обычно уже после того, как сайт начал присылать страницу. QUIC — транспорт на основе UDP, на котором работает HTTP/3. Chrome показывает общую страницу «Не удается получить доступ к сайту» («Веб-страница по адресу …, возможно, временно недоступна или постоянно перемещена по новому адресу») с кодом ошибки внизу; в Chromium это ошибка -356, «There is a QUIC protocol error».

Обычно Chrome восстанавливается сам: если запрос по QUIC не удался, он повторяет его по обычному TCP-соединению, если только сервер уже не начал отвечать (http_network_transaction.cc). Поэтому сеть, которая полностью блокирует QUIC, эту ошибку не вызывает; её вызывает сеть, VPN или сервер, которые дают QUIC начаться, а потом ломают его.

Ошибка бывает только в браузерах на Chromium: Chrome, Edge, Opera, Brave и Vivaldi. Это не то же самое, что ERR_SSL_PROTOCOL_ERROR (сбой TLS-рукопожатия) и ERR_NETWORK_CHANGED (подключение переключилось). Сначала обновите страницу: повторная попытка часто срабатывает. Если ошибка возвращается, способы ниже идут от самого надёжного, отключения QUIC, к разбору каждой причины.

Что такое QUIC и зачем Chrome его использует?

QUIC разработала Google: о нём объявили в 2013 году, а в 2021 году IETF стандартизировала его как RFC 9000. Он заменяет TCP + TLS единым зашифрованным протоколом поверх UDP и лежит в основе HTTP/3 (частный DNS в Android тоже использует его для DNS поверх HTTP/3: см. что такое приватный DNS).

Соединению TCP + TLS 1.3 нужно два обмена туда-обратно до первого запроса, QUIC хватает одного, а при возобновлении соединения — ни одного. 7 октября 2020 года Google сообщила, что 25% пользователей стабильного Chrome уже работают по IETF QUIC (черновик h3-29). По измерениям Google, задержка в Поиске снизилась более чем на 2%, повторная буферизация в YouTube сократилась более чем на 9%, а пропускная способность выросла более чем на 3% на компьютерах и на 7% на мобильных (Chromium Blog).

Chrome использует QUIC, только если сайт сообщает о нём в заголовке Alt-Svc или в HTTPS-записи DNS. Мы проверили 20 самых посещаемых сайтов 26 октября 2026 года: 10 из них объявляют HTTP/3 в заголовке Alt-Svc (Google, YouTube, Facebook, Instagram, Amazon, LinkedIn, Bing, WhatsApp, Cloudflare и OpenAI).

Что вызывает ERR_QUIC_PROTOCOL_ERROR?

Все причины устроены одинаково: QUIC начался, а потом что-то его сломало.

• Сеть, которая даёт QUIC начаться, а потом ломает его — файрволы, роутеры или оборудование провайдера, которые сбрасывают UDP-трафик или обрывают его по таймауту посреди передачи. (Сеть, полностью блокирующая UDP 443, просто заставляет Chrome использовать TCP, без ошибки.)
• VPN, который теряет UDP посреди соединения — когда VPN переподключается, меняет сервер или маршрут либо обрывает по таймауту молчащие UDP-потоки, открытое QUIC-соединение гибнет. (Путь, слишком узкий для QUIC, не проходит уже на рукопожатии, и тогда Chrome просто использует TCP.)
• Защитное ПО, проверяющее трафик — антивирус или «веб-защита» файрвола, которые перехватывают соединения, могут ломать QUIC-потоки.
• Нестабильное соединение — слабый Wi-Fi или переключение между сетями посреди загрузки.
• Настройка HTTP/3 на сайте — сервер или CDN объявляет HTTP/3, но его QUIC-стек даёт сбой посреди ответа. Тогда все видят ошибку именно на этом сайте, в любой сети: Проверка доступности сайта покажет, не работает ли он и у других.
• Не причина: прокси — Chrome использует QUIC только при прямых соединениях, поэтому при заданном прокси все запросы идут по TCP.

Способ 1: отключить протокол QUIC в Chrome

Самый надёжный способ: при отключённом QUIC Chrome использует для любого сайта HTTP/2 (или HTTP/1.1) поверх TCP. Страницы по-прежнему загружаются, вы лишь теряете выигрыш QUIC в скорости, который Google оценила примерно в 2% быстрее Поиск и на 9% меньше повторной буферизации в YouTube.

Для IT-администраторов: политика Chrome и Edge QuicAllowed со значением false отключает QUIC на управляемых устройствах, не трогая chrome://flags.

Отключение QUIC в Google Chrome

Выполните следующие шаги, чтобы отключить QUIC в Chrome на Windows, Mac или Linux.

1. Open Chrome and type in the address bar:
   chrome://flags/#enable-quic

2. Find "Experimental QUIC protocol"

3. Change the dropdown from "Default" to "Disabled"

4. Click "Relaunch" at the bottom to restart Chrome

5. Verify: visit the website that showed the error

Отключение QUIC в Microsoft Edge

Поскольку Edge основан на Chromium, процесс практически идентичен.

1. Open Edge and type in the address bar:
   edge://flags/#enable-quic

2. Find "Experimental QUIC protocol"

3. Change to "Disabled"

4. Click "Restart" to apply

Отключение QUIC в Opera и Brave

Opera и Brave используют ту же систему флагов Chromium.

Opera:  opera://flags/#enable-quic → Disabled → Restart
Brave:  brave://flags/#enable-quic → Disabled → Restart

Способ 2: сбросить соединения Chrome

Очистка данных редко помогает, а вот сброс открытых соединений может: Chrome тогда установит с сайтом новые QUIC- (или TCP-) соединения.

Сброс соединений, затем очистка кеша

Начните с Flush socket pools (см. примечание ниже). Если ошибка осталась, очистите кеш:

1. Press Ctrl+Shift+Delete (Windows/Linux) or Cmd+Shift+Delete (Mac)

2. Choose More → All time for the time range

3. Tick "Cached images and files"

4. Click "Delete data" ("Delete from this device" if you're signed out)

5. Restart Chrome and try the website again

Способ 3: отключить расширения браузера

Причина бывает редко: расширения не могут изменить сам QUIC, а «VPN»-расширения в Chrome для компьютера на деле являются прокси, из-за которых Chrome вообще не использует QUIC.

Откройте сайт в окне в режиме инкогнито (Ctrl+Shift+N): там расширения выключены, если вы не разрешили их. Если сайт открывается, отключайте расширения по одному на странице chrome://extensions/, чтобы найти виновника.

Способ 4: проверить настройки файрвола и антивируса

Файрвол, который полностью блокирует UDP-порт 443, эту ошибку не вызывает: Chrome просто использует TCP. Беда в файрволе или защитном ПО, которое даёт QUIC начаться, а потом сбрасывает или проверяет его пакеты.

Либо полностью разрешите исходящий UDP 443, либо полностью заблокируйте его. Вот как проверить типичные случаи.

Брандмауэр Windows

Брандмауэр Windows Defender по умолчанию разрешает исходящий трафик, а правило блокировки всегда сильнее правила разрешения, поэтому ищите добавленное кем-то правило блокировки и отключайте его. Запустите PowerShell от имени администратора:

# List enabled outbound block rules that cover UDP (or any protocol)
Get-NetFirewallRule -Direction Outbound -Action Block -Enabled True |
  Where-Object { ($_ | Get-NetFirewallPortFilter).Protocol -in 'UDP', 'Any' } |
  Select-Object Name, DisplayName

# Turn off the rule that blocks UDP 443 (use its Name from the list)
Disable-NetFirewallRule -Name '<Name>'

Файрвол macOS

Встроенный файрвол macOS управляет только входящими подключениями, поэтому блокировать QUIC он не может. Если у вас есть файрвол для исходящего трафика, например Little Snitch или LuLu, проверьте его правила для UDP-трафика Chrome на порт 443.

Файрвол на уровне роутера

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

Затем найдите в панели управления роутера (обычно 192.168.1.1 или 192.168.0.1) настройки файрвола, «SPI» или безопасности, ограничивающие UDP, и обновите прошивку.

Способ 5: проверить VPN

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

Отключите VPN и обновите страницу. Если ошибка пропала, попробуйте следующее:

• Смените сервер или протокол VPN — более стабильный сервер или другой протокол часто прекращает обрывы
• Корпоративные VPN — многие сети компаний блокируют QUIC намеренно, чтобы проверять HTTPS; следуйте настройкам IT-отдела и отключите QUIC, если ошибки продолжаются
• Оставьте QUIC выключенным, пока работает VPN — способ 1 подходит к любому VPN, потому что Chrome тогда использует TCP

Способ 6: найти скрытый прокси или фильтр трафика

Настройка прокси эту ошибку не вызывает: Chrome использует QUIC только при прямых соединениях, поэтому через прокси все запросы идут по TCP. Но за прокси можно принять защитное ПО или VPN, которое фильтрует трафик на сетевом уровне без настройки прокси.

Если ошибка появляется в любой сети, но только на этом компьютере, отключайте такое ПО («веб-экран», «защиту сети», VPN-приложение, работающее в фоне) по одному и обновляйте страницу.

Способ 7: обновить Chrome до последней версии

Код QUIC в Chrome обновляется регулярно, и обновления исправляют ошибки на стороне Chrome. Прежде чем что-то менять на компьютере, который давно был без сети, обновите Chrome (или Edge, Opera, Brave).

1. Open Chrome → click ⋮ (three dots) → Help → About Google Chrome

2. Chrome will automatically check for updates

3. If an update is available, click "Relaunch" to apply

4. After updating, verify your Chrome version:
   chrome://version
   
   Look for the version number 

Проблемы QUIC на стороне сервера (для владельцев сайтов)

Если вы владелец сайта и ваши посетители сообщают об ошибке ERR_QUIC_PROTOCOL_ERROR, проблема может быть на вашем сервере. Вот наиболее распространённые серверные причины.

• Настройка HTTP/3 в Cloudflare — если посетители сообщают об ошибке, а вы используете Cloudflare, проверьте Speed > Settings > Protocol Optimization > HTTP/3 и на время протестируйте с отключённым параметром
• HTTP/3 на вашем сервере — в nginx HTTP/3 есть с версии 1.25.0 (listen 443 quic reuseport; и заголовок Alt-Svc); LiteSpeed и Caddy тоже его поддерживают. Убедитесь, что UDP-слушатель на порту 443 доступен, а ваш QUIC-стек обновлён. QUIC всегда использует TLS 1.3: Проверка SSL сертификата покажет, предлагает ли его ваш сервер
• Балансировщики нагрузки, не пересылающие UDP — балансировщики уровня приложений, например AWS ALB, пропускают только TCP. Если вы объявляете h3 в Alt-Svc, но не пересылаете UDP 443, Chrome помечает QUIC для вашего сайта как нерабочий на 5 минут, затем пробует снова, удваивая паузу до 2 суток, и каждый раз запускает гонку с TCP: уберите заголовок или используйте балансировщик с поддержкой UDP (уровня 4)

# Test HTTP/3 only, with no fallback (needs a curl built with HTTP/3)
curl --http3-only -sI https://your-domain.com

# Check something listens on UDP 443 (as root; firewalls are separate)
ss -ulnp 'sport = :443'

# Verify Alt-Svc header (tells browsers QUIC is available)
curl -sI https://your-domain.com | grep -i alt-svc
# Expected: alt-svc: h3=":443"; ma=86400

Стоит ли оставить QUIC включённым или отключить?

Отключить QUIC — безопасное решение, но в здоровой сети вы теряете реальную скорость. Практический способ решить:

Оставьте QUIC включённым дома, в мобильной сети и в любой сети, где ошибки нет. По данным Google, с ним быстрее Поиск, меньше повторной буферизации видео и выше пропускная способность, а QUIC не обрывает соединение, когда телефон переключается с Wi-Fi на мобильную сеть.

Отключите QUIC в сети или VPN, где ошибка возвращается снова и снова. Chrome тогда использует HTTP/2 (или HTTP/1.1) поверх TCP, с которым справляется любая сеть; на хорошем широкополосном канале большинство разницы не заметит.

Когда такой же сбой случается по HTTP/2, а не по QUIC, Chrome показывает ERR_HTTP2_PROTOCOL_ERROR, у которой свои причины и способы исправления.