WSoD(WordPress White Screen of Death) 오류를 수정하는 방법

게시 됨: 2023-01-10

비어 있는 흰색 페이지만 표시되도록 WordPress 사이트를 로드하는 것은 실망스러운 일입니다. 이것은 일반적으로 WordPress White Screen of Death 오류라고합니다.

이 가이드에서는 사이트에서 오류를 일으키는 원인과 오류를 수정하는 방법을 구체적으로 파악하는 방법을 안내합니다.

  • WordPress에서 흰색 죽음의 화면이 표시되는 이유는 무엇입니까?
  • 1단계 – 사이트 캐시 지우기부터 시작
  • 2단계 – PHP 오류 로그 확인
  • 3단계 – 디버그 모드를 사용하여 오류 식별
  • 4단계 – WordPress 및 PHP 메모리 제한 늘리기
  • 5단계 – 마지막으로 변경한 사항을 기억하십시오.
  • 6단계 – 플러그인 비활성화
  • #7단계 – 사이트 백업 복원
  • 디버깅 옵션: 테마의 잠재적인 문제 확인

WordPress에서 흰색 죽음의 화면이 표시되는 이유는 무엇입니까?

WordPress White Screen of Death 오류가 발생하면 이름에서 알 수 있듯이 흰색 화면만 표시되기 때문에 특히 실망스럽습니다. 원인이 무엇인지, 어디를 봐야 하는지에 대한 정보가 없습니다.

White Screen Of Death 오류 예(wsod)

사이트에서 오류의 원인을 식별하고 모든 것을 백업 및 실행하는 방법을 알아보기 전에 가장 일반적인 원인에 대한 분석은 다음과 같습니다.

  • PHP 코드 오류(종종 방금 발생한 플러그인 업데이트)
  • PHP 메모리 제한 소진

참고: 플러그인의 스크립트 또는 프로세스에 갑자기 더 많은 리소스가 필요한 경우 리소스를 제한하고 사이트를 조절하는 방법에 따라 특정 WordPress 호스팅 공급자에서 이러한 문제가 발생할 가능성이 더 큽니다. 호스팅 제공 업체에서 너무 쉽게 발생하는 경우 쉽게 충돌하는 호스트가 대규모 마케팅 캠페인을 실행하는 경우 사이트를 오프라인으로 전환할 가능성이 높기 때문에 더 나은 WordPress 호스팅 제공 업체 로 이동하는 것을 고려해야 할 때입니다. 한 번에 상당한 양의 트래픽을 유도하는 등

따라서 더 이상 고민하지 않고 웹 사이트에서 WSoD 오류를 수정하는 방법을 살펴보겠습니다.

죽음의 WordPress 화이트 스크린을 수정하는 방법

1단계 – 사이트 캐시 지우기 시작(캐싱 플러그인 포함)

프로덕션 사이트인 경우 캐싱이 있을 가능성이 있으며 그렇지 않은 경우 캐싱을 해야 합니다 . 이는 적극 권장되지만 브라우저나 서버에 캐시된 버전을 볼 때 사이트 에서 실제로 일어나는 일 을 볼 수 없다는 의미 일 수 있습니다.

참고: 여기에는 보유하고 있을 수 있는 추가 캐싱 계층도 포함됩니다. 예를 들어, 캐싱 플러그인 – 서버 수준 캐싱 외에 해당 플러그인을 삭제해야 합니다.

WordPress에서 캐시를 지운 후 브라우저의 캐시도 지우고 싶을 것입니다.

브라우저 캐시 지우기

더 이상 WordPress 관리 영역에 액세스할 수 없는 경우: WP-CLI를 사용하여 캐시를 지울 수 있습니다. SSH를 통해 사이트에 연결 한 후 – 먼저 Servebolt의 사이트에 대한 사이트 디렉토리로 이동합니다(예는 아래 1행에 포함됨). 그런 다음 캐시를 플러시하고 선택적으로 그렇게 할 때 테마 및 플러그인 활성화를 제외하십시오.

cd ~/public

wp cache flush --skip-plugins --skip-themes

완료되면 사이트에 다시 액세스하여 문제가 지속되는지 확인하십시오.

그래도 작동하지 않으면 다른 잠재적 솔루션을 읽어 보십시오.

2단계 – PHP 오류 로그 확인

참고: 로그 파일을 읽는 것이 불편하면 3단계로 건너뛰십시오.

