WordPress 사이트에서 504 게이트웨이 시간 초과 오류를 수정하는 방법

504 게이트웨이 시간 초과 오류는 웹 사이트 소유자와 사이트 방문자가 직면하는 가장 일반적인 HTTP 5xx 오류 중 하나입니다. 많은 WordPress 블로그 및 전자 상거래 플랫폼에서 이와 같은 서버 오류를 수정하는 방법을 아는 것은 힘들게 번 방문자가 경쟁 사이트로 이동하지 않도록 하는 데 매우 중요합니다.

504 게이트웨이 시간 초과 오류는 발생한 이유를 알려주지 않으므로 서버 시간 초과의 원인을 정확히 찾아내기 어렵습니다. 이 기사는 그것을 자세히 이해하고 원인을 진단하고 수정하는 방법을 배우는 데 도움이 될 것입니다.

게시물에 언급된 다양한 솔루션을 모두 시도한 후에는 사이트가 즉시 가동되고 실행될 것입니다.

흥미롭게 들립니까? 뛰어들자!

비디오 버전을 보고 싶으십니까?

504 게이트웨이 시간 초과 오류란 무엇입니까?

브라우저에서 웹사이트를 방문할 때마다 브라우저는 해당 사이트가 호스팅되는 웹 서버에 요청을 보냅니다. 서버는 요청을 처리하고 요청된 리소스로 응답합니다.

서버 응답에는 브라우저에 응답 상태를 나타내는 많은 HTTP 상태 코드 중 하나가 포함됩니다. 그러나 이러한 모든 HTTP 상태 코드가 오류인 것은 아닙니다. 예를 들어, 200 OK 상태 코드는 서버가 요청을 성공적으로 처리했으며 "Everything is OK"를 의미합니다.

HTTP 상태 코드의 5xx 클래스는 서버에 문제가 있음을 나타내며 서버는 이를 인식하고 클라이언트 요청을 수행할 수 없습니다. 결과적으로 서버 오류 5xx 상태 코드라고도 합니다.

공식적으로 5xx 클래스(500, 501, 502, 503, 504)에 5개의 상태 코드가 지정됩니다. 비공식 코드도 많이 볼 수 있습니다(506, 507, 509, 520 등).

IETF(Internet Engineering Task Force)는 504 게이트웨이 시간 초과 오류를 다음과 같이 정의합니다.

504(게이트웨이 시간 초과) 상태 코드는 서버가 게이트웨이 또는 프록시 역할을 하는 동안 요청을 완료하기 위해 액세스해야 하는 업스트림 서버로부터 적시에 응답을 받지 못했음을 나타냅니다.

더 단순화하기 위해 이 오류는 두 개의 서버가 요청 처리에 관여할 때 발생합니다. 첫 번째 서버(일반적으로 주 서버)가 시간 초과되어 두 번째 서버(업스트림 서버)의 응답을 기다립니다.

504 게이트웨이 시간 초과 오류는 다양한 형태로 나타납니다. 다음은 일반적으로 표시되는 몇 가지 방법입니다.

504 게이트웨이 시간 초과 오류는 502 잘못된 게이트웨이 오류와 유사하며, 이는 첫 번째 서버가 두 번째 서버(업스트림 서버)로부터 잘못된 응답을 수신했음을 나타냅니다.

504 게이트웨이 시간 초과 오류의 변형

브라우저는 다른 오류와 마찬가지로 내부에 504 게이트웨이 시간 초과 오류를 표시합니다. 다양한 운영체제, 웹 서버, 브라우저, 사용자 에이전트가 있기 때문에 여러 가지로 나타날 수 있습니다.

다음은 실행할 수 있는 몇 가지 일반적인 504 오류 메시지 변형입니다.

• 504 게이트웨이 시간 초과
• 504 게이트웨이 시간 초과 NGINX
• NGINX 504 게이트웨이 시간 초과
• 게이트웨이 시간 초과 오류
• 오류 504
• HTTP 오류 504
• HTTP 오류 504 - 게이트웨이 시간 초과
• HTTP 504
• 504 오류
• 게이트웨이 시간 초과(504)
• 이 페이지가 작동하지 않습니다 — 도메인이 응답하는 데 너무 오래 걸림
• 504 게이트웨이 시간 초과 - 서버가 제 시간에 응답하지 않았습니다.
• 완료하는 데 너무 오래 걸려 페이지 요청이 취소되었습니다.
• 사이트 방문자: 요청을 처리하는 동안 문제가 발생했습니다. 몇 분 후에 다시 시도해 주세요.
• 사이트 소유자: 게이트웨이 시간 초과가 발생했습니다. 자세한 내용은 오류 로그를 방문해야 합니다.
• 빈 흰색 화면

위의 모든 오류 응답은 다르게 표현되었지만 동일한 504 게이트웨이 시간 초과 서버 오류를 가리킵니다.

웹 서버 및 웹 사이트는 504 게이트웨이 시간 초과 오류를 사용자에게 표시하는 방법을 사용자 지정할 수 있습니다. 그들 중 일부는 멋질 수 있습니다! 방문자의 실망을 잠재우기 위한 훌륭한 전술입니다.

