워드프레스 느려짐 WHM 서버 점검 및 Cloudflare TTFB 진단 후기

워드프레스를 오래 운영하다 보면 평소에는 멀쩡하던 사이트가 어느 날 갑자기 굉장히 느려지는 경우가 있습니다. 저도 이번에 워드프레스 사이트를 접속하는데 첫 화면이 뜨기까지 몇 초씩 기다려야 할 정도로 느려져 처음에는 플러그인 과부하나 MySQL 데이터베이스 문제를 가장 먼저 의심했습니다.

특히 워드프레스 글과 이미지가 많아지고 플러그인도 여러 개 사용하는 사이트라면 CPU 부족, 메모리 부족, PHP 과부하, MySQL 느린 쿼리, WP-Cron, 캐시 플러그인 중 하나가 원인이라고 생각하기 쉽습니다.

그런데 이번에는 WHM 서버에 직접 접속해 하나씩 확인해보니 예상과 조금 달랐습니다. 서버 자체는 상당히 여유가 있었고, 원본 서버 응답도 빨랐습니다. 반면 Cloudflare를 거쳐 접속할 때만 TTFB가 크게 증가하는 구간이 확인됐습니다.

개인정보 보호 안내
아래 명령어의 도메인과 IP 주소는 모두 예시입니다.
example.com에는 자신의 워드프레스 도메인을, 203.0.113.10에는 자신의 서버 원본 IP를 입력하면 됩니다.

워드프레스가 갑자기 느려졌다면 플러그인부터 삭제하지 말자

사이트가 느려지면 가장 먼저 플러그인을 비활성화하거나 캐시를 삭제하고 싶은 마음이 듭니다.

저도 처음에는 WP Rocket을 비롯한 캐시 플러그인이나 SEO 플러그인, 이미지 최적화 플러그인 등을 의심했습니다.

하지만 서버가 느린 이유는 크게 나누면 다음과 같습니다.

• CPU 사용량이 너무 높은 경우
• RAM 부족으로 Swap을 사용하는 경우
• SSD 또는 디스크 I/O 병목
• MySQL 쿼리가 밀리는 경우
• PHP-FPM 또는 워드프레스 플러그인이 느린 경우
• 봇이나 크롤러 접속이 폭증한 경우
• Cloudflare 또는 서버와 CDN 사이의 네트워크 지연

원인을 확인하지 않고 플러그인부터 하나씩 끄면 시간이 오래 걸릴 뿐 아니라 정상적으로 동작하던 사이트 설정까지 꼬일 수 있습니다. 그래서 저는 이번에는 WHM → Terminal에서 서버 상태부터 확인했습니다.

WHM Terminal에서 서버 과부하 확인하기

cPanel 기반 VPS나 전용 서버를 사용한다면 WHM 관리자에서 Server Configuration → Terminal 또는 검색창에서 Terminal을 찾아 접속할 수 있습니다.

WHM Terminal은 일반 cPanel 터미널과 달리 root 권한으로 접근하는 경우가 많기 때문에 명령어를 잘못 입력하면 서버 설정에 영향을 줄 수 있습니다. 아래에서 사용하는 명령어들은 대부분 상태를 조회하는 명령입니다.

1. uptime으로 서버 부하 확인

uptime

가장 먼저 확인한 명령어입니다.

예를 들어 다음과 같이 표시됩니다.

load average: 0.09, 0.14, 0.12

세 숫자는 각각 최근 1분, 5분, 15분 동안의 평균 부하입니다.

서버 CPU 코어가 4개인데 Load Average가 오랫동안 4 이상으로 유지된다면 CPU 작업이 밀리고 있는지 확인해 볼 필요가 있습니다. 반대로 제가 확인했을 때는 0.1 전후 수준이라 서버 전체 CPU 과부하는 아니라고 볼 수 있었습니다.

