Why Purging Nginx Cache Is Only Half the Job (And How I Built the Other Half)

Context

WordPress 플러그인의 기존 캐시 무효화는 캐시 항목만 삭제하고 재구성하지 않아, 포스트 업데이트 직후 첫 방문자가 PHP + DB 라운드트립의 지연 패널티를 받는 문제가 있었다. 특히 블로그, 포트폴리오, WooCommerce 스토어 같은 낮은 트래픽 사이트에서는 매번 업데이트마다 이 콜드 캐시 문제가 반복되었다.

Technical Solution

• 3계층 캐시 무효화 전략 구현: HTTP Purge (ngx_cache_purge 모듈) → URL→파일경로 인덱스 조회 (직접 삭제) → 재귀적 파일시스템 스캔 순서로 단계적으로 시도해 가장 빠른 경로부터 적용
• wget 기반 독립 프리로드 엔진: PHP-FPM 워커를 점유하지 않는 OS 수준 프로세스로 실행해 max_execution_time과 memory_limit 제약을 회피하고 전체 URL 크롤링 수행
• PID 파일 기반 Preload Watchdog: 실행 중인 프로세스 추적과 REST 엔드포인트 (/nppp_nginx_cache/v2/preload-progress)를 통한 대시보드 실시간 진행률 스트리밍 (크롤링 중인 URL, 404 개수, 서버 로드, 경과 시간 표시)
• Vary 헤더 정규화: zlib.output_compression 활성화 시 추가되는 Vary: Accept-Encoding 헤더로 인한 캐시 미스 문제를 해결하기 위해 프리로드 시 동일한 Vary 헤더 상태로 요청 생성
• Bootstrap 아키텍처로 보안 격리: 비인증 요청에서는 플러그인을 완전히 비활성화하고, 관리자 페이지 + 로그인 + 권한 확인 게이트를 통해 인증된 요청에서만 부분 로드하며, REST API와 WP-Cron도 동일한 좁은 실행 게이트 적용
• safexec 권한 강등 모델 (선택사항): PHP-FPM 사용자로 강등해 shell_exec/proc_open 등 PHP 취약점 공격 표면을 감소시키고, 미설치 시 PHP-FPM 사용자로 자동 폴백
• Redis 및 Cloudflare APO 동기화: 파일시스템 캐시 무효화 완료 후 Redis Object Cache 및 Cloudflare APO 캐시도 순차적으로 동기화해 분산 캐시 계층 간 일관성 유지

Key Takeaway

WordPress + Nginx 캐시 환경에서는 캐시 무효화 후 프리로드까지를 하나의 원자적 워크플로우로 설계해야 콜드 캐시 문제를 완전히 해결할 수 있다. 동시에 PHP 워커 블로킹을 피하고 보안 격리를 유지하기 위해 OS 수준 프로세스와 부트스트랩 게이팅 아키텍처를 조합하는 것이 핵심 설계 원칙이다.