워드프레스 HTTP 500 (Internal Server Error) 발생하면, 이렇게 해결해 보세요.

Cloudways에서 HTTP 500 (Internal Server Error)가 날 때 가장 빠르게 원인 잡는 “실전 점검 루틴”을 드릴게요. 위에서부터 차례대로 진행하면, 대개 10~30분 안에 원인을 특정/복구합니다. 개인적으로는 처음 경험이라 2시간 걸렸습니다.

워프가 관리자모드 접속 자체가 안되는 케이스였기에, 파일질라 이용해서 SFTP 접속으로 관리자에 들어갈 수 있었습니다. 파일질라 접속을 위한 클라우드웨이즈 몇가지 정보가 필요한데요. 아래에서 한눈에 확인하고 파일질라 접속하세요!!!

Cloudways Access Details 화면에서 FileZilla 접속 시 필요한 정보는 다음과 같이 입력

목차 숨기기

1 SFTP에서 /wp-content/plugins → plugins.off로 변경

2 단계별 방법 (Cloudways + FileZilla 예시)

2.1 1. SFTP 접속 정보 확인

2.2 2. SFTP 클라이언트 실행

2.3 3. 워드프레스 플러그인 폴더 이동

2.4 4. plugins 폴더 이름 변경

2.5 5. 관리자 접속 후 복원

3 플러그인 중 다운을 시킨 범인 찾기

3.1 다음 단계 (문제 플러그인 찾기 과정)

4 plugins 로 다시 이름을 원래대로 돌려놓으니, 다시 워프가 다운된다면

5 0) 연결 위치

6 1) 사이트를 먼저 안정 상태로 만들기

7 2) 플러그인 하나씩 이동 → 활성화 → 테스트

8 3) 추천 활성화 순서 (안전 루틴)

9 4) 여전히 전체 복구만 하면 죽는 경우(중요 체크)

10 5) 원인 플러그인 잡았다면 이렇게 해결

11 6) 에러 정확한 원인 로그 보기(선택)

11.1 한 줄 요약

12 ✅ 권장 테스트 순서

12.1 1단계: 비교적 안전/가벼운 유틸 먼저

SFTP에서 /wp-content/plugins → plugins.off로 변경

“SFTP에서 /wp-content/plugins → plugins.off로 변경” 이라는 건, 플러그인 전체를 강제로 꺼서 관리자 화면(/wp-admin)에 들어갈 수 있게 만드는 응급처치예요. 구체적인 단계는 아래와 같습니다.

단계 순차적으로 진행하기

단계별 방법 (Cloudways + FileZilla 예시)

1. SFTP 접속 정보 확인

Cloudways 콘솔 로그인
Applications → 해당 워드프레스 앱 클릭
왼쪽 메뉴 Access Details → Application Credentials 항목 확인
- 서버 주소 (Host)
- 사용자명 (Username)
- 비밀번호 (Password)

2. SFTP 클라이언트 실행

FileZilla 같은 프로그램 실행 후, 위에서 확인한 Host/Username/Password로 연결
포트는 22 로 입력

3. 워드프레스 플러그인 폴더 이동

접속 후 경로 이동: /home/master/applications/<앱ID>/public_html/wp-content/
여기서 plugins 이라는 폴더를 찾음

4. plugins 폴더 이름 변경

plugins → plugins.off 로 이름 바꾸기 (오른쪽 마우스 → Rename)
→ 워드프레스는 해당 폴더를 못 찾으니까 모든 플러그인이 자동 비활성화 됨
이제 https://도메인/wp-login.php 또는 Cloudways 제공 Application URL + /wp-login.php 로 접속 시도

5. 관리자 접속 후 복원

관리자가 정상 접속되면, 문제가 된 플러그인을 찾아내야 함
- plugins.off → 다시 plugins 로 원복
- 관리자에서 플러그인 목록 확인 후 하나씩 켜보기
- 에러 발생하는 플러그인이 범인

HTTP 500 문제해결 신청하기

✅ 정리:

“plugins.off로 변경” = 플러그인 전체 비활성화 트릭
관리자 들어가기 위한 응급조치로 가장 안전하면서 간단한 방법

플러그인 중 다운을 시킨 범인 찾기