캐싱을 배제한 첫 번째 단계는 PHP 오류 로그를 확인하는 것입니다. 오류, 문제 또는 잠재적인 문제의 진정한 원인을 찾는 가장 좋은 방법이기 때문에 항상 기본적으로 로그를 확인하는 것이 좋습니다.

여기에서 로그 파일 보기 및 검사에 대해 자세히 알아보십시오.

그렇게 하면 문서의 잠재적인 수정 사항 을 구현하기 전에 그 이유를 이해할 수 있습니다(즉, 메모리 제한을 높이면 문제가 해결되는지 테스트하기 전에 더 높은 제한이 필요한 플러그인이 실행 중인지 아는 것이 좋습니다). .

오류 로그를 확인하는 목적은 올바른 방향을 알려주는 것입니다. 그러나 여기에서 발견한 것을 실제로 사용하는 것 또한 마찬가지로 중요합니다! 오류와 경고는 모두 주의를 집중하고 해결하기 위해 노력해야 하는 첫 번째 장소임을 의미합니다(이것이 편하지 않다면 개발자와 함께 작업하는 것이 좋습니다).

3단계 – 디버그 모드를 사용하여 오류 식별

WordPress에 내장된 "디버그" 모드는 서버의 오류를 식별하는 데 도움이 될 수 있습니다. WordPress에서 디버깅 모드를 활성화하려면 wp-config.php 파일을 열고 마지막 줄 바로 앞에 다음 코드를 추가하십시오.

// Enable WP_DEBUG mode

define( 'WP_DEBUG', true );

// Enable Debug logging to the /wp-content/debug.log file

define( 'WP_DEBUG_LOG', true );

참고: WP_DEBUG 모드를 활성화하면 모든 PHP 오류, 알림 및 경고가 표시됩니다. 이는 손상 되지 는 않았지만 WordPress(및/또는 PHP) 개발 규칙을 따르지 않는 항목에 대한 오류 및 경고 메시지를 표시할 수 있습니다.

이제 웹사이트를 열면 흰색 화면 대신 오류나 알림이 표시될 수 있습니다. WordPress에서 디버깅을 활성화하면 오류를 확인할 수 있는 debug.log 파일도 생성됩니다.

모든 오류 또는 경고에 대한 정보가 포함된 로그 파일입니다. wp-content 디렉토리 에서 찾을 수 있습니다 . 로그 파일을 확인하여 문제의 원인을 식별하고 수정하십시오.

예를 들어 플러그인이 문제를 일으키는 경우 디버그 파일에 오류가 기록됩니다. 그런 다음 해당 특정 플러그인을 비활성화하고 개발자에게 문제를 보고할 수 있습니다.

완료되면 wp-config.php 파일에서 코드를 제거하여 디버깅 모드를 종료하십시오. 이것은 WordPress 웹사이트에서 오류를 식별하는 더 좋은 방법 중 하나이지만 사이트에서 발생하는 모든 오류를 항상 포착하지는 않습니다.

디버깅 모드를 종료했는지 확인하십시오. 많은 사용자가 실수로 그대로 두어 웹 사이트 성능이 저하되고 리소스 소비가 증가합니다.

4단계 – WordPress 및 PHP 메모리 제한 늘리기

서버에 설정된 메모리 제한이 문제의 원인일 수도 있습니다. 사이트의 모든 플러그인은 서로 다른 스크립트를 실행하며 실행을 위해 서버의 메모리를 사용합니다.

이 외에도 WordPress는 플러그인이 사이트 속도를 저하시키는 비효율적인 프로세스를 실행하지 못하도록 메모리 제한을 부과합니다. 즉, 스크립트에 허용된 것보다 더 많은 메모리가 필요한 경우 White Screen of Death가 발생할 수 있습니다.

그러나 사용 가능한 메모리를 늘리기 전에 로그를 검토하여 이 모든 메모리를 소비하는 것이 무엇인지 정확히 확인할 수 있습니다. 맹목적으로 메모리를 늘리는 것은 절대 권장되지 않으므로 먼저 로그를 주의 깊게 검토하는 것이 중요합니다.

이 문제를 해결하기 위해 다른 플러그인에서 사용할 수 있는 메모리 양을 늘릴 수 있습니다. SFTP를 사용하여 서버에 로그인한 다음 wp-config.php 파일을 찾습니다. Servebolt를 포함하여 대부분의 경우 공용 폴더에 있습니다.

wp-config.php 파일을 열고 맨 아래에 다음 행을 추가하십시오.

