nginx: enregistre la demande / réponse complète avec tous les en-têtes?

Nous avons un serveur d'applications qui se bloque parfois. Nous pensons que cela est dû à une mauvaise demande d'un client.

Nginx peut-il consigner la demande / réponse complète (comme les captures de fiddler) dans des fichiers afin que nous puissions voir les demandes envoyées avant le blocage?

(Nous devons probablement éviter PCAP et cette approche et tout faire avec nginx)

Si nginx n’est pas le bon outil pour cela, quel peut-être (à part un analyseur de réseau)?

nginx

— Sam Smith
source

mitmproxy en mode proxy inverse devrait faire ce que vous cherchez.

— Vivek Thomas

@VivekThomas c'est une question de nginx .... nous utilisons déjà nginx et ne changerons pas.

— samsmith

@samsmith Ancienne question, mais peut-être que cela aide quelqu'un d'autre: vous n'êtes pas obligé d'abandonner nginx. Selon les circonstances, vous pouvez simplement rediriger temporairement nginx vers un autre port, afin de permettre à mitmproxy d'intercepter le trafic et de prendre en charge le débogage. Ensuite, une fois terminé, vous pouvez simplement rediriger nginx vers le port d’origine et arrêter mitmproxy.

— Par Lundberg

Vous pouvez utiliser le module modsecurity, qui peut enregistrer les demandes / réponses complètes, voir nginx.com/blog/modsecurity-logging-and-debugging

— Willem

Réponses:

Pour que le corps de la demande soit envoyé par les visiteurs, utilisez client_body_in_file_only on;et enregistrez le fichier "temporaire" dans lequel il est écrit dans les journaux en ajoutant var $request_body_fileau format de journal. Les fichiers "temporaires" seront situés par défaut dans le répertoire client_temp.

Vous pouvez également enregistrer les en-têtes de requête $http_<header>et les en-têtes envoyés avec $sent_http_<header>.

Si vous avez un corps de requête et des en-têtes, vous devriez pouvoir le rejouer et obtenir la réponse de votre visiteur.

Vous devez également prendre en compte quelque chose comme gor pour pouvoir reproduire le trafic sur un autre environnement dans lequel vous pourriez laisser nginx écrire ces fichiers temporaires sans générer de problèmes d'E / S en production (nginx ne les purgera pas avec la onvaleur. C'est pourquoi ce n'est pas "temporaire". dans ce cas).

— Xavier Lucas
source

@jwadsack Lisez la réponse attentivement.

— Xavier Lucas

@XavierLucas Je pensais que vous proposiez deux approches différentes. Je n'avais pas réalisé que vous disiez les deux client_body_in_file_only et que vous en $http_<header>auriez besoin. Je comprends ça maintenant.

— jwadsack

Pourriez-vous s'il vous plaît partager un code plus précis?

— Velkan

Certes, $ http <header> n'est utile que si vous connaissez tous les noms d'en-tête à l'avance

— Ed Randall

Quelqu'un peut-il partager un fragment réel de la configuration nginx, s'il vous plaît?

— Nowaker

mitmproxy semble être le bon outil pour faire ce que vous demandez.

mitmproxy est un proxy man-in-middle interactif, compatible SSL, avec une interface de console.

mitmdump est la version en ligne de commande de mitmproxy. Pensez tcpdump pour HTTP.

traits

Intercepter les requêtes et les réponses HTTP et les modifier à la volée.

Enregistrez des conversations HTTP complètes pour une relecture et une analyse ultérieures.

Rejouer le côté client d'une conversation HTTP. Relire les réponses HTTP d'un serveur précédemment enregistré.

Mode proxy inverse pour transférer le trafic vers un serveur spécifié.

Mode proxy transparent sous OSX et Linux.

Apportez des modifications de script au trafic HTTP à l'aide de Python.

Les certificats SSL d'interception sont générés à la volée.

Le mode proxy inverse vous permettrait de capturer la demande et la réponse, comme le fait Fiddler.

— Vivek Thomas
source