Я и несколько моих коллег получили ошибку net::ERR_SPDY_PROTOCOL_ERROR
.
Мы используем ngnix версии 1.8.0. Ошибка нестабильна (трудно реплицировать), и журнал ошибок Ngnix не имеет этой ошибки.
Как бы вы посоветовали нам это поймать и решить?
Я и несколько моих коллег получили ошибку net::ERR_SPDY_PROTOCOL_ERROR
.
Мы используем ngnix версии 1.8.0. Ошибка нестабильна (трудно реплицировать), и журнал ошибок Ngnix не имеет этой ошибки.
Как бы вы посоветовали нам это поймать и решить?
У меня была та же проблема, проверьте, есть ли у вас достаточно места в разделе Nginx/HDD, мы добавляем некоторые, и это сработало для нас.
TL; DR: если вы кэшируете ресурсы, проверьте дисковое пространство на вашем сервере nginx.
Я не уверен, где разместить свой ответ на это, так как это может быть ERR_SPDY_PROTOCOL_ERROR
случай при получении ERR_SPDY_PROTOCOL_ERROR
в Chrome (и эквивалентная ошибка "сбой при загрузке ресурса" в Firefox). Но этот пост помог мне сузить преступника. Это не были заголовки, gzip, перенаправления или adblock/ublock.
У нас есть 2 веб-приложения, развернутые с компьютера, и оба работали отлично. Недавно мы развернули одно из приложений с изменениями в кэшированных ресурсах. После завершения развертывания мы немедленно получили ERR_SPDY_PROTOCOL_ERROR
от Chrome. Интересно, что он получал HTTP 200
и если вы переходите непосредственно к ресурсу, Chrome отобразит его. Однако загрузка ресурса на страницу может привести к сбою.
Интересно, что другое веб-приложение было прекрасно. Исследуя внутренние сети в Chrome, мы обнаружили, что сервер закрывает соединение. Через несколько часов мы решили, что это потому, что на нашем сервере nginx не хватило места на диске. Я не знаю, почему это привело бы к тому, что ресурсы загружались правильно, когда вы переходите к ним напрямую, но не работали, когда вы загружали страницу, но очистка пространства мгновенно решала проблему.
Я столкнулся с этим вопросом, пытаясь найти справку по проблеме, с которой я столкнулся в ERR_SPDY_PROTOCOL_ERROR
в Chrome. Думал, что это может принести пользу другим.
Наша ситуация/решение: Мы используем балансировщик нагрузки приложений AWS, подключенный к экземплярам EC2. Один из сценариев, которые мы запускаем на прокси-запросах EC2 из клиентского браузера. Недавно мы обновили скрипт - без соответствующих изменений - и заметили, что запросы Chrome и Safari к прокси-скрипту начали давать сбой. Chrome показал ошибку 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
Это известная проблема, которая существует между браузерами Chromium и некоторыми антивирусными программами, такими как AVG и Avast, особенно при использовании SSL-соединения. Он не может быть разрешен в конце пользователя. Это для разработчиков веб-сайтов, чтобы предотвратить эту проблему.
Документация для веб-разработчиков находится здесь: http://dev.chromium.org/spdy/spdy-best-practices
Вот несколько полезных советов для разработчиков, которые специально не упоминаются в этой статье:
По моему опыту, эта проблема возникает только при использовании сеансов для хранения и передачи данных. Cookies, Get and Post, похоже, не будут затронуты.
Надеюсь, что это поможет.
Похоже, что существует много потенциальных причин. Сегодня я столкнулся с линией заголовка
add_header X-Frame-Options: deny;
Текущий хром будет зависеть от того, что с ssl + http2 по какой-то причине. Другие заголовки X-Frame, похоже, не являются проблемой.
Для меня это была конфигурация Nginx, которая не позволяла использовать метод OPTIONS. У меня был только белый список GET | PUT | POST | DELETE, поэтому, когда Chrome пытался отправить метод OPTIONS, потому что Бог знает, почему **, ошибка воспроизводилась.
Откройте Firefox и повторите запрос, затем посмотрите на Инспектора сети, чтобы проверить, отправляются ли какие-либо OPTIONS-запросы.
** возможно, для проверки X-Frame-Options или проверки HSTS.
Как вы можете судить по другим ответам, это может вызывать множество разных вещей. Для меня, у меня был некорректный заголовок, что другие браузеры просто игнорируя (дополнительный :
). Единственный ответ на это - отладочная подсказка, извлекающая события Chrome net-internals при загрузке испорченной страницы: chrome://net-internals/# events
Для меня, я знал, что это была проблема с заголовком, когда я увидел эту строку
t=65422 [st=53] HTTP_TRANSACTION_READ_HEADERS [dt=4]
--> net_error = -337 (ERR_SPDY_PROTOCOL_ERROR)
После удаления из заголовка extra :
HTTP/2 начал работать в Chrome. Я предлагаю получить сырой ответ от вашего сервера и провести очень тщательную проверку, чтобы убедиться в отсутствии синтаксических ошибок.
У меня был сайт, который это делал, оказалось, что кто-то забыл поставить "Location:" в перенаправление PHP в первой строке index.php, недействительным заголовком. Очевидно, только Chrome заботился об этом, остальные браузеры все равно загрузили его.
Я видел эту ошибку недавно после обновления сервера.
Я видел его для всех пользователей в Chrome, но только с перерывами.
Мне удалось разрешить его для всех пользователей, заставив их использовать функцию обновления "Очистить кеш и жесткую перезагрузку Chrome" для сайта. (F12 для инструментов Chrome, щелкните правой кнопкой мыши кнопку обновления)
Я подозреваю, что это связано с чем-то кэшированным о используемых SSL-сертификатах.
Как и в случае с 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;