서버 한 대에서 홈페이지에 핑을 보내는 가동 시간 모니터가 알려주는 것은 단 하나, 그 서버가 사이트에 닿는다는 사실뿐입니다. 챌린지 페이지를 받는 독일 고객이나 CDN 엣지가 오류를 돌려주는 브라질 방문자에 대해서는 아무것도 알려주지 않습니다. 여러 국가에서 판매하거나 검색 순위를 노린다면, 그 국가들에서 가용성과 콘텐츠를 점검하는 일은 SEO 모니터링의 일부이며, 단일 프로브로는 절대 보이지 않는 문제를 잡아냅니다.
이 가이드에서는 한 곳에서 하는 점검이 놓치는 것, 시장별로 테스트할 항목, 출발지 IP가 중요한 이유, 그리고 예약 실행할 수 있는 작은 스크립트를 다룹니다.
한 곳에서 하는 가동 시간 점검이 놓치는 것
프로브 하나에서 본 초록색 상태 페이지는 다음 문제를 모두 가릴 수 있습니다.
- 지역 CDN 장애. CDN은 방문자와 가장 가까운 엣지에서 응답합니다. 다른 엣지는 정상인데 한 엣지만 장애가 나거나 오래된 오류를 내보낼 수 있습니다.
- 망가진 지역 리디렉션. 프랑스 방문자를
/fr/로 보내는 규칙이 무한 반복되거나, 더 이상 없는 페이지를 가리키거나, 한 국가를 엉뚱한 스토어로 보낼 수 있습니다. - 자체 보안 규칙에 의한 국가 단위 차단. 공격 후 강화한 방화벽이나 봇 차단 규칙이 한 지역의 모든 방문자에게 챌린지를 띄우기 시작할 수 있습니다.
- DNS와 라우팅 문제. 지역 DNS가 한 시장을 다운된 오리진으로 보낼 수 있고, 일부 현지 리졸버는 변경 후에도 오래된 레코드를 오래 유지합니다.
- 잘못된 콘텐츠. 페이지는 열리지만 통화가 틀리거나, 동의 배너가 없거나, 언어가 틀리거나, 가격 영역이 비어 있습니다.
이 중 어느 것도 모니터링 서버에서는 “다운”으로 보이지 않습니다. 하지만 모두 방문자와 매출을 잃게 하고, Googlebot도 같은 상황을 만나면 순위까지 잃게 합니다.
시장별로 확인할 항목
국가마다 별도의 사이트처럼 다루세요. 점검할 때마다 다음을 기록합니다.
- 상태 코드와 리디렉션 후 최종 URL. 잘못된 URL에서 받은 200은 실패입니다.
- 응답 시간. 다운되기 전에 느려지는 시장을 알아차리기 위해서입니다.
- 콘텐츠 마커. 올바른 현지 버전에만 나오는 문자열로, 예를 들어 통화 기호, 현지 전화번호, 번역된 제목입니다.
- 차단 신호. 챌린지 페이지 제목, CAPTCHA 양식, 자체 CDN의 403 등입니다.
- 응답한 엣지.
cf-ray,x-amz-cf-pop,x-served-by같은 헤더에서 확인해, 한 지역에 장애가 나면 어디를 봐야 할지 알 수 있습니다.
매출이 나오는 페이지부터 시작하세요. 홈페이지, 주요 카테고리, 상품 페이지, 결제 시작 페이지입니다. 사용자가 의존한다면 검색과 로그인도 추가합니다.
출발지 IP가 중요한 이유
대부분의 상용 가동 시간 서비스는 수십 개 도시의 데이터센터에서 프로브를 실행합니다. “서버가 살아 있는가”를 알기에는 충분하지만, 고객이 실제로 접속하는 방식은 아닙니다. CDN과 봇 차단 규칙은 데이터센터 주소를 가정용 회선과 다르게 처리하는 경우가 많아서, 실제 방문자는 챌린지를 받는데 프로브는 통과하거나, 방문자는 문제가 없는데 프로브만 차단될 수 있습니다.
대상 국가의 레지덴셜 프록시를 통한 점검은 이 간극을 메웁니다. 요청이 그 시장의 가정용 회선에서 나가므로, 지역 DNS와 CDN, 보안 규칙이 현지 고객과 똑같이 처리합니다. 큰 시장에서는 도시 단위까지 좁힐 수 있어서, 예를 들어 미국이라면 한 곳이 아니라 여러 지역에서 점검할 수 있습니다.
역할은 나눠서 보세요. 레지덴셜 점검은 시장마다 무엇이 전달되고 제대로 동작하는지 보는 데 쓰고, 정확한 응답 시간은 데이터센터 모니터나 실사용자 데이터로 측정합니다. 프록시를 거친 요청에는 중계 구간이 하나 더 있기 때문입니다.
작은 다지역 점검기
이 스크립트는 여러 국가에서 URL 목록을 점검하고, 리디렉션을 따라가며 콘텐츠 마커를 찾습니다. USERNAME과 PASSWORD는 본인의 프록시 인증 정보로 바꾸세요.
import requests
USER = "USERNAME"
PASS = "PASSWORD"
GATEWAY = "p.shifter.io:443"
CHECKS = {
"de": ("https://www.example.com/", "€"),
"gb": ("https://www.example.com/", "£"),
"us": ("https://www.example.com/", "$"),
"br": ("https://www.example.com/", "R$"),
}
def check(country, url, marker):
proxy = f"http://customer-{USER}-country-{country}:{PASS}@{GATEWAY}"
try:
r = requests.get(url, proxies={"http": proxy, "https": proxy},
timeout=30, allow_redirects=True)
except requests.RequestException as e:
return country, "ERROR", str(e)[:80]
blocked = "captcha" in r.text.lower() or r.status_code in (403, 429)
ok = r.status_code == 200 and marker in r.text and not blocked
edge = r.headers.get("cf-ray") or r.headers.get("x-amz-cf-pop") or "-"
return country, "OK" if ok else "FAIL", f"{r.status_code} {r.url} edge={edge} {r.elapsed.total_seconds():.2f}s"
for country, (url, marker) in CHECKS.items():
print(*check(country, url, marker))cron이나 CI 스케줄러로 실행하고, 각 줄을 로그나 작은 데이터베이스에 저장한 뒤 실패 시 알림을 보내세요. 결과를 믿을 수 있게 만드는 습관이 두 가지 있습니다.
- 알림 전에 확인하기. 점검이 실패하면 같은 국가의 새 IP로 한 번 다시 시도합니다. 두 번째도 실패할 때만 알림을 보냅니다.
- 한 줄이 아니라 패턴으로 알리기. 한 국가에서 세 번 연속 실패하면 장애입니다. 일주일에 한 번 나는 타임아웃은 잡음입니다.
점검을 루틴으로 만들기
- Search Console과 분석 데이터로 시장을 고릅니다. 트래픽과 매출을 가져오는 국가, 그리고 키우려는 국가입니다.
- 가치에 따라 주기를 정합니다. 주요 시장의 결제 페이지는 몇 분마다, 나머지는 매시간 점검합니다.
- 배포나 CDN 변경 후마다 점검합니다. 사무실에서만이 아니라 모든 시장에서 확인합니다.
- 매주 검토합니다. 어느 국가에서 실패가 가장 많은지, 그 이유는 무엇인지 봅니다.
시장이 다운되지는 않았지만 느리다면, 국가별 웹사이트 속도 테스트 방법 가이드에서 원인을 찾는 법을 다룹니다. 일부 지역에 의도적으로 다른 콘텐츠가 제공된다고 의심된다면, 여러 위치에서 SEO 클로킹을 탐지하는 방법이 같은 국가별 요청을 사용합니다.
결론
가동 시간은 지역마다 다릅니다. 모니터에는 정상이지만 한 국가 전체에서는 다운일 수 있습니다. 중요한 시장마다 매출 페이지를 점검하고, 상태와 최종 URL, 콘텐츠, 차단 신호를 확인하고, 두 번째 IP로 실패를 검증하세요. 그러면 고객이 알려주기 전에 지역 문제를 먼저 알게 됩니다.