Ответ 1

У меня была та же проблема, проверьте, есть ли у вас достаточно места в разделе Nginx/HDD, мы добавляем некоторые, и это сработало для нас.

Ответ 2

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 не хватило места на диске. Я не знаю, почему это привело бы к тому, что ресурсы загружались правильно, когда вы переходите к ним напрямую, но не работали, когда вы загружали страницу, но очистка пространства мгновенно решала проблему.

Ответ 3

Я столкнулся с этим вопросом, пытаясь найти справку по проблеме, с которой я столкнулся в 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

Ответ 4

Это известная проблема, которая существует между браузерами Chromium и некоторыми антивирусными программами, такими как AVG и Avast, особенно при использовании SSL-соединения. Он не может быть разрешен в конце пользователя. Это для разработчиков веб-сайтов, чтобы предотвратить эту проблему.

Документация для веб-разработчиков находится здесь: http://dev.chromium.org/spdy/spdy-best-practices

Вот несколько полезных советов для разработчиков, которые специально не упоминаются в этой статье:

• Будьте предельно осторожны при использовании заголовков и переадресаций, особенно 301 и 302
• Сохраняйте все свои входящие в или под тем же каталогом, что и ваш доступ к доменному имени, а не над каталогом на сервере. Антивирус не может получить к ним доступ. Чтобы защитить ваши включенные файлы, создайте файл .htaccess в каталоге include и просто напишите одну строку: Deny from all
• Включить сжатие Gzip. Если вы используете cPanel, это можно сделать в настройках Оптимизации веб-сайта.
• Сохраните файл .htaccess простым. Переключение выходов сервера для создания разных расширений файлов и перенаправления пользовательских клиентов создаст ненужный конфликт.

По моему опыту, эта проблема возникает только при использовании сеансов для хранения и передачи данных. Cookies, Get and Post, похоже, не будут затронуты.

Надеюсь, что это поможет.

Ответ 5

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

add_header X-Frame-Options: deny;

Текущий хром будет зависеть от того, что с ssl + http2 по какой-то причине. Другие заголовки X-Frame, похоже, не являются проблемой.

Ответ 6

Для меня это была конфигурация Nginx, которая не позволяла использовать метод OPTIONS. У меня был только белый список GET | PUT | POST | DELETE, поэтому, когда Chrome пытался отправить метод OPTIONS, потому что Бог знает, почему **, ошибка воспроизводилась.

Откройте Firefox и повторите запрос, затем посмотрите на Инспектора сети, чтобы проверить, отправляются ли какие-либо OPTIONS-запросы.

** возможно, для проверки X-Frame-Options или проверки HSTS.

Ответ 7

Как вы можете судить по другим ответам, это может вызывать множество разных вещей. Для меня, у меня был некорректный заголовок, что другие браузеры просто игнорируя (дополнительный :). Единственный ответ на это - отладочная подсказка, извлекающая события 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. Я предлагаю получить сырой ответ от вашего сервера и провести очень тщательную проверку, чтобы убедиться в отсутствии синтаксических ошибок.

Ответ 8

У меня был сайт, который это делал, оказалось, что кто-то забыл поставить "Location:" в перенаправление PHP в первой строке index.php, недействительным заголовком. Очевидно, только Chrome заботился об этом, остальные браузеры все равно загрузили его.

Ответ 9

Я видел эту ошибку недавно после обновления сервера.

Я видел его для всех пользователей в Chrome, но только с перерывами.

Мне удалось разрешить его для всех пользователей, заставив их использовать функцию обновления "Очистить кеш и жесткую перезагрузку Chrome" для сайта. (F12 для инструментов Chrome, щелкните правой кнопкой мыши кнопку обновления)

Я подозреваю, что это связано с чем-то кэшированным о используемых SSL-сертификатах.

Ответ 10

Как и в случае с OP, это было проблемой для меня, и это происходит только на AJAX-запросах размером > 2 МБ.

Проблема началась после того, как мы перешли с классического ELB в AWS в ALB.

Я решил это, удалив Chrome, удалив мой профиль пользователя (в Mac удалите содержимое ~/Library/Application Support/Google/Chrome), затем переустановите.

Ответ 11

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

например, nginx.conf (фрагмент)

proxy_cache_path/proxy_cache levels=1:2 keys_zone=danger_zone:10m inactive=60m;

... затем проверьте, что путь /proxy_cache принадлежит и доступен для записи nginx.

Ответ 12

В моем случае я решил эту проблему, увеличив размер чанка:

http2_chunk_size             300k;