define( 'WP_MEMORY_LIMIT', '64M' );

이를 통해 WordPress는 플러그인 스크립트에 최대 64MB의 메모리를 할당할 수 있습니다. 어떤 경우에는 이렇게 하면 문제가 해결될 수 있습니다. 즉시 수정되지 않으면 125, 256 및 512와 같은 더 큰 값을 시도하십시오. 성능이 좋지 않은 코드가 평소보다 훨씬 더 많은 메모리를 사용하고 있을 수 있으므로 더 많은 메모리를 사용할 수 있을 때 활성화됩니다.

Servebolt에서 제한을 정의하지 않는 한 WordPress는 항상 사용 가능한 최대 메모리를 사용합니다. 따라서 이전에 사용 가능한 메모리를 제한한 경우에만 이 단계를 수행해야 합니다.

또는 Servebolt 제어판에서 더 높은 PHP 메모리 제한을 설정할 수도 있습니다. 사이트 설정 으로 이동 하면 아래와 같이 웹사이트의 PHP 메모리 제한을 변경할 수 있습니다.

Servebolt 제어판에서 더 높은 PHP 메모리 제한 설정

5단계 – 마지막으로 변경한 사항을 기억하십시오.

플러그인을 설치 및 활성화했는지 아니면 설정을 변경했는지 잠시 생각해 보십시오. 사망의 흰색 화면은 일반적으로 PHP가 충돌할 때 발생합니다(즉, 서버와 관련이 없음).

따라서 이는 최근에 이를 발생시킨 플러그인에서 프로세스를 시작했음을 의미할 수 있습니다(예: 대용량 미디어 라이브러리 등을 처리하는 효율적인 방법이 있는 이미지 최적화 플러그인).

변경 사항을 추적하고 이전 반복을 기억하기가 훨씬 쉽기 때문에 Git 사용을 고려할 수 있습니다. Git은 변경 사항을 저장하므로 필요할 때 다시 불러올 수 있습니다.

어떤 변경을 했는지 식별할 수 있는 경우 플러그인 또는 테마 개발자가 작업을 완료할 때까지 해당 설정을 활성화하는 것이 작동하지 않는다는 점(다시 시도해서는 안 됨)을 쉽게 역추적하고 메모할 수 있습니다. 문제를 해결하기 위해 연락했습니다.

6단계 – 플러그인 비활성화

이것은 약간 더 지루하고 덜 선호되는 방법이므로 값이 너무 낮습니다. 각 플러그인을 개별적으로 문제 해결하는 것은 번거롭지만 설치된 모든 플러그인을 한 번에 비활성화하는 것과 같은 일괄 작업을 적용할 수 있습니다.

대시보드 영역에 액세스할 수 없는 경우 FileZilla 와 같은 SFTP 클라이언트를 사용하여 사이트에 연결해야 합니다 . wp-content 폴더를 검색하면 "plugins"라는 디렉토리가 표시됩니다.

"plugins-deactivated"로 이름을 바꾸고 변경 사항을 저장합니다. WordPress는 더 이상 사이트에서 플러그인을 로드할 폴더를 찾을 수 없습니다. 따라서 자동으로 완전히 비활성화됩니다. 이것은 WordPress가 plugins 라는 폴더를 찾기 때문입니다 해당 폴더를 찾을 수 없으면 자동으로 모든 플러그인이 비활성화된 것으로 간주합니다.

WordPress에서 플러그인 비활성화

그 시점에서 선택한 FTP 클라이언트로 돌아가서 폴더 이름을 플러그인 으로 다시 설정합니다 . 이제 관리 영역으로 돌아가 플러그인을 하나씩 활성화하여 문제가 있는 플러그인을 격리할 수 있습니다.

#7단계 – 사이트 백업 복원

아무 것도 작동하지 않는 것 같으면 사이트의 백업 복원을 고려할 수 있습니다. 당연히 백업에 문제가 생길 경우를 대비하여 현재 파일의 백업을 만드는 것이 가장 좋습니다(비합리적으로 보일 수도 있지만).

Servebolt 는 고객을 위해 모든 파일과 데이터베이스를 매일 백업합니다. 사이트 채팅을 통해 Servebolt에 연락하기만 하면 사이트 백업을 복원할 수 있습니다. 팀에서 추가 비용 없이 백업을 복원합니다.

