Explication comparative du code d'état 499 en HTTP et de l'erreur 499 sous nginx

Il existe de nombreuses situations dans lesquelles des erreurs 499 apparaissent dans le code d'état HTTP dans les enregistrements du journal. Une situation que j'ai rencontrée était que nginx était inversé vers un backend qui ne pouvait jamais être ouvert. C'était tout. L'enregistrement d'état du journal était 499. Envoyer. mot Le nombre de sections est 0.

Il y a toujours des utilisateurs qui signalent que le système du site Web est en panne. Parce que les produits en ligne n'ont pas été modifiés depuis longtemps, le problème avec le programme frontal peut être pratiquement éliminé, alors j'ai pensé que. l'interface appelée par la méthode Get n'est pas correcte. Elle était stable. J'ai demandé au personnel concerné et ils ont dit qu'il n'y avait pas de problème, j'ai demandé au personnel concerné le fichier journal du serveur nginx (awstats). log). Après analyse, j'ai constaté qu'il y avait de nombreuses erreurs avec le code d'erreur 499 dans le journal, représentant environ 1 % des fichiers journaux, et cela ne représente qu'environ 70 % de tous les rapports d'erreurs (voir la figure ci-dessous). pour tous les rapports d'erreurs), le total de tous les rapports d'erreurs dépassera 1 %, ce qui reste un montant très élevé.

Quelle est l'erreur 499 ? Jetons un coup d'œil à la définition dans le code source de NGINX :

ngx_string(ngx_http_error_495_page), /* 495, https certificate error */

ngx_string(ngx_http_error_496_page), /* 496, https pas de certificat * /

ngx_string(ngx_http_error_497_page), /* 497, http vers https */

ngx_string(ngx_http_error_404_page), /* 498, annulé */

ngx_null_string, /* 499 , le client a fermé la connexion */

Vous pouvez voir que 499 correspond à "le client a fermé la connexion". Cela est probablement dû au fait que le temps de traitement côté serveur est trop long et que le client est « impatient ».

Raisons et solutions de l'erreur Nginx 499

Ouvrez le fichier access.log de Nginx et constatez que HTTP1.1 499 0 est apparu dans la dernière soumission - une telle erreur, recherchez nginx 499 sur Baidu Error, le le résultat est que le client s'est activement déconnecté.

Mais après mon test, ce n'est évidemment pas un problème de client, car utiliser port + IP pour accéder directement au serveur back-end n'a pas ce problème. Plus tard, lors du test de nginx, j'ai trouvé que si le message. est soumis deux fois trop rapidement, 499 se produira. , il semble que nginx pense qu'il s'agit d'une connexion non sécurisée et rejette activement la connexion du client

Mais je ne trouve pas de solution lors de la recherche de problèmes associés. J'ai cherché sur Google et trouvé un forum anglais à ce sujet. Mauvaise solution :

proxy_ignore_client_abort on;

Je ne sais pas si c'est sûr.

Cela signifie configurer le paramètre. proxy_ignore_client_abort on;

signifie que le serveur proxy ne doit pas fermer activement la connexion client.

Redémarrez nginx avec cette configuration, et le problème est bel et bien résolu. C'est juste un petit manque de sécurité, mais c'est bien mieux que de toujours ne pas trouver le serveur.

Une autre raison est que j'ai testé plus tard et constaté que le client avait effectivement fermé la connexion, ou que la connexion avait expiré. Peu importe le délai d'attente que vous avez défini, cela ne sert à rien. suffisamment de processus php. Veuillez améliorer le problème du nombre de processus php. Pour résoudre le problème, seuls 5 processus enfants sont ouverts dans l'environnement de test par défaut.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!