추가로 확인할 부분
uptime 결과에 서버 가동 시간이 몇 분밖에 되지 않는다면 최근 서버가 재부팅됐다는 뜻입니다. 직접 재부팅하지 않았다면 장애나 OOM, 호스팅사 재부팅 여부도 확인할 필요가 있습니다.

2. top으로 CPU와 메모리 실시간 확인

top

top에서는 CPU, 메모리, 실행 중인 프로세스를 실시간으로 확인할 수 있습니다.

제가 확인했을 때 CPU 부분은 대략 다음과 같은 상태였습니다.

%Cpu(s): 4.4 us, 0.6 sy, 94.4 id, 0.3 wa

여기서 특히 중요한 것이 id입니다. idle의 약자로 CPU가 아무 일도 하지 않고 쉬고 있는 비율입니다.

94% 이상이 idle 상태라면 서버가 느린 시점에도 CPU 자체는 거의 놀고 있다는 뜻입니다. 따라서 CPU 업그레이드가 해결책이 아닐 가능성이 높습니다.

top에서 알아두면 좋은 값

항목	의미
us	사용자 프로그램 CPU 사용량
sy	커널 CPU 사용량
id	CPU가 쉬고 있는 비율
wa	디스크 I/O를 기다리는 시간

3. free -h로 RAM 부족 확인

free -h

워드프레스가 느려질 때 CPU만큼 자주 발생하는 문제가 RAM 부족입니다.

여기서는 단순히 free 값보다 available 메모리를 보는 것이 좋습니다. 리눅스는 남는 메모리를 캐시로 적극 활용하기 때문입니다.

Swap까지 계속 사용하고 있다면 메모리가 부족해 디스크를 RAM처럼 사용하면서 사이트가 갑자기 느려질 수도 있습니다.

swapon --show

제가 확인한 서버에서는 약 8GB RAM 중 상당한 메모리가 남아 있었고 Swap 사용량도 0이었습니다. 따라서 메모리 증설 역시 이번 느려짐의 해결책은 아니었습니다.

CPU를 많이 사용하는 프로세스 찾기

top 화면만으로 확인하기 어렵다면 프로세스를 CPU 사용량 순서로 정렬해서 볼 수 있습니다.

ps aux --sort=-%cpu | head -20

메모리 사용량 순으로 보고 싶다면 다음과 같습니다.

ps aux --sort=-%mem | head -20

이때 다음과 같은 프로세스가 유독 높은 값을 계속 유지하는지 확인하면 됩니다.

• php-fpm
• lsphp
• mysqld
• httpd
• apache
• wp
• 백업이나 압축 관련 프로세스

특히 php-fpm이나 lsphp가 여러 개 생성되고 CPU를 지속적으로 점유한다면 워드프레스 PHP 작업이나 특정 플러그인을 의심할 수 있습니다.

디스크 용량과 I/O 문제 확인하기

서버 저장공간 확인

df -h

루트 파티션이나 /home, /var 등이 90~100% 가까이 사용 중이면 로그, 캐시, 백업 파일 등을 확인할 필요가 있습니다.

작은 파일이 지나치게 많아 inode가 고갈되는 경우도 있어 다음 명령어도 도움이 됩니다.

df -i

SSD I/O 지연 확인

iostat -xz 1 10

여기서는 await와 %util 값을 확인합니다. 디스크 사용률이 계속 100%에 가까우면 CPU가 여유 있어도 PHP나 MySQL이 디스크를 기다리느라 사이트가 느려질 수 있습니다.

MySQL이 워드프레스를 느리게 만드는지 확인

CPU와 RAM이 정상이라면 다음으로 확인한 것이 MySQL입니다.

mysql -e "SHOW FULL PROCESSLIST;"

이 명령어는 현재 MySQL에서 실행되고 있는 쿼리를 보여줍니다.

다음 상태가 오랫동안 여러 개 쌓여 있다면 데이터베이스 문제를 의심할 수 있습니다.

• Locked
• Waiting for table metadata lock
• Sending data
• Creating sort index
• Copying to tmp table

