délai d'expiration de la connexion nginx et problème de connexion fermée du client


21

J'ai ce serveur nginx en cours d'exécution sur AWS et cela fonctionnait très bien jusqu'à récemment lorsque quelques utilisateurs ont commencé à se plaindre du fait que le site Web ne s'ouvrait pas jusqu'à ce qu'ils aient fait environ 10 tentatives pour y accéder.

Je n'ai jamais pu reprocher le problème de mon côté. J'utilise le DNS de Google, c'est-à-dire 8.8.8.8 et quand j'ai changé la même chose pour l'un des utilisateurs, le site fonctionnait bien. Maintenant, cela peut être la raison ou cela peut aussi être juste une coïncidence.

J'ai trouvé cela dans le journal des erreurs -

2014/05/29 13:46:15 [info] 6940#0: *150649 client timed out (110: Connection timed out) while waiting for request, client: xx.xxx.xxx.xx, server: 0.0.0.0:80
2014/05/29 13:46:20 [info] 6940#0: *150670 client closed connection while waiting for request, client: xx.xxx.xxx.xx, server: 0.0.0.0:80
2014/05/29 13:46:20 [info] 6940#0: *150653 client closed connection while waiting for request, client: xx.xxx.xxx.xx, server: 0.0.0.0:80
2014/05/29 13:46:20 [info] 6940#0: *150652 client closed connection while waiting for request, client: xx.xxx.xxx.xx, server: 0.0.0.0:80

Et certains endroits, même cela -

2014/05/29 13:46:53 [info] 6940#0: *150665 client closed connection while waiting for request, client: xx.xxx.xxx.xx, server: 0.0.0.0:80
2014/05/29 13:46:53 [info] 6940#0: *150660 client xx.xxx.xxx.xx closed keepalive connection

Remarque - avoir placé xx.xxx.xxx.xx pour l'IP clien't

Voici la configuration de nginx -

server {
    listen       80;
    server_name  somedomain.com  www.somedomain.com;

    #charset koi8-r;
    #access_log  /var/log/nginx/log/host.access.log  main;

    root        /var/www/somedomain/current/app/webroot;
    index       index.php index.html index.htm;

    ... couple of location rules ...
}

J'apprécierais vraiment toute aide.

Merci


1
Cela pourrait être un problème avec la connexion des développeurs au serveur, pas au serveur. Étant donné que vous ne pouvez pas recréer le problème et que le serveur lui-même enregistre un délai d'expiration de connexion client, nous devons soupçonner que le développeur peut être derrière un pare-feu et qu'il a des problèmes de réseau interne qui provoquent cela.
Andrew S

Vous pouvez essayer de désactiver Keep-Alive juste comme test pour ce problème. Je ne suis pas sûr que le trafic frappe votre serveur Web, mais Keep-Alive pourrait vous amener à atteindre la limite de concurrence dans votre configuration nginx. Voici plus d'informations: nginx.com/blog/http-keepalives-and-web-performance
Alfonso

1
@NitishDhar Avez-vous réussi à résoudre ce problème? Je suis également confronté au même problème et je n'en sais rien. Sera heureux si vous pouvez partager la solution.
Ethan Collins

2
Questions: le serveur est-il derrière un équilibreur de charge ou un pare-feu? Le NAT est-il impliqué? Existe-t-il un tunnel quelconque entre le serveur et Internet? La raison pour laquelle je demande est que cela ressemble au genre de chose qui se produit quand il y a un tunnel quelque part sur le chemin et que quelqu'un a bloqué tout ICMP, ce qui rompt la découverte du chemin MTU.
GeorgeB

De plus, quelle est la sortie de cat / proc / sys / net / ipv4 / tcp_mtu_probing
GeorgeB

Réponses:


6

D'après le journal que vous avez fourni depuis Nginx, il semble que les connexions entre votre serveur et les utilisateurs soient instables ou lentes. Veuillez essayer traceroutel'adresse IP de votre client ou sa passerelle depuis votre serveur. Aussi, pingvotre adresse IP client depuis longtemps pour voir le taux de perte de paquets et le temps de réponse. MTU peut être une autre source de ce problème. Testez si vous pouvez joindre votre client avec MTU = 1500 (Mac:) ping -D -s 1472 xx.xx.xx.xx.

BTW: Si votre serveur ou client réside en Chine, ce problème n'est généralement pas de votre faute. GFW est connu pour rejeter au hasard les paquets entre les frontières afin d'aggraver intentionnellement la qualité de la connexion internationale.


fyi, GFW = Great Firewall of China.
Roshan

0

Comme spéculé dans ce commentaire, il s'agit probablement d'une erreur de l'utilisateur et ils ferment la connexion (que ce soit intentionnellement ou non). Essayez de reproduire le problème de manière fiable. Excluez que cela se produise ailleurs et si ce n'est que cet endroit, ils devront dépanner de leur côté. Essayez à partir de différents navigateurs / ordinateurs, puis testez la fiabilité du réseau.


0

Ces entrées de journal ressemblent aux entrées qui s'affichent lorsque j'utilise des outils comme OpenVAS pour analyser un serveur. Ces outils établissent de mauvaises connexions, ralentissent ou fonctionnent mal; nginx rapporte juste qu'une connexion ne fonctionnait pas bien. Si tout le trafic provient de la même source, est rapide et n'a pas d'autres demandes légitimes à faire correspondre dans le journal d'accès, c'est probablement juste une sorte de bot-scanner.

Ces scanners pourraient également mettre votre application sous charge, ce qui pourrait la ralentir pour d'autres trafics légitimes.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.