블로그로 돌아가기
2025년 11월 14일Sergei Solod2 분 읽기

왜 내 사이트는 러시아에서 거의 트래픽을 받지 못했을까

문제는 수요가 아니었다. 원인은 Cloudflare, 러시아 측 차단, 그리고 결국 접근을 되살린 마이그레이션이었다.

DevOpsSEONginxCloudflare문제 해결인프라

💔 Roskomnadzor가 어떻게 내 러시아 트래픽을 실수로 날려버렸나! 한 개발자의 SEO 이야기

최근 SEO 프로젝트에서 나는 Cloudflare에 의존하고 있었다. 업계 표준이니까 당연히 괜찮을 거라고 생각했다. 그런데 2025년 여름, Roskomnadzor의 조용한 차단 때문에 러시아 사용자들이 내 사이트에 접근하는 길이 크게 막혀 있었다. 뼈아픈 교훈은 분명했다. 중요한 시장이라면 인프라는 결국 직접 통제해야 한다는 것이다.

사라진 트래픽의 수수께끼

나는 해외에 거주하는 프론트엔드 개발자로, 실력을 더 끌어올리기 위해 대규모 SEO 프로젝트를 만들고 있었다. 숫자만 보면 상황은 좋아 보였다. Yandex가 무려 12,500페이지를 색인하고 있었기 때문이다.

하지만 실제 러시아 트래픽은 거의 0에 가까웠다.

보이지 않는 벽

그래서 문제를 파고들기 시작했다. 원인은 내 코드도, SEO 전략도 아니었다. 문제는 네트워크 레이어에 있었다.

알고 보니 Roskomnadzor가 특정 Cloudflare IP 대역의 트래픽을 차단하고 있었다. 나는 러시아에 있지 않았기 때문에, 러시아 주요 ISP를 쓰는 수천 명의 사용자에게 내 사이트가 사실상 먹통이었다는 걸 알아차릴 방법이 없었다. 내 "성능 레이어"는 어느새 방화벽이 되어 있었다.

해결책: Nginx와 VDS

이 문제를 해결하려면 중간 단계를 없애야 했다.

  1. Cloudflare 비활성화: 프록시를 완전히 껐다.
  2. 보안과 캐시 재구성: 이전에 무료로 받던 핵심 기능, 즉 캐싱, 압축, 기본 보안을 직접 구현하기 위해 내 VDS에 Nginx를 수동으로 설정했다.

결과: 접근은 즉시 복구됐다. 이제 12,500페이지 전체가 러시아 연방에서 다시 열린다.

교훈

규제가 강한 시장에서는 Cloudflare처럼 "설정해 두고 잊어버리는" 서비스가 오히려 리스크가 될 수 있다. 결국 가장 안전한 선택은 옛날 방식인 경우가 많다. 즉, 처음부터 끝까지 직접 통제할 수 있는 고도로 맞춤화된 VDS + Nginx 구성이다. 사용자가 공급자 차단의 부수적 피해를 입지 않게 해야 한다.