504 게이트웨이 시간 초과 오류의 SEO 영향

모든 5xx 오류는 웹 페이지가 로드되지 않도록 하여 사용자 경험에 해롭습니다. 따라서 Google과 같은 검색 엔진은 이러한 오류를 심각하게 생각합니다. 오류가 오랫동안 지속되면 검색 엔진 결과에서 웹 페이지의 색인을 해제할 수도 있습니다.

예를 들어 Google 스파이더가 503 서비스를 사용할 수 없음 오류를 발견하면 대부분 사이트 유지 관리 모드를 활성화하는 데 사용되기 때문에 일시적인 문제라는 것을 이해할 것입니다. 따라서 나중에 다시 페이지 크롤링을 시도합니다.

504 게이트웨이 시간 초과 오류는 여러 가지 이유로 인해 발생할 수 있으므로 반드시 일시적인 것은 아닙니다. 사이트가 단 몇 분 동안 다운되고 스파이더가 1분에 여러 번 사이트를 크롤링하려는 경우 캐시에서 페이지를 제공하려고 시도합니다. 그들은 그것을 알아차리지도 못했을 것입니다.

그러나 사이트가 6시간 이상 다운된 경우 Google은 504 오류를 가능한 한 빨리 수정해야 하는 심각한 사이트 전체 문제로 간주합니다. 이는 SEO에 부정적인 영향을 미칠 수 있습니다.

Google Search Console은 웹사이트의 HTTP 5xx 오류를 모니터링하는 최고의 SEO 도구 중 하나입니다.

504 게이트웨이 시간 초과 오류의 원인

504 오류는 서버 간의 시간 초과로 인해 발생하므로 클라이언트의 장치나 인터넷 연결에 문제가 있는 것은 아닐 수 있습니다. 여기에는 장치와 연결도 포함됩니다.

504 게이트웨이 시간 초과 오류는 웹 서버가 다른 서버의 응답을 너무 오래 기다리며 "시간 초과"되었음을 나타냅니다. 이 시간 초과에는 여러 가지 이유가 있을 수 있습니다. 다른 서버가 제대로 작동하지 않거나 과부하가 걸리거나 다운되기 때문입니다.

다른 서버가 항상 외부일 필요는 없습니다(예: CDN, API 게이트웨이). 또한 주 웹 서버(예: 역방향 프록시 서버, 데이터베이스 서버) 내의 서버와 같은 엔터티일 수 있습니다.

504 게이트웨이 시간 초과 오류를 수정하는 방법

서버 구성, 호스팅 계획, 타사 플러그인 및 끌어들이는 트래픽과 같은 WordPress 사이트에 대한 정확한 세부 정보를 알지 못하면 504 게이트웨이 시간 초과 오류를 수정하는 것이 답답하고 압도적일 수 있습니다.

많은 변수가 관련되어 있으므로 매우 드문 클라이언트 측 문제를 수정한 다음 서버 측 문제를 수정하는 방향으로 이동하는 것이 좋습니다. 그들은 일반적으로 504 오류의 범인입니다.

웹페이지 새로고침 시도

504 게이트웨이 시간 초과 오류가 발생했을 때 가장 먼저 시도할 수 있는 것 중 하나는 몇 분 정도 기다렸다가 페이지를 새로고침하는 것입니다.

대부분의 브라우저에서 F5 키보드 단축키를 눌러 웹 페이지를 새로고침/다시 로드할 수 있습니다. 다시 로드하기 전에 페이지의 브라우저 캐시를 제거하려면 CTRL+F5 바로 가기 콤보를 대신 누를 수 있습니다.

그 동안 다른 브라우저에서 사이트를 로드하여 문제가 되지 않도록 할 수도 있습니다. 대부분의 504 오류는 일시적으로 과부하된 서버로 인해 발생하므로 이 솔루션을 사용하면 사이트를 바로 복구할 수 있습니다.

사이트를 기다렸다가 새로고침해도 504 오류 문제가 해결되지 않으면 사이트가 모두 다운되었는지 아니면 나만 다운되었는지 확인할 수 있습니다. 사이트 가동 중지 시간을 테스트하는 데 유용한 두 가지 온라인 도구는 Down for Everyone 또는 Just Me와 Is It Down Right Now?입니다.

네트워크 장치 재부팅

때때로 모뎀이나 라우터와 같은 네트워크 장치의 문제로 인해 504 게이트웨이 시간 초과 오류가 발생할 수 있습니다. 이러한 장치를 재부팅하면 문제를 해결하는 데 도움이 될 수 있습니다.

이러한 모든 네트워킹 장치를 순서에 관계없이 끌 수 있지만 다시 켜는 순서가 중요합니다. 일반적으로 인터넷 서비스 제공업체에서 기본 클라이언트 장치로의 연결 순서에 따라 "외부에서" 이러한 장치를 켭니다.

프록시 설정 확인

