Что означает ERR_SPDY_PROTOCOL_ERROR в nginx?
Я и несколько моих коллег получили net::ERR_SPDY_PROTOCOL_ERROR ошибка.
Мы используем ngnix версии 1.8.0. Ошибка не является стабильной (трудно реплицируется), и журнал ошибок Ngnix не имеет этой ошибки.
Как бы вы посоветовали нам поймать и решить эту проблему?
11 ответов
Я сталкивался с этим вопросом, пытаясь найти помощь по проблеме, с которой столкнулся ERR_SPDY_PROTOCOL_ERROR на хром. Думал, что это может принести пользу другим.
Наша ситуация / решение: Мы используем балансировщик нагрузки приложений AWS, подключенный к экземплярам EC2. Один из сценариев, которые мы запускаем на прокси-запросах EC2 из клиентского браузера. Недавно мы обновили скрипт - без соответствующих изменений - и заметили, что запросы Chrome и Safari к прокси-скрипту начали давать сбой. Хром показал ERR_SPDY_PROTOCOL_ERROR ошибка и, когда мы копались в нем, мы могли видеть, что этот запрос использует HTTP/2. Запросы Firefox продолжали работать нормально.
Наше решение: мы отключили поддержку HTTP / 2 в ALB. Сразу решил проблему.
Команда AWS CLI:
aws elbv2 modify-load-balancer-attributes --load-balancer-arn <your_load_balancer_arn> --attributes Key=routing.http2.enabled,Value=false
У меня была такая же проблема, проверьте, достаточно ли у вас места в разделе / жестком диске Nginx, мы добавили немного, и это сработало для нас.
TL; DR: если вы кэшируете ресурсы, проверьте дисковое пространство на вашем сервере nginx.
Наш сценарий
Я не уверен, где разместить свой ответ на это, так как это может быть крайний случай при получении ERR_SPDY_PROTOCOL_ERROR в Chrome (и эквивалентная ошибка "сбой загрузки ресурса" в Firefox). Но этот пост помог мне сузить преступника. Это не были заголовки, gzip, перенаправления или adblock/ublock.
У нас есть 2 веб-приложения, развернутые с компьютера, и оба работали отлично. Недавно мы развернули одно из приложений с изменениями в кэшированных ресурсах. После завершения развертывания мы сразу получили ERR_SPDY_PROTOCOL_ERROR из хрома. Интересно, что он получал HTTP 200 и если вы перейдете к активу напрямую, Chrome отобразит его. Однако загрузка ресурса на страницу может привести к сбою.
Интересно, что другое веб-приложение было прекрасно. Исследуя внутренние сети в Chrome, мы обнаружили, что сервер закрывает соединение. Через несколько часов мы решили, что это потому, что на нашем сервере nginx не хватило места на диске. Я не знаю, почему это привело бы к тому, что ресурсы загружались правильно, когда вы переходите к ним напрямую, но не работали, когда вы загружали страницу, но очистка пространства мгновенно решала проблему.
Как вы можете судить по другим ответам, это может вызывать множество разных вещей. Для меня у меня был искаженный заголовок, который другие браузеры просто игнорировали (дополнительный :). Единственный ответ на этот вопрос - подсказка по отладке, извлекающая события Chrome net-internals при загрузке испорченной страницы: chrome://net-internals/#events
Для меня, я знал, что это была проблема с заголовком, когда я увидел эту строку
t=65422 [st=53] HTTP_TRANSACTION_READ_HEADERS [dt=4]
--> net_error = -337 (ERR_SPDY_PROTOCOL_ERROR)
После удаления лишнего : из ответа заголовка HTTP/2 начал работать в Chrome. Я предлагаю получить сырой ответ от вашего сервера и провести очень тщательную проверку, чтобы убедиться в отсутствии синтаксических ошибок.
Кажется, есть много потенциальных причин. Сегодня я ударил заголовок
add_header X-Frame-Options: отказать;
Текущий chrome почему-то откажется от этого с помощью ssl+http2. Другие заголовки X-Frame, похоже, не являются проблемой.
Для меня это была конфигурация Nginx, которая не позволяла использовать метод OPTIONS. У меня был только белый список GET|PUT|POST|DELETE, поэтому, когда Chrome пытался отправить метод OPTIONS, потому что Бог знает, почему **, ошибка воспроизводилась.
Откройте Firefox и повторите запрос, затем посмотрите на Инспектора сети, чтобы проверить, отправляются ли какие-либо OPTIONS-запросы.
** возможно, для проверки X-Frame-Options или проверки HSTS.
Это известная проблема, которая существует между браузерами Chromium и некоторыми антивирусными программами, такими как AVG и Avast, особенно при использовании соединения SSL. Это не может быть решено на стороне пользователя. Разработчики веб-сайтов должны предотвратить возникновение этой проблемы.
Документация для веб-разработчиков находится здесь: http://dev.chromium.org/spdy/spdy-best-practices
Вот несколько полезных советов для разработчиков, которые конкретно не упомянуты в этой статье:
- Будьте предельно осторожны при использовании заголовков и перенаправлений, особенно 301 и 302
- Храните все свои включения в том же каталоге, что и для доступа к имени домена, но не выше каталога на сервере. Антивирус не может получить к ним доступ там. Чтобы защитить файлы включения, создайте файл.htaccess в каталоге включений и просто напишите одну строку: Запретить все
- Включить сжатие Gzip. Если вы используете cPanel, это можно сделать в настройках оптимизации вашего сайта.
- Держите ваш файл.htaccess простым. Переключение выходов сервера для создания различных расширений файлов и перенаправление пользовательских клиентов создаст ненужный конфликт.
По моему опыту, эта проблема возникает только при использовании сеансов для хранения и передачи данных. Cookies, Get и Post, похоже, не пострадали.
Надеюсь это поможет.
Если вы получаете
ERR_HTTP2_PROTOCOL_ERROR
ИЛИ
ERR_SPDY_PROTOCOL_ERROR
в браузере Chrome или Safari с помощью Nginx Content-Security-Policy сначала проверьте эту проблему, открыв скрытый интерфейс Chrome: chrome://net-internals/#events и выбрав кнопку "живые сеансы HTTP/2" на вкладке HTTP/2.
Если после обновления вы получите что-либо подобное нижеприведенному для вашего домена:
HTTP2_SESSION_RECV_INVALID_HEADER
-> error = "Недействительный символ в имени заголовка."
Вы должны написать заголовок CSP следующим способом:
add_header Content-Security-Policy "<values>";
У меня этот метод сработал.
ПРИМЕЧАНИЕ: Пробелы не допускаются в CSP. Используйте пробел, чтобы различать только параметр политики и его значение. Чтобы воспроизвести эту проблему в Chrome, вы можете использоватьadd_header Content-Security-Policy: "<values>"; которые имеют дополнительные : который будет считаться недействительным.
У меня был сайт, который делал это, оказалось, что кто-то забыл поместить "Location: " в редиректе PHP на первую строку index.php, лишив заголовка недействительностью. Хотя, видимо, заботился только о Chrome, остальные браузеры по-прежнему загружали его нормально.
Как и в случае с OP, для меня это была проблема с перебоями, возникающая только при запросах AJAX размером более 2 МБ.
Проблема начала возникать после того, как мы перешли с классического ELB AWS на ALB.
Я решил это, удалив Chrome, удалив мой профиль пользователя (на Mac удалите содержимое ~/Library/Application Support/Google/Chrome), затем переустановка.
Проверьте местоположение вашего кеша прокси - проверьте, существует ли он, есть ли место, и что разрешения и владелец позволяют nginx Процесс записи в путь.
например, nginx.conf (фрагмент)
proxy_cache_path /proxy_cache levels=1:2 keys_zone=danger_zone:10m inactive=60m;
... тогда проверьте /proxy_cache путь принадлежит и доступен для записи nginx,
В моем случае я решил эту проблему, увеличив размер чанка:
http2_chunk_size 300k;
Я видел эту ошибку недавно после обновления сервера.
Я видел это для всех пользователей в Chrome, но только с перерывами.
Мне удалось решить эту проблему для всех пользователей, заставив их использовать функцию обновления Chrome "Очистить кэш и полная перезагрузка" для сайта. (F12 для инструментов Chrome, щелкните правой кнопкой мыши кнопку обновления)
Я подозреваю, что это связано с тем, что кешируется информация об используемых сертификатах SSL.
Наша нынешняя структура была
AWS ELB=>Nginx=>JBoss
Это вызвало ту же ошибку crome. ERR_SPDY_PROTOCOL_ERROR
Он работал нормально без http2, который по умолчанию включен в ELB, мы не хотели, чтобы он был отключен. При дальнейшем исследовании было замечено, что наш сервер JBoss сжимал ответ, мы отключили его, и все работало нормально.