제가 확인한 당시에는 MySQL Event Scheduler가 대기 중인 것 외에는 사이트 쿼리가 쌓여 있지 않았습니다.

따라서 MySQL 쿼리 적체도 이번 문제의 주원인으로 보기 어려웠습니다.

워드프레스 느려짐 진단에서 가장 유용했던 curl TTFB 측정

이번에 가장 도움이 됐던 것은 curl을 이용해 DNS, 연결, TLS, TTFB, 전체 응답시간을 따로 측정한 것입니다.

• [블로그 수익화/블로그 SEO] - 워드프레스 MySQL DB 최적화 방법 phpMyAdmin SSH WHM cPanel 호스팅별 정리
• [블로그 수익화/블로그 SEO] - 블루호스트 VPS 워드프레스 TTFB 줄이기(OPcache + Redis Object Cache 설치)

웹사이트가 느리다는 말만으로는 서버가 느린 것인지 인터넷 구간이 느린 것인지 알 수 없습니다.

하지만 TTFB를 구간별로 확인하면 어디에서 시간이 소비되는지 비교하기 쉬워집니다.

일반 도메인 접속 TTFB 측정

curl -k -o /dev/null -s -w "TTFB:%{time_starttransfer}\nTOTAL:%{time_total}\n" https://example.com/

제가 처음 테스트했을 때는 예시로 정리하면 다음과 같이 상당히 느린 값이 나왔습니다.

TTFB: 약 9~10초
TOTAL: 약 11초

첫 HTML 데이터가 오기까지 거의 10초가 걸리는 것은 정상적인 상태라고 보기 어렵습니다.

Cloudflare를 우회하고 Origin 서버를 직접 테스트

Cloudflare를 사용하고 있다면 일반적인 도메인 테스트 결과에는 Cloudflare까지 포함됩니다.

그래서 다음에는 Cloudflare를 거치지 않고 같은 서버 안에서 원본 웹서버를 직접 호출했습니다.

curl -k --resolve example.com:443:127.0.0.1 \
-o /dev/null -s \
-w "ORIGIN_TTFB:%{time_starttransfer}\nORIGIN_TOTAL:%{time_total}\n" \
https://example.com/

놀랍게도 이 테스트에서는 약 0.007~0.008초 수준으로 응답했습니다.

다만 이 숫자를 보고 PHP가 실제로 워드프레스 페이지를 7ms 만에 생성한다고 생각하면 안 됩니다.

Nginx, Bluehost 서버 캐시 또는 다른 페이지 캐시가 앞단에서 응답했을 가능성도 있기 때문입니다.

그래도 중요한 점
서버 내부에서 같은 페이지를 요청했을 때 매우 빠르고 일정하게 응답한다면 CPU, RAM, 웹서버 자체가 지속적으로 10초씩 막히고 있는 상황일 가능성은 크게 낮아집니다.

캐시 때문에 빨라 보이는지 추가 확인

단순 Origin 테스트가 서버 캐시를 사용했을 가능성이 있어 query string을 붙여 여러 번 확인했습니다.

for i in {1..5}; do
curl -k --resolve example.com:443:127.0.0.1 \
-o /dev/null -s \
-w "RUN$i TTFB:%{time_starttransfer} TOTAL:%{time_total}\n" \
"https://example.com/?diag=$RANDOM$i"
done

5번 모두 비슷하게 0.007초 수준이었습니다.

WP Rocket 캐시를 최대한 피하기 위해 로그인 쿠키와 nowprocket도 추가해 비교했습니다.

for i in {1..5}; do
curl -k --resolve example.com:443:127.0.0.1 \
-H "Cookie: wordpress_logged_in_test=1" \
-o /dev/null -s \
-w "ORIGIN RUN$i TTFB:%{time_starttransfer} TOTAL:%{time_total}\n" \
"https://example.com/?nowprocket&diag=$RANDOM"
done

이 테스트에서도 응답이 일정하게 빨랐습니다.