프록시 서버는 장치와 인터넷 사이에 있습니다. 웹사이트와 웹서버(예: VPN 사용)에서 개인 정보(예: 장치 위치)를 숨겨 온라인 개인 정보를 강화하는 데 주로 사용됩니다.

프록시 서버에서 504 오류가 발생하는 경우는 드물지만 잘못된 프록시 서버 설정이 원인일 수 있습니다. 프록시 서버를 비활성화하고 웹 페이지를 새로고침하여 오류가 수정되는지 확인할 수 있습니다.

대부분의 클라이언트는 프록시 서비스를 사용하지 않으므로 프록시 서버를 사용하지 않는다고 확신하는 경우 이 단계를 건너뛸 수 있습니다. 하지만 본인도 모르는 사이에 설정했을 수 있습니다. 이 원인을 배제하기 위해 장치 및 브라우저의 프록시 설정을 확인하는 것이 좋습니다.

DNS 문제

504 게이트웨이 시간 초과 오류는 서버 측이나 클라이언트 측(또는 둘 다)의 DNS 문제로 인해 발생할 수도 있습니다.

서버 측 DNS 문제의 가장 가능성 있는 이유는 FQDN(정규화된 도메인 이름)이 올바른 IP 주소를 확인 하지 않거나 DNS 서버가 응답하지 않기 때문 입니다. 일반적으로 이것은 WordPress 사이트를 새 서버나 호스트로 마이그레이션했을 때 발생합니다. 따라서 도메인의 DNS 레코드가 완전히 전파될 때까지 기다리는 것이 중요하며 최대 24시간이 소요될 수 있습니다.

whatsmydns.net DNS Checker 또는 DNSMap과 같은 무료 도구를 사용하여 DNS가 전 세계적으로 전파되었는지 확인할 수 있습니다.

클라이언트 측 DNS 문제를 해결하기 위해 로컬 DNS 캐시를 플러시할 수 있습니다. 운영 체제에서 DNS 캐시를 플러시한다는 점을 제외하고는 브라우저 캐시를 지우는 것과 같습니다.

Windows를 사용하는 경우 명령 프롬프트를 열고 다음 지시문을 입력하여 DNS 캐시를 플러시할 수 있습니다.

 ipconfig /flushdns

"DNS 확인자 캐시를 성공적으로 플러시했습니다."가 표시되어야 합니다. 작동했다면 메시지.

최신 macOS 버전의 경우 터미널을 열고 다음 명령을 실행할 수 있습니다.

 sudo killall -HUP mDNSResponder

프로세스가 완료되면 macOS에 알림이 표시되지 않지만 사용자 지정 메시지와 함께 명령을 추가하여 알림을 변경할 수 있습니다.

 sudo killall -HUP mDNSResponder; DNS Cache was cleared successfully

이전 macOS 버전을 사용하는 경우 입력해야 하는 명령은 실행 중인 macOS 버전에 따라 다릅니다. 자세한 내용은 Kinsta의 심층 플러시 DNS 자습서에서 macOS 섹션을 참조할 수 있습니다.

Linux 운영 체제를 사용하는 경우 Linux에서도 터미널을 명령줄 인터페이스로 사용하므로 프로세스는 macOS와 매우 유사합니다. 많은 Linux 배포판이 있기 때문에 실행해야 하는 정확한 명령은 배포판마다 다를 수 있습니다. 자세한 내용은 Kinsta의 가이드를 확인하세요.

마지막으로 클라이언트 측 DNS 서버를 일시적으로 변경할 수 있습니다. 기본적으로 ISP는 DNS 서버를 자동으로 할당합니다. 그러나 일시적으로 공용 DNS IP로 변경할 수 있습니다.

사용해 볼 수 있는 신뢰할 수 있는 DNS 서버로는 Google Public DNS, Cloudflare 1.1.1.1, Quad9 DNS 및 Cisco OpenDNS가 있습니다.

사이트의 CDN을 일시적으로 비활성화

때로는 CDN(콘텐츠 전송 네트워크)에 문제가 있을 수도 있습니다. 사이트의 원본 서버에 연결할 수 없는 경우 대부분의 CDN은 캐시에서 전체 웹 페이지를 제공하려고 합니다.

그러나 대부분의 CDN은 대부분의 사이트(예: WordPress 관리 대시보드)에서 동적 자산을 캐시하는 것이 복잡하기 때문에 기본적으로 이 기능을 활성화하지 않습니다.

이 문제를 해결하는 간단한 방법은 CDN을 일시적으로 비활성화하는 것입니다. 예를 들어 무료 CDN Enabler WordPress 플러그인을 사용하여 사이트 자산을 CDN URL에 연결하는 경우 플러그인을 비활성화하고 사이트 다시 로드를 테스트할 수 있습니다.

CDN에 연결하는 데 사용할 수 있는 다른 플러그인(예: WP Rocket, Breeze, W3 Total Cache)을 사용할 때도 마찬가지입니다.

사이트의 관리 대시보드에 액세스할 수 없는 경우 플러그인의 폴더 이름을 변경하여 SFTP를 통해 플러그인을 비활성화할 수 있습니다.

