서버 응답이 중간에 끊어지다

서버 응답이 중간에 끊어지다

저는 json 응답을 반환하는 REST API를 가지고 있습니다.때때로(그리고 완전히 랜덤으로 보이는) json 반응이 중간에 끊어질 수 있습니다.따라서 반환된 json 문자열은 다음과 같습니다.

...route_short_name":"135","route_long_name":"Secte // end of response

반환되는 json 문자열에 따라 컷오프 포인트가 계속 바뀌기 때문에 인코딩 문제는 아닌 것 같습니다.컷오프가 발생하는 응답 사이즈도 특정하지 않았습니다(65kb가 컷오프를 하지 않는 반면 40kbs는 컷오프를 하지 않는 것을 보았습니다).

컷오프가 발생했을 때 응답 헤더를 확인합니다.

{
    "Cache-Control" = "must-revalidate, private, max-age=0";
    Connection = "keep-alive";
    "Content-Type" = "application/json; charset=utf-8";
    Date = "Fri, 11 May 2012 19:58:36 GMT";
    Etag = "\"f36e55529c131f9c043b01e965e5f291\"";
    Server = "nginx/1.0.14";
    "Transfer-Encoding" = Identity;
    "X-Rack-Cache" = miss;
    "X-Runtime" = "0.739158";
    "X-UA-Compatible" = "IE=Edge,chrome=1";
}

나도 기억이 안 나.누구라도 있나요?

저도 같은 문제가 있었습니다.

Nginx가 Fast CGI 백엔드에서 일부 응답을 끊었습니다.예를 들어 PhpMyAdmin에서 적절한 SQL 백업을 생성할 수 없습니다.로그를 확인해 보니 다음과 같습니다.

2012/10/15 02:28:14 [crit] 16443#0: *14534527 open() "/usr/local/nginx/fastcgi_dism/4/81/0000004814"가 업스트림, 클라이언트:*, 서버:, 요청: "POST/HTTP/1.1"을 읽는 동안 실패했습니다.

을 고치기 내가 해야 할 은 적절한 이었다./usr/local/nginx/fastcgi_temp「」를 참조해 주세요.client_body_temp

고정!

대단히 감사합니다.당신의 질의응답은 저를 올바른 방향으로 이끌었습니다.

(nginx)를 했다.error.log다음 파일을 찾았습니다.

13870 open() "/var/lib/nginx/tmp/proxy/9/00/0000000009" failed (13: Permission denied) while reading upstream...

가 응답 것 .nginx looks 、 in （ 을로 looks ） 。응답 크기가 다음 값을 초과할 때만 해당됩니다.proxy_buffers(64비트 플랫폼에서는 디폴트로 64kb).결국 버그는 내 요청 응답 크기에 연결되었습니다.

i i i i i i i i i setting setting setting my my my my로 문제를 해결했습니다.proxy_buffering로로 합니다.off 파일에서 "nginx config "를 upping하는 proxy_buffers이치

nginx 버퍼의 용도는 아직 확실하지 않습니다.누가 그걸 더해주면 고맙겠다.버퍼링을 해제하는 것은 완전히 나쁜 생각입니까?

저도 서버에서 응답을 끊는 것에 대해 비슷한 문제가 있었습니다.

는 응답을 반환하기 합니다.header('Content-type: application/json');

같은 에는 ★★★★★★★★★★★★★★★★★★★★★★★.gzip을 사용하다

나는 그것을 특정함으로써 해결 방법을gzip_typesnginx.conf "" 추가application/json gzip:

gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript application/json;
gzip on;

inode가 부족할 수 있으므로 NginX가 fastcgi_temp 디렉토리를 올바르게 사용할 수 없습니다.

★★를 해 보세요.df -i 가능한 %node 빈 inode 、 % % % % % % % 。

★★를 해 보세요.find /tmp -mtime 10 것을 확인할 수 . (10일 이내)

아니면 파일이 너무 많은 다른 디렉토리일 수도 있습니다.예를 들어 /home/www-data/example.com로 이동하여 파일을 카운트합니다.

find . -print | wc -l