플러그인 비활성화 (가장 먼저 시도) 500 에러는 대부분 플러그인 충돌 때문에 발생합니다. public_html/wp-content/ 폴더로 이동 plugins 폴더 이름을 plugins_old 로 변경 이러면 모든 플러그인이 강제로 비활성화됩니다.

사이트 접속 테스트 👉 접속이 된다면, plugins_old를 다시 plugins로 돌려놓고 내부의 플러그인을 하나씩 이름을 바꾸면서 문제 플러그인을 찾아내면 됩니다. 폴더 이름 변경으로 접속은 되었는데, 내부의 플러그인을 하나씩 이름을 바꾸면서 문제 플러그인을 찾아내면 됩니다.

plugins 폴더 전체 이름을 변경해서 모든 플러그인을 강제로 꺼버린 것입니다.
그래서 워드프레스 사이트가 정상 접속된 거예요. 즉, 문제는 플러그인 중 하나라는 뜻입니다.

다음 단계 (문제 플러그인 찾기 과정)

plugins_old → plugins 로 다시 이름을 원래대로 돌려놓습니다.
- 이러면 플러그인 폴더가 다시 활성화된 상태가 됩니다.
- 하지만, 워드프레스가 플러그인별 폴더명을 기준으로 불러오기 때문에, 개별 플러그인 폴더 이름을 바꿔주면 그 플러그인만 비활성화됩니다.
플러그인 하나씩 비활성화 테스트
- wp-content/plugins/ 안에는 yoast-seo, elementor, woocommerce 같은 개별 폴더들이 있습니다.
- 여기서 예를 들어 elementor 폴더를 elementor_old 로 바꾸면, Elementor 플러그인만 꺼집니다.
사이트 접속 테스트
- 폴더명을 바꾼 후 사이트가 정상 접속된다면 → 그 플러그인이 문제였던 겁니다.
- 접속이 여전히 안 되면 → 다시 원래 이름으로 돌려놓고, 다른 플러그인 폴더를 바꿔보는 식으로 반복합니다.
문제 플러그인 확인 후 조치
- 문제 플러그인을 찾으면, 해당 플러그인을 삭제하거나 업데이트 버전을 다시 설치하면 됩니다.

파일질라 프로그램 신청하기

📌 정리하자면:

전체 plugins 폴더 이름 변경 = 모든 플러그인 강제 비활성화
개별 플러그인 폴더 이름 변경 = 특정 플러그인만 강제 비활성화

plugins 로 다시 이름을 원래대로 돌려놓으니, 다시 워프가 다운된다면

다운 안 되게 안전하게 문제 플러그인을 찾는 “파일질라 단계별 방법”을 바로 갈게요.
핵심은 빈 plugins 폴더를 하나 만들어 놓고, 거기에 플러그인을 하나씩만 되돌려 넣어 활성화·테스트하는 방식입니다.

0) 연결 위치

FileZilla로 접속 → /public_html/wp-content/ 폴더까지 들어가세요. (Cloudways 기본 구조)

1) 사이트를 먼저 안정 상태로 만들기

현재 plugins → plugins_old 로 바꿔서 접속이 된다면, 그 상태를 유지합니다.
새 폴더 생성: wp-content 안에 이름이 정확히 plugins 인 빈 폴더를 하나 만듭니다.
- 이제 구조는 plugins(빈 폴더) + plugins_old(모든 플러그인 보관) 두 개가 공존합니다.
이 상태에서 사이트 & /wp-admin 접속이 가능해야 정상입니다.

주의: 전체 plugins_old 를 다시 plugins 로 되돌리면 다시 다운되므로, 절대 한 번에 되돌리지 마세요.

2) 플러그인 하나씩 이동 → 활성화 → 테스트

plugins_old 폴더를 열고, 플러그인 폴더(예: elementor, yoast-seo 등)를 하나만 드래그해서 빈 plugins 폴더로 옮깁니다.
- ‘복사’가 아니라 ‘이동(Drag & Drop)’이 편합니다.
브라우저에서 워드프레스 관리자 > 플러그인 목록 새로고침 → 방금 옮긴 플러그인이 “비활성” 상태로 나타납니다.
그 플러그인을 활성화합니다.
프론트/관리자 페이지 접속 테스트:
- 정상 동작하면 → 다음 플러그인을 같은 방식으로 이동·활성화합니다.
- 에러(500)가 다시 나면 → 즉시 FileZilla로 그 플러그인 폴더명을 pluginname_off 로 바꿔 비활성화하거나 다시 plugins_old로 되돌리세요. 그 플러그인이 범인입니다.