전체 프록시 서비스를 제공하는 Cloudflare 또는 Sucuri와 같은 CDN에는 에지 서버와 원본 서버 사이에 추가 방화벽이 있습니다. 따라서 HTTP 5xx 오류를 사용하는 동안 더 자주 발생할 수 있습니다. 대부분은 원본 서버에서 반환된 5xx 오류를 캐시하므로 문제를 쉽게 해결할 수 있습니다.

Cloudflare의 무료 요금제는 5xx 오류가 발생하기 쉽습니다. 불행히도, 그것은 완전한 프록시 서비스이기 때문에 그것을 비활성화하는 빠른 방법이 없습니다. 그러나 Cloudflare를 비난하기 전에 Cloudflare는 504 게이트웨이 시간 초과 오류의 두 가지 변형을 보여줍니다.

504 Cloudflare에서 게이트웨이 시간 초과(변형 1)

Cloudflare는 사이트의 원본 서버가 표준 HTTP 504 응답으로 응답할 때 사용자 지정 504 게이트웨이 시간 초과 오류 화면을 표시합니다.

여기서 문제는 Cloudflare가 아닌 웹 서버에 있습니다. 아래에 언급된 다른 솔루션으로 문제를 해결하거나 호스팅 제공업체의 지원에 기술 지원을 문의할 수 있습니다.

504 Cloudflare에서 게이트웨이 시간 초과(변형 2)

Cloudflare에서 504 게이트웨이 시간 초과 오류가 발생하면 오류 화면에 현재 모든 Cloudflare 자산의 표준 서버 이름인 "cloudflare"가 표시됩니다. 일반적으로 오류 화면은 다음과 같이 나타납니다.

Cloudflare 자체가 응답하지 않기 때문에 여기에 Cloudflare 브랜드 오류 화면이 표시되지 않습니다.

Cloudflare는 이미 문제를 인식하고 있으며 이미 수정 작업을 진행 중일 가능성이 큽니다. Cloudflare 시스템 상태 웹 페이지를 확인하여 이를 확인할 수 있습니다. 또는 더 빠른 해결을 위해 Cloudflare 지원에 문의할 수 있습니다.

대용량 업로드로 인한 Cloudflare의 504 게이트웨이 시간 초과

사이트에 업로드하는 크기도 서버 시간 초과의 원인이 될 수 있습니다. Cloudflare는 업로드 파일 크기(HTTP POST 요청당)를 Free 및 Pro 계획 모두에서 100MB로 제한합니다.

문제는 호스트 측 또는 Cloudflare에 있을 수 있습니다. DNS 호스트 파일로 Cloudflare를 우회하고 업로드를 다시 시도하면 정확한 원인을 찾을 수 있습니다.

WordPress와 함께 Cloudflare를 사용하는 경우 무료 플러그인을 사용하고 캐싱에서 중요한 URL(예: WordPress 관리 대시보드)을 제외하는 것이 좋습니다. WordPress에 대한 Cloudflare 설정을 구성하는 방법에 대한 Kinsta의 자세한 게시물을 참조할 수 있습니다.

추천 자료: WordPress용 Cloudflare APO 설정 방법.

서버 문제(호스트에 확인)

서버 문제는 504 게이트웨이 시간 초과 오류가 발생하는 가장 일반적인 이유 중 하나입니다. 대부분의 WordPress 사이트는 Nginx 또는 Apache 웹 서버에서 호스팅되기 때문에 Nginx 또는 Apache는 무언가의 응답을 기다리고 있으며 시간이 초과됩니다.

많은 클라이언트가 다른 WordPress 호스트에서 직면하고 있는 바로 이 문제 때문에 Kinsta에 옵니다. 대화는 다음과 같이 진행됩니다.

우리는 200,000 이상의 조회수와 함께 매월 약 100,000명의 방문자를 확보하고 있습니다. 현재 ____에서 호스팅하고 있으며 서버 과부하로 인해 지속적으로 504 오류가 발생합니다. 나는 ____이(가) 문제를 처리하는 방식이 마음에 들지 않으며, 우리는 또한 우리가 곧 그들의 전용 계획으로 이동해야 한다는 조언을 받았는데, 이는 필요하지 않다고 생각합니다.

트래픽이 많은 전자 상거래 사이트는 캐시할 수 없는 많은 요청을 생성하므로 서버 과부하로 인해 504 오류가 발생하기 쉽습니다. 그러나 이 문제는 간단한 블로그를 포함한 모든 사이트에서 잘릴 수 있습니다. 많은 호스트가 문제를 해결하기 위해 상위 계층 계획으로 업그레이드하도록 요청할 것입니다. 이는 대부분의 경우 필요하지 않습니다.

Kinsta는 LXD 관리 호스트와 각 사이트에 대해 오케스트레이션된 LXC 소프트웨어 컨테이너를 사용합니다. 따라서 모든 WordPress 사이트는 실행에 필요한 모든 소프트웨어(Linux, Nginx, PHP, MySQL)에 액세스할 수 있는 자체 격리된 컨테이너에 보관됩니다. 리소스는 100% 비공개이며 다른 사이트, 심지어 귀하의 사이트와도 공유되지 않습니다.

