Que signifie ERR_SPDY_PROTOCOL_ERROR dans nginx?
Quelques collègues et moi-même avons eu l'erreur net::ERR_SPDY_PROTOCOL_ERROR.
Nous utilisons ngnix version 1.8.0. L'erreur n'est pas stable (difficile à répliquer) et le journal des erreurs Ngnix ne contient pas cette erreur.
Comment conseilleriez-vous de résoudre ce problème?
J'ai eu le même problème, vérifiez si vous avez assez d'espace dans la partition/disque dur Nginx, nous en ajoutons et cela a fonctionné pour nous.
TL; DR : si vous mettez en cache des éléments, vérifiez l’espace disque sur votre serveur nginx.
Notre scénario
Je ne sais pas trop où poster ma réponse à cette question, car il pourrait s'agir d'un cas Edge lors de l'obtention du ERR_SPDY_PROTOCOL_ERROR dans Chrome (et de l'erreur équivalente "échec du chargement de ressources" dans Firefox). Mais ce post m'a aidé à cibler le coupable. Ce ne sont pas des en-têtes, gzip, redirections ou adblock/ublock.
Nous avons 2 applications Web déployées à partir de la machine, et les deux fonctionnaient parfaitement. Récemment, nous avons déployé l'une des applications avec des modifications apportées aux actifs mis en cache. Une fois le déploiement terminé, nous avons immédiatement reçu le ERR_SPDY_PROTOCOL_ERROR de Chrome. Chose intéressante, il recevait un HTTP 200 et si vous accédez directement à l'actif, Chrome le rendra. Cependant, le chargement de l'actif sur une page entraînerait son échec.
Curieusement, l’autre application Web était parfaitement satisfaisante. En examinant les internautes sur Chrome, nous avons découvert que le serveur fermait la connexion. Après plusieurs heures, nous avons déterminé que c'était parce que notre serveur nginx n'avait plus d'espace disque disponible. Je ne sais pas pourquoi cela entraînerait le chargement correct des actifs lorsque vous y accédiez directement, mais échouait lorsque vous chargiez une page, mais le fait de libérer de l'espace a immédiatement résolu le problème.
Je suis tombé sur cette question lorsque j'essayais de trouver de l'aide pour résoudre le problème que je rencontrais avec ERR_SPDY_PROTOCOL_ERROR sous Chrome. Pensé que cela pourrait profiter aux autres.
Notre situation/solution: Nous utilisons un AWS Application Load Balancer connecté à EC2 instances. Un des scripts que nous exécutons sur les demandes de proxy EC2 à partir du navigateur client. Nous avons récemment mis à jour le script - sans modifications pertinentes - et avons constaté que les demandes adressées par Chrome et Safari au script de proxy commençaient à échouer. Chrome affichait l'erreur ERR_SPDY_PROTOCOL_ERROR et, lorsque nous y avons inséré, nous avons constaté que cette requête utilisait HTTP/2. Les demandes de Firefox ont continué à bien fonctionner.
Notre solution: nous avons désactivé le support HTTP/2 dans ALB. Immédiatement résolu le problème.
Commande AWS CLI:
aws elbv2 modify-load-balancer-attributes --load-balancer-arn <your_load_balancer_arn> --attributes Key=routing.http2.enabled,Value=false
Comme vous pouvez le constater à partir des autres réponses, beaucoup de choses différentes peuvent en être la cause. Pour moi, j'avais un en-tête malformé que d'autres navigateurs ignoraient tout simplement (un : supplémentaire). La seule solution à cela est un conseil de débogage, consultez les événements net-internals de Chrome lors du chargement de la page cassée: chrome: // net-internals/# events
Pour moi, je savais que c'était un problème d'en-tête quand j'ai vu cette ligne
t=65422 [st=53] HTTP_TRANSACTION_READ_HEADERS [dt=4]
--> net_error = -337 (ERR_SPDY_PROTOCOL_ERROR)
Après avoir supprimé le : supplémentaire de la réponse de l'en-tête, HTTP/2 a commencé à fonctionner dans Chrome. Je suggère d’obtenir une réponse brute de votre serveur et de procéder à une inspection très minutieuse afin de s’assurer qu’il n’ya pas d’erreur de syntaxe.
Il semble y avoir beaucoup de causes potentielles. Celui que j'ai frappé aujourd'hui était la ligne d'en-tête
add_header X-Frame-Options: refuser;
Le chrome actuel va en parler avec ssl + http2 pour une raison quelconque. Les autres en-têtes X-Frame ne semblent pas poser de problème.
Pour moi, la configuration de Nginx n'autorisait pas la méthode OPTIONS. J'avais uniquement inscrit les listes GET | PUT | POST | DELETE sur la liste blanche. Ainsi, lorsque Chrome a tenté d'envoyer la méthode OPTIONS, Dieu sait pourquoi **, l'erreur a été reproduite.
Ouvrez Firefox et répétez la demande, puis consultez l'inspecteur de réseau pour vérifier si des demandes OPTIONS sont envoyées.
** probablement pour vérifier la vérification de X-Frame-Options ou HSTS.
Il s'agit d'un problème connu entre les navigateurs Chromium et certains programmes antivirus tels que AVG et Avast, notamment lors de l'utilisation d'une connexion SSL. Il ne peut pas être résolu du côté de l'utilisateur. Il appartient aux développeurs de sites Web d'empêcher ce problème de se produire.
La documentation pour les développeurs Web se trouve ici: http://dev.chromium.org/spdy/spdy-best-practices
Voici quelques astuces utiles pour les développeurs qui ne sont pas spécifiquement mentionnées dans cet article:
- Soyez extrêmement prudent lorsque vous utilisez des en-têtes et des redirections, en particulier 301 et 302
- Conservez tous vos éléments inclus dans ou sous le même répertoire que votre accès au nom de domaine, et non au-dessus de celui du serveur. Antivirus ne peut pas y accéder. Pour protéger vos fichiers d'inclusion, créez un fichier .htaccess dans le répertoire includes et écrivez simplement une ligne: Refuser de tout.
- Activer la compression Gzip. Si vous utilisez cPanel, vous pouvez le faire dans les paramètres d’optimisation de site Web.
- Gardez votre fichier .htaccess simple. Changer de sortie de serveur pour créer différentes extensions de fichier et rediriger les clients des utilisateurs créera des conflits inutiles.
D'après mon expérience, ce problème ne semble se produire que lorsque vous utilisez des sessions pour stocker et transmettre des données. Les cookies, Get et Post ne semblent pas être affectés.
J'espère que cela t'aides.
J'ai récemment vu cette erreur après une mise à niveau du serveur.
Je le voyais pour tous les utilisateurs de Chrome, mais seulement par intermittence.
J'ai pu résoudre ce problème pour tous les utilisateurs en leur demandant d'utiliser la fonction d'actualisation "Vider le cache et rechargement dur" de Chrome pour le site . (F12 pour les outils de Chrome, clic droit sur le bouton d'actualisation)
Je soupçonne que cela est lié à quelque chose en cache concernant les certificats SSL utilisés.
J'avais un site qui le faisait, il s'est avéré que quelqu'un avait oublié de placer "Emplacement:" dans une redirection PHP sur la première ligne de index.php, invalidant ainsi l'en-tête. Apparemment, seul Chrome s'en souciait, le reste des navigateurs le chargeait toujours bien.
Comme pour le PO, il s’agissait d’un problème intermittent pour moi qui ne concernait que les demandes AJAX de plus de 2 Mo.
Le problème a commencé à se produire après le passage d'un ELB classique AWS à ALB.
J'ai résolu ce problème en désinstallant Chrome, en supprimant mon profil utilisateur (sous Mac, supprimez le contenu de ~/Library/Application Support/Google/Chrome), puis en le réinstallant.
Dans mon cas, j'ai résolu ce problème en augmentant la taille du bloc:
http2_chunk_size 300k;
Vérifiez l'emplacement de votre chemin de cache de proxy - vérifiez qu'il existe, qu'il a de l'espace et que les autorisations et le propriétaire permettent au processus nginx d'écrire dans le chemin.
par exemple. nginx.conf (extrait)
proxy_cache_path /proxy_cache levels=1:2 keys_zone=danger_zone:10m inactive=60m;
... puis vérifiez que le chemin /proxy_cache est possédé et accessible en écriture par nginx.