빠르게 찾고 싶다면 “하프 스플릿(반씩 옮기기)”로도 가능합니다. 다만 한 번에 여러 개 활성화하면 다시 다운될 수 있으니, 옮기는 건 묶음으로 하더라도 ‘활성화’는 1개씩 하세요.

3) 추천 활성화 순서 (안전 루틴)

가장 나중: 캐시/성능/보안류 (Breeze, WP Rocket, LiteSpeed Cache, Object Cache, Wordfence 등)
먼저: 필수 유틸(예: Classic Editor), SEO(Yoast/RankMath), 폼, 슬라이더 등 가벼운 것
쌍으로 관리되는 플러그인(예: Elementor + Elementor Pro, WooCommerce + 애드온)은 버전 맞춘 뒤 순차 활성화

4) 여전히 전체 복구만 하면 죽는 경우(중요 체크)

아래 “항상 로드되는 요소”가 원인일 때가 있습니다. 문제가 의심되면 잠시 꺼보세요.

mu-plugins (wp-content/mu-plugins)
- 폴더명을 mu-plugins_old 로 변경하고 테스트.
Drop-ins (wp-content 바로 아래 파일)
- advanced-cache.php, object-cache.php, db.php가 있으면 각각 *.off 로 임시 변경 후 테스트.
- 캐시 플러그인(Breeze/LSCache/WP Rocket 등)이 남긴 파일로 500이 나올 때가 많습니다.
WP_CACHE 상수
- wp-config.php에서 define('WP_CACHE', true); 가 있다면 일시적으로 주석 처리하거나 false로 바꿔 테스트.
테마 충돌
- wp-content/themes에서 현재 테마 폴더명을 themename_old 로 바꾸면 WP가 기본 테마로 넘어가며 테스트 가능.

5) 원인 플러그인 잡았다면 이렇게 해결

업데이트/재설치: 관리자 > 업데이트에서 해당 플러그인과 쌍 플러그인(프로/애드온)까지 모두 최신으로.
PHP 버전 확인: Cloudways에서 PHP가 최근에 올라갔다면, 호환 버전(예: 8.1 ↔ 8.2)로 맞춰보세요.
캐시 비우기: 캐시류는 전부 끈 상태에서 사이트 정상화 → 마지막에 켜고 캐시 비우기.
대체 플러그인: 업데이트로도 해결이 안 되면 같은 기능의 대체품 고려.

6) 에러 정확한 원인 로그 보기(선택)

wp-config.php에 아래 3줄 추가 후 재현 → wp-content/debug.log 확인

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

Cloudways 패널의 Application Logs에서도 PHP 에러 확인 가능.

한 줄 요약

빈 plugins 폴더를 만들어 놓고 → plugins_old에서 한 개씩만 이동 → 활성화 → 테스트를 반복하면 범인 플러그인을 안전하게 찾을 수 있습니다.
캐시/보안/오브젝트캐시/드롭인/뮤플러그인은 마지막에 건드리세요.

필요하면 지금 설치되어 있는 플러그인 리스트만 알려주시면, 권장 테스트 순서를 바로 짜 드릴게요.

플러그인 리스트 기준으로 “500에러 원인 찾기” 테스트 순서를 짜 드릴게요.
원칙은 안전한 것부터 → 충돌 가능성 큰 것(캐시/SEO/보안) 마지막입니다.

✅ 권장 테스트 순서

1단계: 비교적 안전/가벼운 유틸 먼저

admin-hangul-font
duplicate-page
disable-comments
contextual-related-posts
insert-headers-and-footers
table-of-contents-plus
ultimate-addons-for-gutenberg

이 그룹은 워드프레스 관리 기능 보조용이라 치명적 충돌 확률 낮음. 하나씩 plugins 폴더에 옮겨 활성화 → 정상 동작 확인.

2단계: 이미지/최적화 도구

imagify
image-optimization

이미지 최적화 플러그인은 PHP 모듈, 메모리와 충돌 가능성 있음. 여기서 에러가 나면 범인일 확률 있음.

3단계: 통계/추적/마케팅

google-site-kit
google-sitemap-generator
microsoft-clarity
mshop-mysite (커머스 성격 플러그인)