공유 호스팅 계획을 제공하는 대부분의 WordPress 호스트에는 이 기능이 없습니다. 따라서 귀하와 동일한 서버에서 호스팅되는 트래픽이 많은 사이트는 귀하의 사이트에서도 504 오류를 발생시킬 수 있습니다.

Kinsta는 컨테이너에서 각 사이트를 격리하는 것 외에도 수천 개의 동시 연결을 쉽게 처리할 수 있도록 인프라를 설계했습니다. Kinsta는 원격 서버가 아닌 localhost에서 MySQL 데이터베이스를 호스팅합니다. 즉, 시스템 간에 대기 시간이 없으므로 쿼리가 더 빨라지고 시간 초과가 발생할 가능성이 줄어듭니다.

Kinsta로 마이그레이션하는 많은 클라이언트는 전체 로드 시간이 크게 감소합니다.

오버로드된 서버가 서버 시간 초과의 유일한 원인은 아닙니다. 504 오류에 대한 다른 많은 이유가 있을 수 있습니다.

느린 서버 인프라

WordPress 사이트를 호스팅하는 데 사용하는 서버에 로드를 처리할 리소스가 충분하지 않을 수 있습니다. 마치 10년 된 PC에서 현대적이고 그래픽 집약적인 비디오 게임을 하는 것과 같습니다.

서버는 웹 사이트를 제공하려고 하기만 하면 전화를 끊습니다. 이 문제에 대한 유일한 해결책은 더 나은 인프라를 갖춘 서버로 업그레이드하는 것입니다. 이러한 이유로 Kinsta의 가장 기본적인 WordPress 호스팅 계획조차도 중간 트래픽의 정적 사이트를 처리합니다.

더 많은 PHP 작업자 필요

PHP 작업자는 WordPress 사이트의 코드를 실행하는 데 사용됩니다. 매월 50,000명의 방문자가 방문하는 전자 상거래 사이트는 동일한 양의 트래픽을 가진 단순한 블로그보다 훨씬 더 많은 리소스가 필요합니다. 서버의 모든 PHP 작업자가 사용 중이면 대기열을 생성합니다.

대기열이 너무 커지면 서버가 이전 요청을 무시하므로 서버에서 504 게이트웨이 오류가 발생할 수 있습니다. PHP 작업자 수를 늘리는 것에 대해 호스트에게 요청할 수 있습니다. 이렇게 하면 사이트에서 동시에 여러 요청을 실행할 수 있습니다.

방화벽 문제

서버의 방화벽에 오류가 있거나 구성이 잘못되었을 수 있습니다. 아마도 몇 가지 규칙으로 인해 서버가 연결을 제대로 설정하지 못할 수 있습니다. 방화벽이 범인인지 확인하려면 서버의 오류 로그를 확인하십시오.

네트워크 연결 문제

프록시 서버와 웹 서버 간의 연결 문제로 인해 HTTP 요청에 대한 응답이 지연될 수 있습니다. 로드 밸런서를 사용하는 경우 네트워크 연결 문제도 있을 수 있습니다.

HTTP 시간 초과

HTTP 시간 초과는 웹 서버와 클라이언트 간의 연결이 너무 오랫동안 열려 있을 때 발생할 수 있습니다. WordPress 사이트에서 이것은 일반적으로 WordPress 가져오기를 실행할 때 발생합니다. 이 문제를 해결하는 한 가지 방법은 더 빠른 인터넷 연결로 전환하는 것입니다.

WP-CLI를 지원하는 도구를 사용하여 HTTP 연결을 완전히 우회하여 서버에서 직접 스크립트를 실행할 수도 있습니다. 예를 들어 wp import WP-CLI 명령을 사용하여 명령줄 인터페이스를 통해 직접 WordPress Importer 플러그인을 실행할 수 있습니다.

중요: 504 게이트웨이 시간 초과 오류는 503 서비스를 사용할 수 없음 오류 또는 502 잘못된 게이트웨이 오류와 유사합니다. 하지만 그들은 모두 다릅니다. Kinsta에서 504 오류가 발생하는 경우 지원 티켓을 열어 문제를 즉시 해결하세요.

사이트의 다운타임을 스스로 모니터링하려면 updown.io와 같은 도구를 사용할 수 있습니다. HTTP 요청을 보내 웹사이트의 상태(또는 모든 URL)를 주기적으로 확인합니다. 확인 주기는 15초에서 1시간까지 설정할 수 있습니다. 웹사이트가 올바르게 응답하지 않으면 이메일이나 SMS로 알려줍니다.

updown.io의 모든 계정에서 많은 양의 무료 크레딧을 받을 수 있지만 더 저렴한 대안을 찾고 있다면 WebGazer 또는 UptimeRobot을 확인할 수 있습니다. 이 두 도구는 모두 무료로 5분마다 사이트 가동 시간을 모니터링하는 데 도움이 됩니다. 그것은 대부분의 웹사이트 소유자에게 충분합니다.