다만 호스팅 업체의 Nginx 캐시처럼 WP Rocket보다 앞단에서 동작하는 캐시는 ?nowprocket만으로 완전히 우회되지 않을 수 있습니다.

따라서 이 결과는 플러그인이 100% 무죄라는 증명이라기보다 서버 내부에서 지속적인 5~10초 PHP 지연이 발생하고 있다는 흔적은 보이지 않았다 정도로 해석하는 것이 안전합니다.

Cloudflare IP를 직접 분리해서 테스트하기

Cloudflare를 사용하면 도메인을 조회했을 때 원본 서버 IP 대신 Cloudflare IP가 표시됩니다.

dig +short example.com A

예를 들어 다음처럼 2개의 IP가 표시될 수 있습니다.

198.51.100.10
198.51.100.20

실제 글에서는 보안을 위해 서버에서 나온 Cloudflare IP 대신 문서용 예시 주소를 사용했습니다.

각 IP를 강제로 지정해 비교하려면 다음처럼 사용할 수 있습니다.

curl -4 --resolve example.com:443:198.51.100.10 \
-o /dev/null -s \
-w "IP:%{remote_ip} CONNECT:%{time_connect} TLS:%{time_appconnect} TTFB:%{time_starttransfer} TOTAL:%{time_total}\n" \
https://example.com/

두 번째 IP도 같은 방식으로 테스트합니다.

curl -4 --resolve example.com:443:198.51.100.20 \
-o /dev/null -s \
-w "IP:%{remote_ip} CONNECT:%{time_connect} TLS:%{time_appconnect} TTFB:%{time_starttransfer} TOTAL:%{time_total}\n" \
https://example.com/

한 번만 테스트하면 안 되는 이유

이번에 실제로 느낀 부분입니다.

처음 한 번 측정했을 때 특정 Cloudflare IP에서 6~7초가 나오기도 했지만 바로 다음 테스트에서는 0.2~1초 수준으로 정상화됐습니다.

그래서 네트워크 문제는 한 번의 결과만 보고 결론 내리기보다는 최소 5회 정도 반복하는 것이 좋았습니다.

for i in {1..5}; do
curl -4 --resolve example.com:443:198.51.100.10 \
-o /dev/null -s \
-w "RUN$i CONNECT:%{time_connect} TTFB:%{time_starttransfer} TOTAL:%{time_total}\n" \
https://example.com/
done

이번 테스트에서는 같은 서버에서도 TTFB가 0.2초였다가 1초 이상으로 증가하는 등 일정하지 않은 모습을 확인할 수 있었습니다.

CONNECT, TLS, TTFB 차이를 알아두면 원인 찾기가 쉽다

curl 결과에서 가장 중요하게 본 것은 다음 네 가지입니다.

항목	확인할 내용
DNS	도메인 주소를 IP로 찾는 시간
CONNECT	서버와 TCP 연결이 성립되는 시간
TLS	HTTPS 암호화 연결이 완료되는 시간
TTFB	요청 후 첫 데이터를 받을 때까지 걸린 전체 시간
TOTAL	응답을 모두 받기까지 걸린 시간

예를 들어 CONNECT가 0.05초이고 TLS가 0.2초인데 TTFB가 8초라면 인터넷 연결 자체보다 TLS 완료 이후 서버 또는 중간 프록시가 응답하기까지 기다리는 구간을 확인해야 합니다.

반대로 CONNECT 자체가 8~10초라면 TCP 연결이나 네트워크 라우팅을 먼저 확인하는 편이 맞습니다.

Cloudflare 응답 헤더 확인하기

Cloudflare를 실제로 거치고 있는지와 캐시 상태는 HTTP 응답 헤더에서도 확인할 수 있습니다.

curl -k -sD - -o /dev/null https://example.com/ | \
grep -Ei "HTTP/|server:|cf-ray:|cf-cache-status:|cache-control:|cf-apo|x-cache"

예를 들어 다음과 같은 항목을 확인할 수 있습니다.