외부 API 많이 불러오기 때문에 버전 충돌 가능.

4단계: 보안/관리 플러그인

akismet
jetpack
wp-file-manager

특히 jetpack, wp-file-manager 는 종종 500 에러 원인. 여기서 유력 범인이 나올 수 있음.

5단계: SEO 계열

wordpress-seo (Yoast SEO)
seo-by-rank-math (RankMath SEO)

👉 주의: 두 개를 동시에 쓰면 충돌 거의 100% 발생합니다.
→ 둘 다 쓰지 말고 하나만 선택하세요.
(이중 활성화 = 500 에러 원인일 가능성 매우 높음)

개인적으로는 랭크매스를 유료로 사용하고 있어, 나머지는 삭제하고 이것만 활성화

6단계: 캐시·성능·오브젝트

litespeed-cache
object-cache-pro
native-emoji

👉 litespeed-cache, object-cache-pro 는 PHP 캐시와 서버 캐시 모두 건드리므로 500 에러 최상위 용의자입니다.
반드시 맨 마지막에 하나씩만 켜 보세요.

⚡ 추천 실전 절차

plugins 폴더는 비워둔 상태에서 → 1단계 그룹부터 하나씩 넣고 활성화 → 접속 확인.
그룹별로 끝낼 때마다 사이트 정상 확인.
5단계(wordpress-seo, seo-by-rank-math)에서는 반드시 둘 중 하나만 테스트.
마지막 6단계 캐시/오브젝트는 하나씩 → 500 터지면 확실한 범인.

🔎 범인 확률 높은 후보

RankMath + Yoast 동시 설치
LiteSpeed Cache / Object Cache Pro
WP File Manager
Jetpack

👉 정리:
1 → 2 → 3 → 4 → 5 → 6 순서로 올리면서 체크
특히 5단계와 6단계는 범인 가능성 매우 높으니 주의하세요.

Object Cache Pro 활성하니, 다시 다운. 범인 잡음

결론: Object Cache Pro 플러그인이 500 에러의 원인이었습니다.

✅ 다음 조치 방법

1) 즉시 조치

wp-content/plugins/object-cache-pro 폴더명을 그대로 object-cache-pro_old 로 두어 비활성화 유지
사이트 정상화 유지

2) 근본 해결

Object Cache Pro는 유료 고급 플러그인이라 Cloudways에서 자동 번들로 제공되는 경우가 많습니다. 하지만 아래 조건이 맞지 않으면 500 에러를 일으킬 수 있습니다.

Redis 설치/활성화 확인
- Cloudways 패널 → Application Settings > Application Settings > Packages에서 Redis 설치 여부 확인
- 설치 안 되어 있으면 Object Cache Pro가 작동 못 하고 에러 발생
- 설치가 되어 있어도, Redis PHP 모듈 버전이 맞지 않으면 에러
wp-config.php 설정 확인
- define('WP_CACHE', true);
- define('WP_REDIS_CLIENT', 'phpredis'); 등 Object Cache Pro용 설정이 꼬였을 수 있음
- Redis 안 쓰실 거면 아예 이 상수 줄을 주석 처리하거나 삭제
Drop-in 파일 삭제
- wp-content/object-cache.php 파일이 남아 있으면 Object Cache Pro가 로드됩니다.
- Redis 사용 안 하실 거라면 object-cache.php를 삭제하세요.

3) 권장 운영 방안

Redis 사용 예정 없다 → Object Cache Pro는 완전히 비활성화 (plugins 폴더 + object-cache.php drop-in 삭제)
Redis 성능 최적화 원한다 → Cloudways에서 Redis 설치 후 Object Cache Pro를 다시 설정

📌 가장 안전한 선택:
당장은 object-cache-pro 와 object-cache.php 를 꺼두고 사이트를 정상화 → 추후 Redis 설치 여부를 확인한 뒤 필요하면 다시 연결.

여러 방법들이 있지만, 문제가 되는 플러그인 비화성화 후 삭제처리로 마무리 했습니다. 다양한 원인과 이유가 있기에 지피티, 제미나이 등을 활용해서 나름 쉽게 해결해 보았습니다. 워드프레스 HTTP 500 (Internal Server Error) 발생했다면, 꼭 위 방법으로도 확인해 보세요. 저의 경우는 플로그인 충돌이었습니다.