Comment réparer nginx lance 400 en-têtes de requêtes incorrectes sur tous les outils de test d’en-tête?

J’ai mon site qui utilise nginx, et teste le site avec des outils de test d’en-tête, par exemple http://www.webconfs.com/http-header-check.php, mais chaque fois qu’il est indiqué que 400 requêtes incorrectes sont utilisées par l’outil . Bien que toutes mes pages se chargent parfaitement dans le navigateur et quand je vois dans la console chromée, elle indique le code d’état 200OK.

HTTP/1.1 400 Bad Request => Server => nginx Date => Fri, 07 Sep 2012 09:40:09 GMT Content-Type => text/html Content-Length => 166 Connection => close 

Je ne comprends vraiment pas quel est le problème avec la configuration de mon serveur?

Un peu de googler suggère d’augmenter la taille du tampon en l’utilisant, et je l’ai augmenté comme suit:

 large_client_header_buffers 4 16k; 

Les mêmes résultats persistent.

Quelqu’un peut-il me guider dans la bonne direction?

Comme l’a déclaré Maxim Dounin dans les commentaires ci – dessus :

Lorsque nginx renvoie 400 (demande incorrecte), il enregistre la raison dans le journal des erreurs, au niveau “info”. Par conséquent, un moyen évident de savoir ce qui se passe est de configurer error_log pour enregistrer les messages au niveau “info” et examiner le journal des erreurs lors du test.

Une cause peut être un codage invalide dans la demande d’URL. Comme% étant passé non codé.

Oui, en modifiant le niveau de débogage error_to comme suggéré par Emmanuel Joubaud (éditez / etc / nginx / sites-enabled / default):

  error_log /var/log/nginx/error.log debug; 

Ensuite, après avoir restauré nginx, je suis entré dans le journal des erreurs avec mon application Python en utilisant uwsgi:

  2017/02/08 22:32:24 [debug] 1322#1322: *1 connect to unix:///run/uwsgi/app/socket, fd:20 #2 2017/02/08 22:32:24 [debug] 1322#1322: *1 connected 2017/02/08 22:32:24 [debug] 1322#1322: *1 http upstream connect: 0 2017/02/08 22:32:24 [debug] 1322#1322: *1 posix_memalign: 0000560E1F25A2A0:128 @16 2017/02/08 22:32:24 [debug] 1322#1322: *1 http upstream send request 2017/02/08 22:32:24 [debug] 1322#1322: *1 http upstream send request body 2017/02/08 22:32:24 [debug] 1322#1322: *1 chain writer buf fl:0 s:454 2017/02/08 22:32:24 [debug] 1322#1322: *1 chain writer in: 0000560E1F2A0928 2017/02/08 22:32:24 [debug] 1322#1322: *1 writev: 454 of 454 2017/02/08 22:32:24 [debug] 1322#1322: *1 chain writer out: 0000000000000000 2017/02/08 22:32:24 [debug] 1322#1322: *1 event timer add: 20: 60000:1486593204249 2017/02/08 22:32:24 [debug] 1322#1322: *1 http finalize request: -4, "/?" a:1, c:2 2017/02/08 22:32:24 [debug] 1322#1322: *1 http request count:2 blk:0 2017/02/08 22:32:24 [debug] 1322#1322: *1 post event 0000560E1F2E5DE0 2017/02/08 22:32:24 [debug] 1322#1322: *1 post event 0000560E1F2E5E40 2017/02/08 22:32:24 [debug] 1322#1322: *1 delete posted event 0000560E1F2E5DE0 2017/02/08 22:32:24 [debug] 1322#1322: *1 http run request: "/?" 2017/02/08 22:32:24 [debug] 1322#1322: *1 http upstream check client, write event:1, "/" 2017/02/08 22:32:24 [debug] 1322#1322: *1 http upstream recv(): -1 (11: Resource temporarily unavailable) 

Ensuite, j’ai jeté un coup d’œil à mon journal uwsgi et j’ai découvert que:

  Invalid HTTP_HOST header: 'www.mysite.local'. You may need to add u'www.mysite.local' to ALLOWED_HOSTS. [pid: 10903|app: 0|req: 2/4] 192.168.221.2 () {38 vars in 450 bytes} [Wed Feb 8 22:32:24 2017] GET / => generated 54098 bytes in 55 msecs (HTTP/1.1 400) 4 headers in 135 bytes (1 switches on core 0) 

Et en ajoutant http://www.mysite.local aux parameters.py ALLOWED_CONFIGS a résolu le problème 🙂

  ALLOWED_HOSTS = ['www.mysite.local'] 

Pour clearify, dans /etc/nginx/nginx.conf , vous pouvez mettre au début du fichier la ligne

 error_log /var/log/nginx/error.log debug; 

Et puis redémarrez nginx:

 sudo service nginx restart 

De cette façon, vous pouvez détailler ce que fait nginx et pourquoi il renvoie le code d’état 400.

Normalement, la méthode de Maxim Donnie peut en trouver la raison. Mais j’ai rencontré un 400 mauvaise demande ne se connectera pas à err_log. J’ai trouvé la raison avec l’aide de tcpdump