server: cloudflare
cf-cache-status: DYNAMIC
cache-control: max-age=0
cf-ray: xxxxxxxxxxxx-XXX

저는 예전에 Cloudflare APO를 사용했지만 현재는 해지한 상태였기 때문에 APO 관련 헤더가 보인다고 해서 현재 APO가 실제 캐시를 제공한다고 단정하지 않았습니다.

특히 CF-Cache-Status: DYNAMIC은 해당 HTML 요청이 Cloudflare Edge Cache에서 단순 HIT로 제공되고 있는 상태는 아니라는 것을 확인하는 데 참고할 수 있습니다.

Windows PC에서도 실제 방문자 기준 TTFB 측정

서버 안에서 테스트하는 것만으로는 부족합니다. 서버가 미국에 있고 실제 방문자는 한국에 있다면 네트워크 경로가 완전히 다르기 때문입니다.

그래서 이번에는 한국에서 사용하는 Windows PC의 명령 프롬프트에서도 직접 측정했습니다.

curl.exe -o NUL -s -w "DNS:%{time_namelookup} CONNECT:%{time_connect} TLS:%{time_appconnect} TTFB:%{time_starttransfer} TOTAL:%{time_total}\n" https://example.com/

실제 측정에서는 대략 다음 범위가 나왔습니다.

DNS: 약 0.01초
CONNECT: 약 0.05~0.07초
TLS: 약 0.17~0.25초
TTFB: 약 1.5~1.9초
TOTAL: 약 1.9~2.3초

DNS나 CONNECT는 상당히 빨랐지만 TTFB가 상대적으로 길었습니다. 브라우저에서 처음 페이지가 뜰 때 답답하게 느껴졌던 이유와 어느 정도 일치했습니다.

Cloudflare를 우회해서 Bluehost 원본 서버와 직접 비교

가장 재미있었던 테스트입니다.

• [블로그 수익화/블로그 SEO] - 코어웹바이탈 개선 URL FID CLS 최적화 속도개선
• [블로그 수익화/블로그 SEO] - 블루호스트 VPS cPanel WHM 속도 최적화 워드프레스 객체 캐시부터 PHP FPM

Windows PC에서도 Cloudflare를 우회하고 Origin 서버 IP에 직접 접속해봤습니다.

curl.exe -k --resolve example.com:443:203.0.113.10 \
-o NUL -s \
-w "ORIGIN CONNECT:%{time_connect} TLS:%{time_appconnect} TTFB:%{time_starttransfer} TOTAL:%{time_total}\n" \
https://example.com/

실제 결과는 대략 다음과 같았습니다.

CONNECT: 약 0.21초
TLS: 약 0.60초
TTFB: 약 0.80초
TOTAL: 약 1.38초

Cloudflare를 거친 결과는 당시 TTFB 약 1.5~1.9초였는데 원본 서버로 직접 연결했을 때는 약 0.8초였습니다.

여기서 주의할 점
이 테스트 한 번만으로 “Cloudflare 자체가 느리다”라고 단정할 수는 없습니다. Cloudflare와 Origin은 접속 경로가 다르고, 어느 Edge 데이터센터를 통했는지, 캐시 HIT 여부와 당시 네트워크 상태도 영향을 받기 때문입니다.

다만 여러 번 반복했을 때 Cloudflare 경유 요청에서만 지연이 크게 튄다면 서버 CPU나 WordPress 플러그인만 계속 의심하기보다는 Cloudflare ↔ Origin 경로와 캐시 설정도 함께 확인할 필요가 있습니다.

Cloudflare를 거친 요청도 5번 반복해서 확인

for i in {1..5}; do
curl -4 \
-H "Cookie: wordpress_logged_in_test=1" \
-o /dev/null -s \
-w "CF RUN$i CONNECT:%{time_connect} TTFB:%{time_starttransfer} TOTAL:%{time_total}\n" \
"https://example.com/?nowprocket&diag=$RANDOM"
done

