홈 서버 개방의 보안 위협과 Cloudflare 도입 배경
시놀로지(Synology) NAS에 워드프레스나 n8n과 같은 웹 서비스를 구축하고 개인 도메인을 연결하여 외부에 개방하는 순간, 전 세계 해커들의 자동화된 스캐닝 봇(Bot)과 무차별 대입 공격(Brute-force)의 타겟이 됩니다. NAS 자체에도 방화벽 기능이 존재하지만, 공격 트래픽이 이미 우리 집 공유기를 거쳐 NAS의 랜(LAN) 포트까지 도달한 시점에서 방어하는 구조이므로 대규모 디도스(DDoS) 공격이나 악의적인 트래픽 폭주 앞에서는 홈 네트워크 전체가 마비되는 한계를 가집니다.
이러한 물리적인 네트워크 대역폭의 한계를 극복하고 엔터프라이즈급 보안을 무료로 누릴 수 있는 최적의 솔루션이 바로 클라우드플레어(Cloudflare)입니다. 개인이 구매한 도메인의 네임서버(Name Server)를 Cloudflare로 변경하면, 방문자와 나의 NAS 사이에 거대한 글로벌 프록시(Proxy) 서버가 방패막이처럼 개입하게 됩니다.
이를 통해 해커에게는 나의 실제 집 IP 주소가 완벽하게 은닉되며, 정적 이미지 파일들은 전 세계에 흩어진 Cloudflare 엣지(Edge) 서버에서 대신 전송해 주어(CDN) NAS의 부하를 극적으로 낮출 수 있습니다. 본 글에서는 Cloudflare 연동 시 겪게 되는 프로토콜 충돌 문제와, 웹 방화벽(WAF) 설정 시 주의해야 할 치명적인 트러블슈팅 사례를 상세히 다룹니다.
SSL/TLS 암호화 모드 충돌과 무한 리다이렉트(ERR_TOO_MANY_REDIRECTS)
Cloudflare에 도메인을 등록하고 DNS 레코드의 구름 마크를 주황색(프록시 활성화)으로 켜는 과정은 매우 간단합니다. 하지만 연동 직후 웹사이트에 접속해 보면 브라우저에 ‘리다이렉션한 횟수가 너무 많습니다(ERR_TOO_MANY_REDIRECTS)’라는 에러가 출력되며 사이트가 완전히 먹통이 되는 현상을 가장 흔하게 겪게 됩니다.
1. Flexible(가변) 모드의 논리적 함정
이 현상의 원인은 Cloudflare의 기본 SSL/TLS 암호화 설정인 ‘가변(Flexible)’ 모드와 시놀로지 NAS 내부의 HTTPS 강제 리다이렉트 설정이 정면으로 충돌하기 때문입니다. 가변 모드 상태에서는 방문자와 Cloudflare 사이만 HTTPS로 암호화 통신을 하고, Cloudflare가 내 NAS로 데이터를 넘겨줄 때는 암호화를 해제한 HTTP(포트 80)로 접근합니다.
하지만 대부분의 워드프레스 관리자는 보안을 위해 HSTS를 켜두거나 ‘.htaccess’ 파일 등을 통해 HTTP로 들어오는 요청을 무조건 HTTPS(포트 443)로 다시 접속하라고 돌려보냅니다. 그러면 NAS는 Cloudflare에게 HTTPS로 다시 오라고 지시하고, Cloudflare는 방문자에게 HTTPS로 응답한 뒤 다시 NAS에는 HTTP로 접근하는 논리적 무한 반복(루프)이 발생하여 브라우저가 접속을 강제 차단해 버리는 것입니다.
이 치명적인 오류를 해결하기 위해서는 Cloudflare 대시보드의 ‘SSL/TLS’ 메뉴로 이동하여, 암호화 모드를 가변(Flexible)에서 ‘전체(Full)’ 또는 ‘전체 엄격(Full Strict)’으로 변경해야 합니다. 이를 통해 Cloudflare와 내 NAS 사이의 백엔드 통신 구간까지 모두 HTTPS로 일치시켜 주어야만 리다이렉트 루프가 사라지고 정상적인 웹페이지가 출력됩니다.
웹 방화벽(WAF) 구축 시 검색엔진 크롤러 차단 오류
프록시 설정이 완료되면 Cloudflare의 강력한 웹 방화벽(WAF) 규칙을 설정하여 트래픽을 통제할 수 있습니다. 개인 블로그나 국내 타겟의 워드프레스를 운영하는 경우, 악성 트래픽의 99%가 발생하는 해외 IP(중국, 러시아 등)를 원천 차단하기 위해 ‘대한민국(KR)을 제외한 모든 국가 차단’이라는 강력한 WAF 룰을 생성하는 것이 일반적입니다.
1. Known Bots (검색엔진 로봇) 예외 처리 누락의 파장
하지만 국가 기반의 차단 규칙을 적용한 지 며칠 지나지 않아, 구글 서치 콘솔(Google Search Console)에서 ‘페이지 색인을 생성할 수 없음’ 또는 ‘robots.txt를 가져올 수 없음’이라는 붉은색 경고가 쏟아지는 것을 목격하게 됩니다. 검색 유입을 늘리려 구축한 블로그가 구글 검색 결과에서 통째로 사라지는 참사가 벌어지는 것입니다.
이는 구글의 크롤링 봇(Googlebot)이 미국이나 기타 해외 데이터센터의 IP를 사용하여 내 NAS에 접근하기 때문입니다. 방화벽이 해외 IP를 일괄 차단하면서 구글과 빙(Bing)의 검색 로봇까지 적으로 간주하여 접속을 끊어버린 것입니다.
이 문제를 해결하기 위해서는 방화벽 규칙의 우선순위(Priority)를 논리적으로 재배치해야 합니다. 해외 IP를 차단하는 규칙보다 우선순위가 더 높은(목록의 더 위쪽에 위치한) 새로운 WAF 규칙을 생성해야 합니다. 조건 항목에서 ‘Known Bots(알려진 봇)’ 옵션을 선택하고, 작업(Action)을 ‘우회(Skip)’ 또는 ‘허용(Allow)’으로 설정하여 구글 등의 공식 검색엔진 크롤러는 국가 통제 규칙을 거치지 않고 무조건 통과할 수 있도록 백도어(안전 통로)를 뚫어주어야 완벽한 SEO 환경이 유지됩니다.
Page Rules(페이지 규칙) 캐시 최적화와 관리자 페이지 오작동
방화벽 설정 이후에는 CDN의 본질인 캐싱(Caching)을 통한 속도 최적화를 진행하게 됩니다. 워드프레스의 체감 로딩 속도를 극한으로 끌어올리기 위해 Cloudflare의 ‘페이지 규칙(Page Rules)’ 메뉴에서 ‘*mydomain.com/*’ 에 대해 ‘캐시 수준: 모든 항목 캐시(Cache Everything)’를 적용하는 고급 튜닝을 시도하기도 합니다.
이 규칙을 적용하면 HTML 문서 자체를 Cloudflare가 캐싱하여 방문자에게 NAS의 하드디스크 I/O 없이 즉각적으로 화면을 뿌려줍니다. 하지만 곧바로 워드프레스 관리자 페이지(wp-admin)에 로그인이 풀리거나, 글을 수정해도 화면에 반영되지 않고, 다른 방문자에게 관리자 상단 바가 노출되는 등 데이터 정합성이 완전히 붕괴되는 현상을 겪게 됩니다. 동적인 관리자 권한 세션까지 모조리 캐시로 박제해 버렸기 때문입니다.
결론적으로 모든 항목 캐시 기능을 사용하려면, 반드시 워드프레스의 관리자 경로인 ‘*mydomain.com/wp-admin/*’ 및 ‘*mydomain.com/wp-login.php*’에 대해 ‘캐시 수준: 우회(Bypass)’ 규칙을 최상단에 먼저 선언해야 합니다. 관리자 페이지는 절대 캐싱하지 않고 원본 서버(NAS)와 직접 동적으로 통신하게 만들고, 일반 방문자의 프론트엔드 페이지만 캐싱하는 이원화된 규칙 아키텍처를 설계하는 것이 시스템 무결성을 지키는 핵심입니다.
시놀로지 NAS와 Cloudflare의 결합은 하드웨어의 한계를 소프트웨어적 인프라로 극복하는 가장 아름다운 사례입니다. 위에서 언급한 암호화 프로토콜 충돌, 봇 접근 통제, 그리고 동적 캐시 바이패스라는 세 가지 주요 함정을 정확히 이해하고 제어한다면, 월 수십만 원의 유지비가 드는 클라우드 엔터프라이즈 환경에 버금가는 철벽 보안의 홈 서버를 완성할 수 있을 것입니다.
