IT Share you

HTTP 상태 504

shareyou 2020. 11. 8. 11:35
반응형

HTTP 상태 504


win32 (c #) 앱이 웹 서비스를 호출 할 때 다음 오류가 발생합니다.

The request failed with HTTP status 504: Gateway timeout server response timeout.

업스트림 요청이 적시에 응답을받지 못하기 때문인 것 같습니다.

하지만 내 질문은 이것입니까? 데이터를 처리하는 데 더 많은 시간을 허용하기 위해 win32 애플리케이션에서 app.config 설정을 변경하려면 어떻게해야합니까? ws를 호스팅하는 웹 서비스 및 IIS가 확장 된 시간으로 설정되기 때문에 내 앱 설정에서 이러한 변경을 수행해야한다고 가정합니다.

답변을 기다리며 미리 감사드립니다.

스콧


당신은 할 수 없습니다. 문제는 앱이 참을성이없고 시간이 초과되었다는 것이 아닙니다. 문제는 중간 프록시가 참을성이없고 시간이 초과된다는 것입니다. "서버가 게이트웨이 또는 프록시 역할을하는 동안 URI에 지정된 업스트림 서버로부터 적시에 응답을받지 못했습니다." ( http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.5 ) 원본 서버에 일종의 문제가 있음을 나타내므로 전달 된 요청에 빠르게 응답하지 않습니다.

가능한 해결책, 어느 것도 당신을 행복하게 만들지 않습니다.

  • 프록시의 시간 초과 값을 늘립니다 (사용자가 제어하는 ​​경우).
  • 다른 서버에 요청 (동일한 데이터를 가진 다른 서버가있는 경우)
  • 한 번에 더 적은 데이터를 요청하도록 (가능한 경우) 다르게 요청하십시오.
  • 서버에 문제가 없으면 다시 시도하십시오.

CheckUpDown에는 504 오류에 대한 멋진 설명이 있습니다 .

서버 (반드시 웹 서버 일 필요는 없음)는 요청 된 URL에 액세스하기 위해 클라이언트 (예 : 웹 브라우저 또는 CheckUpDown 로봇)의 요청을 이행하는 게이트웨이 또는 프록시 역할을합니다. 이 서버는 HTTP 요청을 처리하기 위해 액세스 한 업스트림 서버로부터 적시에 응답을받지 못했습니다.

이는 일반적으로 업스트림 서버와 게이트웨이 / 프록시가 데이터 교환 프로토콜에 동의하지 않는 것이 아니라 업스트림 서버가 다운되었음을 의미합니다 (게이트웨이 / 프록시에 대한 응답 없음).

이 문제는 전적으로 웹 서버를 포함한 백엔드 컴퓨터 간의 느린 IP 통신 때문입니다. 웹 서버를 호스팅하는 사이트에서 네트워크를 설정 한 사람 만이이 문제를 해결할 수 있습니다.


프록시 서버 A (예 : nginx)에 액세스하고 서버 A가 요청을 다른 서버 B (예 : tomcat)로 전달한다고 가정합니다.

이 프로세스가 오랫동안 계속되면 (프록시 서버 읽기 시간 초과 설정 이상) A는 여전히 B의 완료된 응답을받지 못했습니다. 발생합니다.

nginx의 경우 proxy_read_timeout (in location) 속성을 구성하여 문제를 해결할 수 있지만 값을 너무 높게 설정하면 일반적으로 좋은 생각이 아닙니다. 이것은 실제 오류를 숨길 수 있습니다.이 문제를 실제로 해결하려면 디자인을 개선하는 것이 좋습니다.


ASP.Net 5 (현재 ASP.Net Core v1로 알려짐)를 사용하는 경우 호스팅하는 각 사이트의 project.json "명령"섹션에서 Kestrel 프록시 수신 대기 포트가 사이트간에 다른지 확인하십시오. 그렇지 않으면 한 사이트가 작동하지만 다른 하나는 504 게이트웨이 시간 초과를 반환합니다.

 "commands": {
    "web": "Microsoft.AspNet.Server.Kestrel --server.urls http://localhost:5090"
  },

이 오류와 관련하여 내가 관찰 한 한 가지는 서버의 첫 번째 응답에만 표시되며 http의 경우 핸드 셰이크 응답이어야합니다. 서버에서 게이트웨이로 즉시 응답이 전송되면 주 응답 후 시간이 걸리면 오류가 발생하지 않습니다. 여기서 핵심은 서버의 요청에 대한 첫 번째 응답이 빨라야한다는 것입니다.


나에게 504를주는 또 다른 문제가 있습니다. 꽤 멀지 만 Google 직원과 후손을 위해 여기에 쓸 것입니다 ...

다른 도메인 (Active Directory)에서 호스팅되는 IIS 호스팅 웹 서비스를 호출하는 클라이언트가 있습니다. 클라이언트 도메인과 웹 서비스가 호스팅되는 도메인간에 완전한 신뢰가 없습니다. 이 두 도메인 간의 선택적 신뢰와 관련된 많은 문제 중 하나는 Kerberos가 하나에서 다른 도메인으로 호출 할 때 작동하지 않는다는 것입니다.

제 경우에는 SPN이 등록 된 것을 알게 된 다른 도메인의 서비스를 호출하려고했습니다. 다음과 같이 : http / myurl.test.local (예제)

이로 인해 호출이 NTLM으로 돌아가도록하는 대신 Kerberos를 사용하도록 강제하고 이로 인해 호출 서버에서 405가 반환되었습니다.

spn을 제거하고 호출이 NTLM으로 돌아가도록 허용하면 정상적으로 작동합니다.

내가 말했듯이 ... 대부분의 조직은 두 도메인 사이에 이러한 선택적 신뢰를 가지지 않기 때문에 이것은 당신이 마주 칠 가능성이있는 것이 아닙니다 ... 그러나 그것은 504를 제공하고 나에게 (더 많은) 회색 머리카락을 유발했습니다. .

참고 URL : https://stackoverflow.com/questions/261536/http-status-504

반응형