웹사이트를 모니터링하면 웹사이트가 얼마나 자주 다운되는지 알 수 있습니다. 이는 공유 호스팅 공급자를 사용하는 경우 특히 유용합니다. 대부분의 관리되는 WordPress 호스트는 이를 자동으로 처리합니다. 따라서 항상 그들과 함께 가는 것이 좋습니다.

자세한 설명은 관리형 WordPress 호스팅의 중요성에 대한 Kinsta의 게시물을 확인하세요.

스팸, 봇 또는 DDoS 공격

악의적인 공격자는 너무 많거나 리소스를 많이 사용하는 요청을 보내 웹 서버를 크롤링할 수 있습니다. 사이트가 봇에 의해 스팸을 받거나 DDoS 공격을 받는 경우 서버에 과부하가 걸리고 많은 정품 사용자에게 504 게이트웨이 시간 초과 오류가 발생할 수 있습니다.

서버 트래픽 및 분석을 보고 사이트 트래픽에서 불규칙한 패턴을 발견할 수 있는지 확인할 수 있습니다. Kinsta를 사용하여 사이트를 호스팅하는 경우 MyKinsta Analytics 대시보드로 이동하여 이 데이터를 쉽게 볼 수 있습니다.

상위 클라이언트 IP를 확인하여 조사를 시작합니다. 누가 최대 요청 수를 생성하고 어디에서 생성하는지에 대한 아이디어를 제공합니다. 서버가 갑자기 엄청난 대역폭을 사용하거나 많은 트래픽을 끌어들이는 경우 이 보고서가 매우 유용할 것입니다.

다음으로 Cache Analysis 보고서를 확인할 수 있습니다. 여기에서 얼마나 많은 요청이 캐시를 우회하거나 누락되었는지 또는 캐시에서 제공되는지 확인할 수 있습니다. 성능 및 안정성을 위해 가능한 한 많은 요청을 캐시하고 싶지만 항상 이를 달성할 수 있는 것은 아닙니다.

예를 들어 WooCommerce 사이트는 장바구니 및 체크아웃 프로세스와 같은 기능에 대해 캐시할 수 없는 많은 요청을 생성합니다.

마지막으로 WordPress 보안 플러그인을 사용하여 걱정스러운 트래픽/IP를 찾아내고 차단하여 웹사이트의 보안을 강화할 수 있습니다. 호스트에게 특정 IP를 차단하도록 요청할 수도 있습니다.

공격의 길이와 규모에 따라 많은 공격자가 차단된 후 자신의 IP와 프록시 주소를 변경하므로 IP를 블랙리스트에 추가하는 끝없는 프로세스가 될 수 있습니다.

참고: Kinsta는 사이트 성능, 특히 스캔 기능에 큰 영향을 미칠 수 있으므로 클라이언트가 WordPress 보안 플러그인을 설치하는 것을 허용하지 않습니다. Kinsta는 Google Cloud Platform과 함께 부하 분산기를 사용하므로 차단 IP가 의도한 대로 작동하지 않을 수 있습니다.

Cloudflare 또는 Sucuri와 같은 전용 보안 솔루션을 사용하여 DDoS 공격 및 스팸봇으로부터 사이트를 보호할 수 있습니다. 자세한 내용은 WordPress 사이트에 Cloudflare를 설치하는 방법과 Sucuri가 DDoS 공격을 차단하는 데 도움이 된 방법에 대한 Kinsta의 기사를 확인할 수 있습니다.

손상된 WordPress 데이터베이스

때때로 504 게이트웨이 시간 초과 오류는 특히 WordPress 사이트에서 손상된 데이터베이스로 인해 발생할 수 있습니다. 일반적으로 이는 손상된 데이터베이스 테이블 또는 파일 때문입니다. 때로는 사이트 또는 데이터베이스 해킹과 같은 심각한 보안 문제로 인해 발생할 수도 있습니다.

손상된 WordPress 데이터베이스 복구는 문제에 따라 다릅니다. WP-DBManager와 같은 플러그인을 사용하면 데이터베이스 문제를 쉽게 진단하고 복구할 수 있습니다. 시작하려면 WordPress 데이터베이스 문제 복구에 대한 Kinsta의 자세한 연습을 읽는 것이 좋습니다.

사이트의 플러그인 및 테마 확인

대부분의 경우 타사 플러그인 및 테마는 504 오류를 일으키지 않습니다. 그러나 일반적으로 플러그인/테마에 의해 생성된 많은 캐시되지 않은 요청을 대기열에 넣어 서버 시간 초과를 유발할 수 있는 약간의 기회가 있습니다. 이것은 많은 서버의 PHP 작업자를 묶기 때문에 504 오류가 발생할 수 있습니다.

이 문제의 좋은 예는 WordPress 사이트에 전자상거래 기능을 추가하기 위해 설치된 플러그인인 WooCommerce입니다.

이 문제를 해결할 수 있는 가장 간단한 방법은 모든 플러그인을 비활성화하는 것입니다. 플러그인을 비활성화하면 데이터가 손실되지 않습니다.