백업은 최대 30일 동안 저장되며, 지난 14일 동안 하루에 한 번 백업하고 그 이전에는 매주 두 번 백업합니다.

디버깅 옵션: 테마 문제 확인

워드프레스 테마

웹 사이트에서 사용하는 테마로 인해 경우에 따라 White Screen of Death가 발생할 수도 있습니다. 플러그인과 충돌하거나 업데이트 중에 특정 파일이 손상되었을 수 있습니다. 오류를 확인하거나 테마를 교체하여 문제가 해결되는지 확인할 수 있습니다. 최후의 수단으로 디버깅을 계속하면서 기본 WordPress 테마로 전환하는 것이 좋은 임시 해결책이 될 수 있습니다.

관리 대시보드에 액세스할 수 없으면 어떻게 합니까?

관리자 대시보드에 액세스하려고 할 때 죽음의 흰색 화면이 표시되는 경우 테마를 변경하는 것은 분명히 같은 방식으로 수행할 수 없습니다.

대신 SFTP를 사용하여 사이트의 파일에 액세스할 수 있습니다.

사이트에 접속하면 다음을 수행하십시오.

  1. webroot 폴더를 찾은 다음 wp-content 디렉토리로 이동합니다.
  2. 거기에서 "themes"라는 폴더를 검색하십시오. 내부에서 활성 테마의 이름을 찾으십시오.
  3. 그런 다음 테마의 디렉토리 이름 뒤에 접미사 "_old"를 추가하고 변경 사항을 저장하십시오. WordPress는 테마를 비활성화합니다(기본 테마가 설치되어 있는 경우 기본적으로 해당 테마로 전환).
  4. 웹사이트에 다시 접속해 보십시오.

SSH 액세스 권한이 있는 경우 WP-CLI 를 사용하여 테마를 다른 테마로 변경할 수 있습니다 .

이 예에서는 테마 Twenty Twenty-Two로 변경됩니다.

wp theme activate twentytwentytwo --skip-plugins --skip-themes

참고: 이 명령은 이 변경을 수행할 때 플러그인 및 테마 초기화를 건너뜁니다.

사이트가 다시 작동하면 WordPress 테마로 인해 문제가 발생한 것입니다. 테마가 여전히 활발하게 유지 관리되는 경우 테마 개발자가 수정 작업을 할 수 있도록 이 문제를 테마 개발자에게 보고해야 합니다. 그렇지 않은 경우 일반적으로 다른 WordPress 테마로 전환하는 것이 좋습니다.

조치 후 보고서 – 예방 조치를 취하려면 호스팅 지원팀에 문의하십시오.

오류의 이름은 분명히 훨씬 더 심각해 보이지만, 흰색 화면만 표시될 때 WordPress 웹 사이트를 백업 및 실행하는 것은 일반적으로 수정하기 쉬운 오류입니다. 이 문제를 해결하는 데 여전히 어려움을 겪고 있다면 다음 단계는 WordPress 호스팅 제공업체의 지원 팀에 연락하는 것입니다. 사이트를 호스팅하기로 현명한 결정을 내린 경우 Servebolt 계정에 로그인하여 채팅하십시오. 함께 문제를 해결할 수 있도록 도와드리겠습니다.

아직 Servebolt를 사용하지 않지만 경험적으로 더 빠른 관리형 호스팅에 관심이 있으십니까?

 지금 Servebolt에서 WordPress를 사용해 보세요.

    • 확장성: 실제 사용자 워크로드 테스트에서 Servebolt는 65ms의 평균 응답 시간을 제공하여 2위보다 4.9배 더 빠른 응답 시간을 제공했습니다.
    • 가장 빠른 글로벌 로드 시간: 1.26초의 글로벌 평균 페이지 로드 시간은 Servebolt를 글로벌 WebPageTest 결과 목록의 맨 위에 둡니다 .
  • 가장 빠른 컴퓨팅 속도: Servebolt 서버는 초당 평균보다 2.44배 더 많은 쿼리를 처리하고 2위 서버보다 PHP를 2.6배 더 빠르게 실행하는 유례없는 데이터베이스 속도를 제공합니다!
  • 완벽한 보안 및 가동 시간: 모든 모니터에서 100% 가동 시간과 SSL 구현에 대한 A+ 등급을 통해 사이트가 온라인 상태이고 안전하다는 확신을 가질 수 있습니다.

전문가 팀의 지원을 받으며 오늘 무료 테스트 Bolt 를 사용해 볼 준비가 되었습니다 .