워드프레스 “There has been a critical error on your website” 오류 원인과 해결 과정
워드프레스 관리자 페이지에서 작업 중 다른 페이지는 문제가 없었으나 [업데이트] 페이지를 접속하면 “there has been a critical error on your website. please check your site admin email inbox for instructions.” 오류 메시지가 확인 되었습니다.
워드프레스 “웹사이트에 치명적인 오류가 있습니다.”와 같은 문제 발생 시 빠른 해결 방법은 바로 원인 파악을 하는겁니다.
1️⃣ There has been a critical error on your website: 문제 해결을 위해 wp-config.php 접속
FTP를 사용하거나, Cpanel에 접속해서 워드프레스의 wp-config.php 파일을 디버그 모드로 변경합니다. 저는 직접 서버 접속을 한후 설정을 하였습니다.
wp-config.php 파일을 엽니다.
#define( 'WP_DEBUG', false );
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false); // 화면 출력 금지, 로그에만 저장
ini_set('display_errors', 0);기본값 [define( ‘WP_DEBUG’, false );]을 비활성화 한 후에 디버그 모드를 활성화 합니다. 이후에 오류 페이지에 접속해서 로그가 쌓이도록 확인합니다.
1. 원인 파악: 디버그 파일 확인
~]# vi wp-content/debug.log[wp-content/debug.log] 파일을 열어서 보면 오류 원인이 기록됩니다.
원인을 파악해 보니, 사용하는 플러그인 중 별도 관리자 페이지를 해당 업체에서 제공하는데 업체의 SSL이 만료 된 거였습니다. 이번 경우는 만료, 보통 가장 많은 케이스가 워드프레스 플러그인의 충돌이라고 할 수 있습니다.
PHP Fatal error: Uncaught Error: Cannot use object of type WP_Error as array
in /wp-content/plugins/my-wp-plugin/update.php:442. 문제 해결
메일을 보내지 않더라도 업체에서 확인하고 해결될 사항으로 보이긴 했지만 플러그인을 플러그인 업체에서 다시 SSL을 설치하는 동안 비활성화 하거나 해당 문제가 된 페이지에 접속이 그래도 되는 관계로 SSL이 종료되었으니 갱신해야 한다는 내용으로 메일을 보냈습니다.
2️⃣ [이 웹사이트에 치명적인 오류가 있습니다.] 워드프레스 사이트 메시지 원인은 여러가지입니다.
플러그인에 대한 오류가 가장 많다고 얘기했었고 원인은 다양합니다.
- ERR_CONNECTION_TIMED_OUT
→ 웹 서버가 느리거나 과부하되어 응답이 지연될 때 발생합니다. - ERR_CACHE_MISS
→ 캐시 문제 또는 PHP 기반의 플러그인(캐시 관련 플러그인 포함)이 원인일 수 있습니다. - 500 내부 서버 오류 (500 Internal Server Error)
→ 서버 파일이 손상되었거나.htaccess오류, 플러그인 충돌 등으로 인해 발생하는 심각한 오류입니다. - 데이터베이스 연결 설정 오류 (Error Establishing a Database Connection)
→ 데이터베이스가 손상되었거나, DB 서버 연결 문제, 잘못된 DB 설정 등이 원인입니다. - HTTP 503 서비스를 사용할 수 없음 (503 Service Unavailable)
→ 서버 유지보수 중이거나 과도한 리소스 사용으로 인해 서버가 일시적으로 작동하지 않을 때 발생합니다. - HTTP 502 잘못된 게이트웨이 (502 Bad Gateway)
→ 서버 간 통신 오류, 과도한 트래픽, 리버스 프록시 문제 등으로 인해 발생합니다.
원인을 파악해야 빠른 문제 해결을 할 수 있기에 가장 빠른 방법은 디버그 활성화 후 문제의 원인을 파악하는 겁니다. 저는 랭크 매스의 블로그를 참조해서 문제를 해결 했습니다.
there has been a critical error on your website. please check your site admin email inbox for instructions.3️⃣ 디버그 로그에 아무것도 안 나오는 경우
앞의 방법으로 안 잡히는 경우가 있습니다. WP_DEBUG를 켰는데 debug.log가 비어 있거나 기록이 한참 전에서 멈춰 있는 상황입니다.
이때는 워드프레스 쪽이 아닌 서버에서 확인해야 하는 경우일 수 있습니다.
1. 프런트가 정상으로 보여도 재확인이 필요.
관리자 화면만 죽고 홈은 멀쩡해 보일 때가 있습니다. CDN이나 페이지 캐시가 예전 사본을 대신 내보내는 중일 수 있습니다.
캐시를 우회해 원본 서버를 직접 부릅니다.
curl -s -o /dev/null -w "%{http_code}\n" -H "Host: 도메인" "http://127.0.0.1:8080/?v=$RANDOM"여기서 500이 나오면 사이트 전체가 죽은 것입니다. 캐시가 만료되는 순간부터 방문자에게도 오류가 나갑니다.
2. 진짜 오류는 서버 로그
wp-content/debug.log는 워드프레스가 뜬 뒤부터 기록합니다. 뜨기 전에 죽으면 아무것도 안 남습니다.
웹 서버 로그를 봅니다.
tail -50 /var/log/httpd/error_log‘PHP Fatal error’와 함께 파일 경로와 줄 번호가 찍힙니다. 여기서 시작점이 정해집니다.
3. CLI와 웹을 갈라 봅니다.
WP-CLI로 같은 함수를 불러 봅니다.
wp eval 'echo get_template();'CLI에서 멀쩡하면 파일과 데이터베이스는 정상입니다. 원인이 웹 요청 쪽에만 있다는 뜻입니다. opcache나 JIT 같은 실행 엔진이 후보로 올라옵니다.
4. 화면이 민무늬로 벗겨지는 것도 같은 뿌리입니다.
500이 아니라 관리자 화면의 CSS만 빠질 때가 있습니다. 글자와 링크만 남고 배치가 사라진 화면입니다.
load-styles.php를 직접 불러 봅니다. 관리자 CSS를 한 파일로 묶어 내보내는 곳입니다.개별 .css는 200인데 이 파일만 500이면 경로나 권한 문제가 아닙니다.
5. 조치 순서
- php-fpm을 재시작
- 오브젝트 캐시 비우기
- 페이지 캐시 드롭인을 잠시OFF
- ‘opcache.jit=disable’을 넣고 재시작
앞의 셋으로 안 되면 마지막이 PHP JIT입니다. 워드프레스는 데이터베이스와 입출력에 묶인 작업이라 JIT는 꺼도 체감이 되지 않습니다.
6. 실제로 겪은 일
2026년 9월 5일에 이 서버의 PHP에 JIT를 켰습니다. 속도를 올리려는 설정이었고 사흘 동안 아무 일도 없었습니다.9월 8일 저녁에 사이트 전체에서 500에러가 발생했습니다. 스캐너가 몰려 PHP 워커가 반복해서 포화 된 뒤였습니다.
처음에는 관리자 화면만 죽은 줄 알았습니다. 홈은 200으로 보였는데, CDN 캐시가 예전 사본을 대신 내보내고 있었기 때문입니다. 원인은 서버 로그에 있었습니다. ‘apply_filters’ 한 줄에서 4GB를 할당하려다 죽고 있었습니다.
그 자리에는 필터 콜백이 하나도 없었고 CLI에서는 멀쩡했습니다. 코드나 데이터가 아니라 실행 엔진 문제였습니다. JIT를 끄고 php-fpm을 재시작 이후 복구가 완료 되었으며, 첫 오류부터 복구까지 14분이 소요되었습니다.
로그가 비어 있다는 것은 단서가 없다는 뜻이 아니라 로그를 볼 자리를 잘못 잡았다는 뜻입니다.
ℹ️ 제휴 안내
본 사이트의 콘텐츠에는 제휴 링크가 포함되어 있습니다. 방문자가 이 링크를 통해 상품 또는 서비스를 구매하면 본 사이트는 판매처로부터 수수료를 지급받습니다. 이 과정에서 구매자가 지불하는 금액(이벤트 할인 시 금액이 내려갑니다↓)은 오르지 않습니다. 게시된 가격·할인·재고 정보는 작성 시점 기준이며 실제와 다를 수 있으므로, 구매 전 판매처에서 최종 확인하시기 바랍니다. 상품 선정과 평가는 자체 기준에 따라 작성되며, 수수료 지급 여부가 소개 순서나 평가 내용에 영향을 주지 않습니다.
