Cela faisait longtemps, et aujourd’hui nous allons parler du serveur web sous le célèbre NGINX. J’ai décidé de faire cet article, car c’est un sujet assez intéressant et qui pourra peut-être vous aider si vous arrivez ici. Un ami m’a donc contacté il y a quelque temps, car il a constaté que son site web commençait à se désindexer petit à petit de Google. Problème, il s’agit d’un site à fort trafic et c’est un moyen pour lui de gagner sa vie. Donc quand il m’a contacté, il était un peu en panique … L’enquête commence donc rapidement. Une fois que j’avais accès à son serveur en SSH et sa search console de Google, j’ai pu rapidement y voir plus clair sur son problème.
D’ailleurs, la search console est un outil qui je le rappelle est indispensable si vous possédez un site web, sauf si Google ne vous intéresse pas et là, effectivement, c’est inutile pour vous. C’est facile à installer et vous pouvez suivre vos performances sur le moteur de recherche Google en un clin d’œil. Cela vous permet aussi de voir directement si Google constate des problèmes avec votre site Web. N’oubliez pas qu’il existe aussi la Bing Webmaster Tools qui n’est pas dénuée d’intérêt et est un bon complément si vous voulez suivre vos performances sur le moteur de recherche Bing.
Je commence donc par regarder la search console de Google et effectivement, il ne m’avait pas menti. On voit que son trafic organique est en chute libre alors qu’il était jusqu’à présent très stable. Il me confirme qu’il n’a rien changé sur son site. Tout son trafic naturel est en train de disparaître.
Je me rends ensuite, dans la partie erreur de la search console, et je vois qu’elles sont en augmentation chaque jour. Je décide donc d’aller faire un tour sur son serveur web qui tombe donc sous NGINX. Une fois dans les logs de son site qui tourne avec NGINX, je constate qu’une erreur revient très souvent, il s’agit de : upstream sent too big header while reading response header from upstream
Très bien, je prends note, je l’avais encore jamais celle-ci, c’est aussi ce que j’aime dans l’informatique, on apprend tous les jours. Une autre chose assez étrange que je constate, c’est que lorsque j’essaye de me balader sur le site, je n’ai aucune erreur toutes les pages répondent correctement. J’essaye ensuite essayé avec un crawler fait maison en PHP, pareil toutes les pages répondent bien, je n’ai pas d’erreur 50X. Par contre, quand je teste les pages via la search console, parfois Google me remonte alors une erreur 50X, il n’arrive pas à crawl la page et récupérer son contenu.
Bon, étant donné que c’est cette même erreur mentionné plus haut qui revient tout le temps dans les logs de NGINX, je vais essayer de la corriger directement car elle pollue de toute façon les logs. On verra ensuite comment Google le prend et si c’est bien la cause du problème.
Comment résoudre l’erreur upstream sent too big header while reading response header from upstream
Après quelques recherches voici ce que j’ai trouvé. L’erreur « upstream sent too big header while reading response header from upstream » est généralement causée par un en-tête de réponse trop volumineux provenant de l’upstream. En gros, NGINX ne peut pas traiter la demande avec les limites d’en-tête actuellement définies par ce qui est envoyé en amont, le PHP-FPM dans mon cas. Pourquoi ça s’est mis à coincer d’un coup qu’il n’y a eu aucune modification sur le serveur, je l’ignore.
Pour résoudre ce problème, il faut donc augmenter les limites de taille de l’en-tête dans la configuration de notre serveur proxy NGINX. Ouvrez le fichier de configuration de votre serveur NGINX. Il peut se trouver à différents emplacements en fonction de votre système, mais un emplacement commun est /etc/nginx/nginx.conf. Si vous avez une configuration spécifique à un site, vous pouvez également ajouter ces directives à cette configuration.
Personnellement, c’est comme ça que je fonctionne, j’ai une configuration par site. Je fais la configuration en fonction des besoins du site et de ses spécificités plutôt qu’une configuration générale. C’est particulièrement le cas entre mes WordPress et projets sous Laravel qui ont des besoins différents, mais c’est un autre sujet qui pourrait faire l’objet d’un article complet.
Une fois que vous avez sauvegardé votre fichier de configuration d’origine, dans la configuration de votre site ou générale, dans la partie « server », ajoutez les directives suivantes dans le fichier :
server {
# configuration de base au dessus, on ne touche pas #
# tips by zonetuto.fr #
# fastcgi buffers for php-fpm #
fastcgi_buffers 16 32k;
fastcgi_buffer_size 64k;
fastcgi_busy_buffers_size 64k;
# nginx buffers #
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
# suite et fin de la configuration nginx #
}Vérifiez que votre configuration NGINX est toujours valide en exécutant :
nginx -tSi tout est en ordre, vous verrez un message indiquant « test is successful ». Si ce n’est pas le cas, vous avez probablement introduit une erreur de syntaxe en modifiant votre fichier de configuration. Remettez le contenu de contenu de votre sauvegarde, puis testez à nouveau.
Si le test de « nginx -t » est ok, redémarrez NGINX pour que les modifications prennent effet. La commande pour cela peut varier en fonction de votre système, mais elle peut ressembler à sudo systemctl restart nginx ou sudo service nginx restart.
Normalement, cela devrait aider à résoudre l’erreur, en tout cas sur le serveur de mon ami, dès la mise en production, elle a disparu. Cependant, veuillez noter que l’augmentation de ces limites peut augmenter l’utilisation de la mémoire de votre serveur, alors ajustez les valeurs en conséquence. Si l’erreur persiste même après avoir augmenté ces valeurs, il est possible que vous ayez un problème plus profond dans votre application qui génère des en-têtes extrêmement volumineuses en taille. Elles devraient être résolues d’une autre manière. Il faudra pousser l’analyse plus loin …
Explication des paramètre de la nouvelle configuration NGINX
Bon, je ne vais pas vous laisser comme ça et essayer de vous donner quelques explications sur ses nouveaux paramètres. Le but étant encore une fois de bien comprendre ce que l’on fait.
fastcgi_buffers 16 32k; : Cette directive détermine le nombre et la taille des tampons qui sont utilisés pour le traitement des requêtes. Le premier nombre, 16, est le nombre de tampons, et le second, 32k, est la taille de chaque tampon. Les tampons sont utilisés pour stocker les données reçues de l’upstream jusqu’à ce qu’une réponse complète soit reçue.
fastcgi_buffer_size 64k; : C’est la taille du tampon utilisé pour la première partie de la réponse reçue de l’upstream, qui inclut généralement les en-têtes de réponse. Dans ce cas, la taille du tampon est définie à 64k.
fastcgi_busy_buffers_size 64k; : Cette directive détermine la taille maximale des tampons occupés qui peuvent être en cours d’utilisation par NGINX pour le traitement des requêtes. Si les tampons dépassent cette taille, NGINX commencera à écrire les réponses sur le disque, ce qui peut réduire les performances.
proxy_buffer_size 128k; : Semblable à fastcgi_buffer_size, cette directive détermine la taille du tampon utilisé pour stocker la première partie de la réponse reçue de l’upstream dans une configuration de proxy. La taille est définie à 128k ici.
proxy_buffers 4 256k; : Cette directive définit le nombre et la taille des tampons utilisés pour lire les réponses du serveur proxy. Ici, il y a 4 tampons, chacun de 256k.
proxy_busy_buffers_size 256k; : Cette directive détermine la taille maximale des tampons occupés qui peuvent être en cours d’utilisation par NGINX pour le traitement des requêtes dans une configuration de proxy. Si les tampons dépassent cette taille, NGINX commencera à écrire les réponses sur le disque.
Ces directives sont toutes utilisées pour contrôler comment NGINX gère les tampons lors de la communication avec les serveurs upstream. En augmentant ces valeurs, vous pouvez permettre à NGINX de traiter de plus grandes réponses sans avoir à écrire sur le disque ou à générer des erreurs. Ça permet d’augmenter les performances et surtout d’éviter les erreurs 50X.
Par contre, ça augmentera également l’utilisation de la mémoire, vous devez donc trouver un équilibre entre les performances et l’utilisation de la mémoire en fonction des capacités de votre serveur. De mon côté aucun souci à ce niveau-là et je pourrais largement augmenter ces valeurs sans le moindre problème.
Pour conclure cet article, je me pose tout de même une question. Pourquoi je n’avais pas l’erreur en parcourant le site web sous WordPress de manière classique et pourquoi même mon crawler qui tapait toutes les pages à toute vitesse ne rencontrai pas ce problème non plus. Pourquoi quand je soumettais une page Google à la main dans la search console il avait cette erreur. Sachant que le bot de Google devait voir la même chose, ce qui semble normal, cela reste un mystère. Néanmoins, je suis heureux que cette correction ait résolu le problème chez mon ami et ensuite, Google a pu sans problème parcourir de nouveau l’ensemble des pages.
Finalement et heureusement, mon ami a retrouvé toutes ses positions et tout est revenu à la normale. Si vous rencontrez ce problème, j’espère que cela vous aidera aussi. La magie du SEO et l’administration de serveur web …