당시 테스트에서는 약 0.5초대부터 2초 이상까지 차이가 발생했습니다. 앞선 테스트에서는 일시적으로 7~11초 수준까지 튄 적도 있었습니다.

반면 같은 시점 서버 내부 Origin 테스트는 거의 일정했습니다.

이런 식으로 두 결과를 비교하면 서버 안에서 느린지, 서버 밖 네트워크·프록시 구간에서 느린지를 구분하는 데 도움이 됩니다.

이번 워드프레스 느려짐에서 확인한 결과

점검 항목	결과	판단
CPU	Idle 약 94%	과부하 아님
RAM	여유 메모리 충분	RAM 부족 아님
Swap	사용하지 않음	메모리 압박 낮음
MySQL	대기 쿼리 거의 없음	DB 적체 가능성 낮음
서버 내부 Origin	약 0.007~0.008초	서버/캐시 응답 매우 빠름
한국 → Origin	TTFB 약 0.8초	비교적 정상
한국 → Cloudflare → 사이트	TTFB 약 1.5~1.9초, 간헐적 증가	추가 확인 대상

그렇다면 플러그인을 삭제해야 할까?

이번 점검만 놓고 보면 저는 바로 플러그인을 삭제하지 않았습니다.

서버 CPU와 RAM이 충분했고 MySQL 쿼리도 쌓이지 않았으며, Origin 서버에서의 응답이 반복해서 매우 빨랐기 때문입니다.

물론 플러그인이 외부 API 요청이나 cron 작업을 통해 간헐적으로 문제를 만들 가능성까지 완전히 배제할 수는 없습니다. 하지만 아무 근거 없이 플러그인 20~30개를 하나씩 비활성화하는 것보다는 먼저 서버와 네트워크 구간을 측정하는 쪽이 훨씬 효율적이었습니다.

Cloudflare를 잠깐 끄고 비교하는 방법

여러 테스트에서 Cloudflare 경유 시 지연이 의심된다면 진단 목적으로 Cloudflare DNS의 Proxy를 잠시 해제해 비교할 수도 있습니다.

Cloudflare에서 다음 메뉴로 이동합니다.

Cloudflare → DNS → Records → 도메인 A 레코드 → Proxy status

현재 주황색 구름인 Proxied를 잠시 DNS only로 변경하면 방문자가 Cloudflare Proxy를 거치지 않고 Origin 서버로 직접 접속합니다.

다만 이 상태에서는 Cloudflare WAF, CDN, 캐시, 일부 보안 기능도 함께 빠지므로 영구 설정이라기보다 문제 원인을 비교하기 위한 짧은 테스트로 사용하는 것이 좋습니다.

Cloudflare를 완전히 끄는 것보다 HTML Edge Cache도 생각해볼 수 있다

Cloudflare를 사용한다고 무조건 워드프레스 HTML이 Edge에서 바로 제공되는 것은 아닙니다. 일반적인 정적 이미지, CSS, JS 파일은 캐시 효과를 받기 쉽지만 워드프레스 HTML 페이지는 설정에 따라 Origin까지 다시 요청할 수 있습니다.

그래서 공개 블로그처럼 로그인하지 않은 방문자에게 대부분 같은 HTML을 보여주는 사이트라면 Cloudflare Cache Rules 등을 이용해 공개 페이지 HTML을 Edge Cache하는 방법도 생각해볼 수 있습니다.

단 다음 페이지까지 무조건 Cache Everything으로 처리하는 것은 추천하지 않습니다.

• /wp-admin/
• /wp-login.php
• /wp-json/
• 미리보기 페이지
• 로그인 사용자 페이지
• 장바구니 및 회원 개인화 페이지

블로그처럼 비로그인 방문자가 대부분인 사이트와 쇼핑몰·회원제 워드프레스는 캐시 전략이 완전히 다르기 때문에 자신의 사이트 성격에 맞춰 적용하는 것이 중요합니다.

