nginx 연결 시간 초과 및 클라이언트 종료 연결 문제


21

나는이 nginx 서버를 AWS에서 실행 중이며 최근에 몇 명의 사용자가 웹 사이트에 대해 10 번 시도하려고 할 때까지 웹 사이트가 열리지 않는 것에 대해 불평하기 시작했을 때까지 정상적으로 작동했습니다.

나는 내 편에서 문제를 재현 할 수 없었다. Google의 DNS (예 : 8.8.8.8)를 사용하고 있으며 사용자 중 한 명을 동일하게 변경하면 사이트가 제대로 작동했습니다. 이것이 이유 일 수도 있고 우연의 일치 일 수도 있습니다.

오류 로그에서 이것을 발견했습니다.

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

그리고 어떤 곳은 이것조차도-

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

참고-clien't IP에 xx.xxx.xxx.xx를 배치했습니다

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 ...
}

정말 도움을 주셔서 감사합니다.

감사


1
이는 서버가 아닌 개발자의 서버 연결에 문제가 될 수 있습니다. 문제를 재현 할 수없고 서버 자체가 클라이언트 연결 시간 초과를 등록하고 있으므로 개발자가 방화벽 뒤에있을 수 있으며 이로 인해 내부 네트워킹 문제가있는 것으로 의심됩니다.
Andrew S

이 문제에 대한 테스트처럼 Keep-Alive를 비활성화 할 수 있습니다. 트래픽이 웹 서버에 충돌하는 것을 확신하지 못하지만 Keep-Alive로 인해 nginx 구성의 동시성 한계에 도달 할 수 있습니다. 자세한 정보는 다음과 같습니다. nginx.com/blog/http-keepalives-and-web-performance
Alfonso

1
@NitishDhar이 문제를 해결하셨습니까? 나는 또한 같은 문제에 직면하고 있으며 단서가 없습니다. 솔루션을 공유 할 수 있다면 기쁠 것입니다.
Ethan Collins

2
질문 : 서버가로드 밸런서 또는 방화벽 뒤에 있습니까? NAT가 관련되어 있습니까? 서버와 인터넷 사이에 어떤 종류의 터널이 있습니까? 내가 묻는 이유는 경로에 터널이 있고 누군가가 경로 MTU 발견을 방해하는 모든 ICMP를 차단했을 때 발생하는 일종의 소리처럼 들리기 때문입니다.
GeorgeB

또한, 고양이 / proc 디렉토리 / sys 인 / 그물 /의 IPv4 / tcp_mtu_probing의 출력 무엇인가
GeorgeB

답변:


6

Nginx에서 제공 한 로그를 기준으로 서버와 사용자 간의 연결이 불안정하거나 느려 보입니다. traceroute서버에서 클라이언트 IP 주소 또는 게이트웨이로 시도 하십시오. 또한 ping패킷 손실률과 응답 시간을 확인하기 위해 오랫동안 클라이언트 IP 주소. MTU가이 문제의 또 다른 원인 일 수 있습니다. MTU = 1500 (Mac :)으로 클라이언트에 연결할 수 있는지 테스트하십시오 ping -D -s 1472 xx.xx.xx.xx.

BTW : 서버 또는 클라이언트가 중국에 상주하는 경우이 문제는 대개 귀하의 잘못이 아닙니다. GFW는 의도적으로 국제 연결 품질을 악화시키기 위해 국경 사이의 패킷을 임의로 버리는 것으로 알려져 있습니다.


참고로, GFW = 중국의 위대한 방화벽.
로샨

0

해당 의견에서 추측 한 것처럼 사용자 오류 일 가능성이 있으며 의도적이든 아니든 연결을 닫고 있습니다. 문제를 안정적으로 재현하십시오. 다른 곳에서 발생하는 것을 배제하고 해당 위치 만있는 경우에는 문제를 해결해야합니다. 다른 브라우저 / 컴퓨터에서 시도한 다음 네트워크 안정성을 테스트하십시오.


0

이 로그 항목은 OpenVAS와 같은 도구를 사용하여 서버를 검색 할 때 표시되는 항목과 유사합니다. 이러한 도구는 연결이 잘못되거나 느리게 작동하거나 제대로 작동하지 않습니다. nginx는 일부 연결이 제대로 재생되지 않았다고보고합니다. 모든 트래픽이 동일한 소스에서 왔고 빠르며 액세스 로그에 일치하는 다른 합법적 인 요청이없는 경우 봇 스캐너 종류 일 가능성이 높습니다.

또한이 스캐너는 응용 프로그램을로드 할 때 다른 합법적 인 트래픽이 느려질 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.