운영하다 보면 “AdSense는 노출/수익이 생기는데, 페이지뷰나 일부 지표가 0으로 보이거나 갑자기 급감” 같은 상황이 생깁니다. 특히 Cloudflare(캐시/보안) + Nginx(리버스 프록시/헤더) 조합에서는 스크립트 로딩, 캐시, 보안 헤더가 얽히면서 원인이 여러 갈래로 갈라지기 쉬워요.
아래는 실전 운영 관점에서 “문제 징후 → 원인 → 해결 → 재검증” 순으로 따라가며 좁혀가는 체크 루트입니다.
문제 징후: “수익은 있는데 페이지뷰/태그가 0”일 때 먼저 확인할 것
지표가 0으로 보인다고 해서 실제 트래픽이 0인 건 아닌 경우가 많습니다. 먼저 “무슨 값이 0인지”를 분리해 확인하세요.
- 특정 브라우저(Chrome)에서만 비정상인가? (확장프로그램, 추적 차단, 쿠키 정책 영향)
- 특정 경로만 안 잡히는가? (예: /amp, /blog, /shop 등 캐시 정책이 다른 구간)
- Cloudflare를 우회(직접 오리진)하면 정상인가?
- 새로고침(F5) vs 강력 새로고침에서 결과가 달라지는가? (캐시/서비스워커 의심)
- 콘솔 에러가 있는가? (CSP 차단, mixed content, blocked by client)
이 단계에서 “Cloudflare 우회 시 정상” 또는 “경로별로만 문제”가 확인되면, 대개 캐시/보안/헤더 이슈로 범위를 빠르게 줄일 수 있습니다.
원인 1) Cloudflare 캐시가 스크립트/HTML을 ‘다르게’ 서빙하는 경우
Cloudflare에서 HTML까지 적극 캐시하는 구성(예: Cache Everything, Page Rules/Cache Rules, APO 등)이면, 페이지마다 로딩되어야 할 스크립트 태그가 누락되거나(또는 옛 버전이 고정) 지표가 비정상으로 보일 수 있습니다. 특히 서버 사이드에서 조건부로 광고/태그를 넣는 경우에 더 잘 터집니다.
해결
- Cloudflare에서 HTML 캐시를 쓰는 구간이라면, 문제 구간만 우선 Bypass Cache로 전환해 비교합니다.
- 정말 HTML 캐시가 필요하다면, 광고/태그 삽입 방식(서버 조건 분기, 템플릿 버전)을 점검하고 캐시 키(쿠키/쿼리스트링 포함 여부)를 의도대로 설계합니다.
- Cloudflare에서 Purge(전체/URL 단위) 후에도 재발한다면, 캐시 규칙 우선순위(여러 Rules 충돌)와 “Origin Cache-Control 무시” 옵션을 확인합니다.
재검증
- Chrome DevTools > Network에서 문서(HTML) 응답 헤더의 cf-cache-status가 HIT/MISS/BYPASS 중 무엇인지 확인합니다.
- 문서 응답이 HIT인데도 페이지에 필요한 스크립트가 없으면, 캐시된 HTML 자체가 잘못 굳은 상태일 확률이 큽니다.
원인 2) CSP(콘텐츠 보안 정책) 또는 보안 헤더가 광고/측정을 차단
Nginx에서 CSP를 엄격하게 운영하거나, Cloudflare에서 보안 관련 헤더를 추가/변조하면 외부 스크립트가 조용히 차단될 수 있습니다. 이 경우 페이지는 정상 렌더링되지만 지표가 0처럼 보이기도 합니다.
징후
- DevTools Console에 Content Security Policy 위반 메시지
- Network에 스크립트 요청이 아예 없거나, (blocked:csp)처럼 표시
해결
- 우선 문제 재현 페이지에서 실제로 필요한 도메인들이 무엇인지(스크립트/iframe/img/connect)부터 확인합니다.
- Nginx에서 CSP를 쓴다면, 테스트로 Report-Only 모드로 전환해 차단을 멈추고 로그로만 수집해봅니다.
- Cloudflare에서도 Response Header를 추가하는 설정(Transform Rules 등)이 있다면, Nginx와 중복/충돌이 없는지 확인합니다.
재검증
- Console 에러가 사라졌는지 확인
- Network에서 광고/측정 스크립트가 200으로 내려오는지 확인
원인 3) SSL/HTTPS 혼선(리다이렉트 체인, mixed content, 프록시 구성)
Cloudflare(Edge)와 Nginx(Origin) 사이 SSL 모드가 어긋나면, 리다이렉트 루프나 프로토콜 혼선이 생겨 스크립트 호출이 깨지기도 합니다. 또는 페이지는 https인데 내부 리소스가 http로 남아 mixed content로 막히는 케이스도 있습니다.
해결
- Cloudflare SSL/TLS 모드가 운영 의도에 맞는지 확인합니다. (일반적으로는 Full(Strict) 권장)
- Nginx에서 http→https 리다이렉트, www/non-www 정규화를 할 때 Cloudflare 프록시 환경(예: X-Forwarded-Proto)을 고려해 리다이렉트 체인이 과도하지 않게 정리합니다.
- 사이트 내 스크립트/리소스 URL이 http로 하드코딩된 부분이 없는지 점검합니다.
재검증
- DevTools Network에서 문서 요청이 301을 몇 번 타는지 확인(가능하면 0~1회)
- Console에 mixed content 경고가 없는지 확인
원인 4) Cloudflare Bot/Firewall/WAF가 스크립트 호출 또는 리퍼러 흐름을 막는 경우
Cloudflare의 Bot Fight Mode, WAF 규칙, Firewall Rules가 일부 요청을 “봇”으로 판단해 차단/챌린지를 걸면, 사용자 페이지 렌더링은 되는데 특정 외부 호출이나 내부 엔드포인트가 실패할 수 있습니다(특히 비동기 요청, beacon류).
해결
- Cloudflare 이벤트 로그(보안 이벤트)에서 문제가 발생한 시각의 차단/챌린지 기록을 확인합니다.
- 문제가 특정 경로나 특정 User-Agent에서만 발생하면, 해당 경로에 한해 완화 규칙(Allow/Skip 등)을 검토합니다.
- 너무 공격적인 레이트리밋/봇 규칙을 썼다면, 광고/측정에 필요한 요청까지 막지 않도록 범위를 좁힙니다.
재검증
- 재현 시나리오로 접속했을 때 Cloudflare 챌린지/403/429가 사라졌는지 확인
- 차단 로그가 더 이상 쌓이지 않는지 확인
원인 5) Chrome 환경(확장프로그램/추적 차단/3rd-party 쿠키) 때문에 ‘본인만’ 0으로 보이는 경우
운영자가 보는 Chrome에는 광고 차단 확장프로그램이 깔려 있거나, 브라우저 정책 때문에 일부 요청이 막혀 “나만 0”처럼 보일 수 있습니다. 이 경우 서버/Cloudflare 설정을 아무리 바꿔도 현상이 그대로일 수 있어요.
해결
- Chrome 시크릿 모드(확장 비활성) 또는 새 프로필에서 재현 여부를 먼저 봅니다.
- DevTools Network에서 (blocked:client)류가 보이면 확장프로그램 영향 가능성이 큽니다.
- 가능하면 다른 브라우저/모바일 네트워크에서도 비교해 “환경 의존”인지 분리합니다.
재검증
- 확장프로그램 OFF 후 스크립트 요청이 정상적으로 발생하는지 확인
- 운영자 개인 환경이 아닌 외부 사용자 기준으로도 문제가 있는지 확인
마무리
“AdSense는 잡히는데 페이지뷰/지표가 0” 같은 상황은 대개 Cloudflare 캐시(HTML 포함) → CSP/보안 헤더 → SSL/리다이렉트 → WAF/봇 규칙 → Chrome 로컬 환경 순서로 좁혀가면 빨리 결론이 납니다.
한 번에 다 바꾸기보다, 우회(캐시 bypass/Cloudflare off/시크릿 모드)로 원인 범위를 먼저 확 줄인 뒤, 해당 구간만 최소 변경으로 고치는 방식이 운영 스트레스를 가장 줄여줍니다.