관리 대시보드에 액세스할 수 있는 경우 플러그인 화면으로 이동하여 일괄 작업 메뉴에서 비활성화 를 선택하고 모든 플러그인에 체크 표시를 한 다음 적용 버튼을 누를 수 있습니다. 그러면 모든 플러그인이 비활성화됩니다.

관리 영역에 액세스할 수 없는 경우 앞에서 설명한 방법을 사용하여 SFTP를 통해 플러그인을 비활성화할 수 있습니다. 모든 플러그인을 일괄적으로 비활성화하려면 기본 플러그인 폴더 이름을 변경하기만 하면 됩니다.

모든 플러그인을 비활성화했으면 사이트가 제대로 로드되는지 확인하세요. 작동하는 경우 각 플러그인을 활성화하고 모든 플러그인을 활성화한 후 사이트를 테스트해야 합니다.

마지막으로 플러그인, 테마 및 WordPress 코어가 최신 버전인지 확인하십시오. 또한 서버에서 권장되는 PHP 버전을 실행하고 있는지 확인하십시오.

이것이 너무 부담스럽다고 생각되면 언제든지 호스트에게 도움을 요청할 수 있습니다. Kinsta는 Kinsta APM 및 기타 문제 해결 기술을 사용하여 클라이언트가 오류를 유발할 수 있는 플러그인, 쿼리 또는 스크립트의 범위를 좁힐 수 있도록 도와줍니다.

플러그인/테마의 비효율적인 쿼리 또는 잘못된 코드와 같은 최악의 시나리오에서는 WordPress 개발자를 불러와서 문제를 해결할 수 있습니다.

오류 로그 확인

오류 로그 보기는 WordPress 사이트의 504 오류 문제를 해결하고 디버깅할 때 매우 유용할 수 있습니다. 이렇게 하면 특히 사이트의 까다로운 플러그인으로 인해 발생한 문제인 경우 사이트의 문제 범위를 빠르게 좁힐 수 있습니다.

Kinsta 고객인 경우 MyKinsta 대시보드의 로그 뷰어에서 오류를 쉽게 확인할 수 있습니다.

호스트에 로깅 도구가 없는 경우 wp-config.php 파일에 다음 코드를 추가하여 WordPress 디버그 모드를 활성화할 수 있습니다.

 define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );

WP_DEBUG 상수는 WordPress 디버그 모드를 활성화하거나 비활성화합니다. 기능을 확장할 수 있는 두 개의 선택적 동반자 상수가 있습니다. WP_DEBUG_LOG 상수는 모든 오류가 /wp-content/ 디렉토리 내의 debug.log 파일에 저장되도록 지시합니다. 이 파일이 표시되지 않으면 언제든지 만들 수 있습니다.

WP_DEBUG_DISPLAY 상수는 디버그 로그가 HTML 페이지에 표시되는지 여부를 제어합니다. 이를 false로 설정하면 모든 오류가 숨겨 WP_DEBUG_LOG 도 true로 정의했기 때문에 나중에 오류를 검토할 수 있습니다.

중요: Kinsta 환경에서 WP_DEBUG를 활성화한 경우 MyKinsta 대시보드의 error.log 가 아니라 모든 오류를 debug.log 파일로 라우팅합니다.

SFTP를 통해 원시 WordPress 오류 로그 파일을 다운로드할 수도 있습니다. 일반적으로 "logs"라는 폴더의 서버 루트 디렉터리에서 오류 로그를 찾을 수 있습니다.

Kinsta 사용자는 MyKinsta 대시보드에서 WordPress 디버그 모드를 활성화할 수도 있습니다. 그렇게 하려면 사이트 > 도구 > WordPress 디버깅 으로 이동하고 활성화 버튼을 클릭합니다. 이렇게 하면 SSH 또는 SFTP를 통해 디버그 모드를 활성화하지 않고도 PHP 오류 및 알림을 볼 수 있습니다.

마지막으로 서버 로그 파일을 확인할 수 있습니다. WordPress 사이트를 호스팅하는 데 사용하는 서버에 따라 일반적으로 다음 위치에서 찾을 수 있습니다.

• 아파치: /var/log/apache2/error.log/
• Nginx: /var/log/nginx/error.log/

자세한 내용은 Apache 또는 Nginx의 로깅 관련 문서를 참조할 수 있습니다.

Apache 또는 Nginx 설정을 올바르게 구성

서버 구성 파일을 편집하여 특정 지시문에 대한 리소스 제한을 늘릴 수 있습니다. 이렇게 하면 504 게이트웨이 시간 초과 오류를 해결하는 데 도움이 될 수 있습니다.

Apache 웹서버용

먼저 httpd.conf 에 다음 코드를 추가합니다.

 TimeOut 600

이 설정은 서버가 네트워크 시간 초과 문제로 표시하기 전에 특정 요청을 기다리는 시간을 정의합니다. 기본값은 60초(Apache 2.4 버전)입니다.