WHM Terminal 붙여넣기 시 ^[[200~ 오류가 나온다면

이번 점검 중 WHM 웹 터미널에 명령어를 붙여넣을 때 다음과 같은 오류도 경험했습니다.

^[[200~curl ...
command not found

이것은 curl이나 서버가 고장난 것이 아니라 브라우저 기반 터미널에서 Bracketed Paste 제어문자가 명령어 앞에 같이 들어간 경우입니다.

짧은 명령어는 직접 타이핑하거나 필요한 경우 현재 쉘 세션에서 다음 설정을 사용할 수 있습니다.

bind 'set enable-bracketed-paste off'

또 화면에 출력된 cf-cache-status: DYNAMIC 같은 결과를 다시 명령어처럼 입력하면 당연히 command not found가 나오므로 검사 명령어와 출력 결과를 구분하는 것도 중요합니다.

워드프레스가 느릴 때 제가 확인하는 순서

이번에 직접 확인해보니 무작정 플러그인을 끄는 것보다 아래 순서가 훨씬 효율적이었습니다.

1. uptime → 서버 Load 확인
2. top → CPU·RAM·I/O Wait 확인
3. free -h → 메모리와 Swap 확인
4. ps aux → CPU·메모리 많이 사용하는 프로세스 확인
5. SHOW FULL PROCESSLIST → MySQL 적체 확인
6. curl → 실제 TTFB 확인
7. 127.0.0.1 → Origin 내부 응답 확인
8. Cloudflare IP별 반복 테스트
9. 한국 PC에서 실제 방문자 기준 TTFB 확인
10. Origin IP 직접 접속과 Cloudflare 경유 결과 비교

이 순서로 확인하면 적어도 서버 문제인지, 워드프레스 문제인지, 데이터베이스 문제인지, CDN·네트워크 문제인지 범위를 상당히 좁힐 수 있습니다.

서버가 느리다고 VPS부터 업그레이드할 필요는 없었다

이번에 가장 크게 느낀 점은 사이트가 느리다고 해서 무조건 CPU나 RAM을 늘릴 필요는 없다는 것이었습니다.

제 경우 서버를 확인했을 때 CPU의 90% 이상이 놀고 있었고 RAM도 충분히 남아 있었습니다. 그런 상태에서 VPS CPU를 4코어에서 8코어로 늘리거나 RAM을 더 추가해도 네트워크 구간의 TTFB 지연은 해결되지 않습니다.

월 서버 비용만 늘어나고 실제 사이트 속도는 그대로일 수도 있습니다.

그래서 워드프레스 속도가 갑자기 느려졌다면 PageSpeed Insights 점수만 보거나 플러그인만 만지기보다 TTFB를 Origin과 CDN으로 나눠 실제 숫자로 측정해보는 것을 추천합니다.

워드프레스 서버 느려짐 점검 명령어 모음

마지막으로 이번에 사용했던 주요 명령어를 한 번에 정리했습니다.

서버 상태

uptime
top
free -h
swapon --show
df -h
df -i

CPU·메모리 프로세스

ps aux --sort=-%cpu | head -20
ps aux --sort=-%mem | head -20

MySQL 상태

mysql -e "SHOW FULL PROCESSLIST;"
mysqladmin status

사이트 TTFB

curl -k -o /dev/null -s \
-w "TTFB:%{time_starttransfer}\nTOTAL:%{time_total}\n" \
https://example.com/

DNS·TCP·TLS·TTFB 세부 측정

curl -4 -o /dev/null -s \
-w "DNS:%{time_namelookup} CONNECT:%{time_connect} TLS:%{time_appconnect} TTFB:%{time_starttransfer} TOTAL:%{time_total}\n" \
https://example.com/

서버 내부 Origin 직접 테스트

curl -k --resolve example.com:443:127.0.0.1 \
-o /dev/null -s \
-w "ORIGIN TTFB:%{time_starttransfer} TOTAL:%{time_total}\n" \
https://example.com/

Cloudflare IP 확인

dig +short example.com A

Cloudflare 응답 헤더

curl -k -sD - -o /dev/null https://example.com/ | \
grep -Ei "HTTP/|server:|cf-ray:|cf-cache-status:|cache-control:|x-cache"

Windows에서 Origin 직접 비교

curl.exe -k --resolve example.com:443:203.0.113.10 \
-o NUL -s \
-w "ORIGIN CONNECT:%{time_connect} TLS:%{time_appconnect} TTFB:%{time_starttransfer} TOTAL:%{time_total}\n" \
https://example.com/

마무리 후기

처음에는 워드프레스 글도 많고 플러그인도 여러 개 사용하다 보니 이번에도 PHP나 MySQL이 과부하에 걸린 줄 알았습니다.

그런데 WHM Terminal에서 실제 숫자를 하나씩 확인해보니 CPU와 메모리는 여유가 있었고 MySQL에도 쿼리가 밀리지 않았습니다. 서버 내부 응답도 매우 빨랐습니다.

반면 외부에서 Cloudflare를 거쳐 접속했을 때는 TTFB가 1~2초 이상으로 늘어나거나 특정 테스트에서는 훨씬 크게 튀는 현상이 확인됐습니다.

결국 이번 경험을 통해 느낀 것은 “워드프레스가 느리다 = 무조건 플러그인 문제”는 아니라는 점입니다.

CPU, RAM, MySQL, PHP, Origin, Cloudflare를 단계별로 분리해서 측정하면 서버 업그레이드나 플러그인 삭제처럼 큰 변경을 하기 전에 어느 구간이 실제로 느린지 상당히 정확하게 좁힐 수 있습니다.

저라면 앞으로도 워드프레스가 갑자기 느려지면 가장 먼저 uptime과 top을 확인하고, 그다음 curl로 Origin TTFB와 Cloudflare TTFB를 비교할 것 같습니다. 이번에는 이 방법이 원인을 찾는 데 가장 도움이 됐습니다.

워드프레스 느려짐 관련 FAQ

워드프레스 TTFB가 2초 이상이면 느린 건가요?

일반적인 블로그라면 첫 HTML 응답이 1~2초를 계속 넘는 경우 체감상 답답해질 수 있습니다. 다만 서버 위치, 로그인 여부, 캐시 상태, 페이지 종류에 따라 차이가 있으므로 한 번의 측정값보다는 같은 조건에서 여러 번 비교하는 것이 좋습니다.

CPU 사용량이 낮은데 워드프레스가 느릴 수도 있나요?

가능합니다. 외부 API 연결을 기다리거나 네트워크 지연, 데이터베이스 Lock, 디스크 I/O, Cloudflare-Origin 통신 지연 등이 발생하면 CPU는 놀고 있는데 사이트만 느릴 수 있습니다.

Cloudflare를 사용하면 무조건 빨라지나요?

이미지, CSS, JS 같은 정적 파일 캐시에는 큰 장점이 있지만 워드프레스 HTML이 Edge에서 캐시되지 않는 구성이라면 Origin 서버까지 다시 왕복해야 합니다. 따라서 서버 위치와 Cloudflare 설정에 따라 HTML TTFB 개선 효과는 달라질 수 있습니다.

사이트가 느리면 플러그인을 모두 비활성화해야 하나요?

저라면 바로 그렇게 하지는 않을 것 같습니다. 먼저 CPU, RAM, MySQL, Origin TTFB를 확인하고 실제로 PHP·WordPress 구간에서 느려지는 것이 확인된 뒤 플러그인을 하나씩 점검하는 편이 훨씬 효율적입니다.

Cloudflare를 잠시 DNS Only로 바꿔도 되나요?

원인 비교를 위한 짧은 테스트라면 사용할 수 있습니다. 다만 Cloudflare Proxy를 끄는 동안 CDN, WAF, 프록시 기반 보안 기능이 적용되지 않을 수 있고 Origin IP가 외부에 직접 노출될 수 있으므로 장시간 유지할 때는 주의가 필요합니다.