질문과 훌륭한 답변 덕분에 많은 시간을 절약할 수 있었습니다.결국 클레멘트와 샘의 답변이 나의 문제를 해결하는 데 도움이 되었기 때문에 크레딧은 그들에게 돌아간다.

토픽에 , 이 토픽을 사용하지 않도록 설정하는 되지 않는 것 .proxy_buffering클라이언트(시스템 사용자)의 인터넷 연결이 불량할 경우 서버가 정지될 수 있습니다.

나는 이 토론이 더 많은 것을 이해하는 데 매우 유용하다고 생각했다.프란시스 데일리의 사례는 나에게 매우 분명했다.

전체 프로세스를 일련의 프로세스로 생각하는 것이 더 쉬울 수 있습니다.

웹 브라우저는 1MB/s 링크를 통해 nginx와 통신합니다.nginx는 100MB/s 링크를 통해 업스트림서버와 통신합니다.업스트림서버는 100MB의 콘텐츠를 nginx에 반환하고 nginx는 100MB의 콘텐츠를 웹 브라우저에 반환합니다.

proxy_buffering을 켜면 nginx는 100MB 전체를 유지할 수 있기 때문에 nginx-upstream 접속은 1초 후에 닫히고 nginx는 웹 브라우저에 콘텐츠를 전송하는데 100초를 소비할 수 있습니다.

proxy_buffering이 꺼진 경우 nginx는 콘텐츠를 웹 브라우저로 전송할 수 있는 레이트와 동일한 레이트로 업스트림에서 콘텐츠를 가져올 수 있습니다.

웹 브라우저는 그 차이를 신경 쓰지 않습니다. 전체 콘텐츠를 가져오려면 여전히 100초가 걸립니다.

nginx는 그 차이에 크게 신경 쓰지 않는다.- 콘텐츠를 브라우저에 공급하려면 아직 100초가 걸리지만 업스트림으로의 접속을 99초 더 유지해야 한다.

업스트림에서는 그 차이에 관심이 있습니다.실제로 1초 걸렸을 가능성이 있는 것은 100초입니다.추가 99초 동안 업스트림서버는 다른 요구를 처리하지 않습니다.

보통: nginx-upstream 링크는 browser-nginx 링크보다 빠르고 업스트림은 nginx보다 "헤비웨이트"이기 때문에 업스트림은 가능한 한 빨리 처리를 끝내도록 하는 것이 현명합니다.

우리도 비슷한 문제가 있었어.이 문제는 REST 서버(DropWizard)에서 SO_LINGER가 활성화되어 있기 때문에 발생했습니다.로드 상태에서 DropWizard는 버퍼를 플러시하기 전에 NGINX의 연결을 끊었습니다.JSON은 8kb를 넘고 프론트 엔드는 그것을 잘립니다.

저도 이런 문제가 있었습니다.JSON클라이언트 측 해석에 장애가 있거나 응답이 끊겼거나 더 나쁘거나 응답이 오래되어 랜덤메모리 버퍼에서 읽혀졌습니다.

몇 가지 가이드– Nginx 및 Nginx에서 POST를 통한 스태틱콘텐츠 서비스: Nginx가 심플한 서비스를 제공하도록 설정하면서 POST를 사용하는 경우 "405 Not Allowed"로 수정합니다.JSON파일.

제 경우, 다음을 사용해야 했습니다.

max_ranges 0;

nginx가 추가될 때 브라우저가 웃긴 아이디어를 얻지 않도록 하기 위해Accept-Ranges: bytes응답 헤더) 및

sendfile off;

내 안에서server정적 파일에 서비스를 제공하는 프록시에 대한 차단입니다.에 추가하다location마침내 발견자에게 도움이 되는 블록JSON파일은 도움이 되지 않았다.

정전기 서빙용 또 하나의 프로팁JSONs는 응답 유형도 잊지 않습니다.

charset_types application/json;
default_type application/json;
charset utf-8;

다른 검색에서는 폴더 권한 문제가 발생하였습니다.nginx는 동적 페이지의 끝을 잘라내고 캐시하거나 프록시 버퍼링 문제를 발생시킵니다.nginx를 통해 청크 요청을 받는 것은 제 경우는 아니었습니다.

언급URL : https://stackoverflow.com/questions/10557927/server-response-gets-cut-off-half-way-through