이 지시문은 .htaccess 파일이 아니라 httpd.conf 파일에만 추가할 수 있습니다. 대부분의 공유 호스팅 공급자는 httpd.conf 파일 수정을 허용하지 않으므로 대신 .htaccess 파일에서 LimitRequestBody 지시문 값을 늘릴 수 있습니다.

그런 다음 php.ini 파일에 다음 줄을 추가합니다.

 max_execution_time 300

PHP의 max_execution_time 지시문의 기본값은 30초입니다. 이 값을 늘리면 사이트의 PHP 스크립트를 더 오래 실행할 수 있습니다.

Nginx 웹서버용

Nginx + FastCGI Process Manager(PHP-FPM)에서 WordPress 사이트를 실행하거나 Nginx를 Apache용 역방향 프록시로 사용하는 경우 서버 설정을 조정하여 504 게이트웨이 시간 초과 오류를 방지할 수 있습니다.

Nginx + FastCGI(PHP-FPM)에서 504 게이트웨이 시간 초과 오류

먼저 PHP-FPM 풀 구성 파일을 편집해야 합니다. Nginx 서버의 /etc/php7.4/fpm/pool.d/www.conf 위치에서 찾을 수 있습니다(정확한 경로는 PHP 버전에 따라 다를 수 있음). 또는 터미널에서 다음 명령을 실행하여 PHP-FPM 풀 구성 파일을 편집할 수 있습니다.

 sudo nano /etc/php/7.2/fpm/pool.d/www.conf

다음으로 다음 지시문을 설정합니다.

 request_terminate_timeout = 300

그런 다음 php.ini 파일을 편집해야 합니다. /etc/php.ini 에서 찾을 수 있습니다. 파일을 열고 max_execution_time 지시문의 값을 300초로 추가/변경합니다.

 max_execution_time = 300

마지막으로 nginx.conf 파일의 위치 블록에 다음 코드를 추가합니다.

 location ~ .php$ { ... fastcgi_read_timeout 300; }

변경 사항을 적용하려면 Nginx 및 PHP-FPM을 다시 로드하세요.

 sudo service nginx reload sudo service php7.4-fpm reload

PHP-FPM을 다시 로드하는 정확한 코드는 서버에 설치된 PHP 버전에 따라 다릅니다. 사이트를 테스트하여 문제가 해결되었는지 확인하십시오.

Nginx 프록시에서 504 게이트웨이 시간 초과 오류

Nginx를 Apache용 역방향 프록시 서버로 사용하는 경우 nginx.conf 파일에 다음 지시문을 추가하여 서버 시간 초과에 대해 관대하게 만들 수 있습니다.

 proxy_connect_timeout 600; proxy_send_timeout 600; proxy_read_timeout 600; send_timeout 600;

변경한 후 Nginx를 다시 로드하는 것을 잊지 마십시오.

sudo service nginx reload

504 게이트웨이 시간 초과와 같은 기타 HTTP 오류

이 기사의 앞부분에서 언급했듯이 다른 많은 HTTP 5xx 오류는 504 게이트웨이 시간 초과 오류와 같습니다. 모두 서버 측에서 발생하기 때문입니다. 이러한 오류에는 다음이 포함됩니다.

• 500 내부 서버 오류
• 501 구현되지 않음 오류
• 502 잘못된 게이트웨이 오류
• 503 서비스를 사용할 수 없음 오류

404 Not Found 오류와 같은 클라이언트 측 문제로 인해 발생하는 기타 HTTP 오류도 504 오류와 유사합니다. 자세한 내용은 Kinsta의 상세 가이드 및 HTTP 상태 코드 목록을 참조하세요.

요약

WordPress 사이트는 여러 가지 이유로 인해 504 게이트웨이 시간 초과 오류의 영향을 받을 수 있습니다. 이 문서에서는 모든 문제를 해결하는 방법을 배웠습니다. 일반적으로 이러한 오류는 서버 측 문제로 인해 발생하며 이 경우 호스트에 연락하여 신속하게 해결할 수 있습니다.

그러나 이 오류는 타사 플러그인, 테마, 서비스, 비효율적인 데이터베이스 쿼리 또는 이들 중 둘 이상의 조합으로 인해 발생할 수 있음을 이해해야 합니다. 서버의 리소스(예: PHP 작업자)를 최대한 활용하는 경우 성능을 위해 사이트를 최적화하는 것이 좋습니다.

여전히 웹 사이트가 시간 초과되는 경우 호스팅 계획이나 PHP 작업자 수를 업그레이드해야 할 수 있습니다. 이 문서에 설명된 다른 솔루션을 모두 사용한 후에만 이 옵션을 고려하는 것이 좋습니다.

단순한 정적 사이트에서 복잡한 전자 상거래 및 회원 사이트에 이르기까지 Kinsta의 확장 가능한 호스팅 계획은 모든 유형의 웹 사이트를 수용하도록 설계되었습니다. 확장 가능한 클라우드 호스팅에 대해 자세히 알아보려면 이 기사를 확인하십시오!

우리가 놓친 것이 있습니까? 여전히 WordPress 사이트에서 504 Gateway Timeout 오류를 수정하는 것이 어렵다면 아래에 의견을 남겨주세요.