개인 NAS에서 WordPress 블로그와 여러 서비스를 함께 운영하다 보면 Cloudflare 설정도 조금씩 늘어납니다.
DNS 레코드, Reverse Proxy, TLS, 캐시, 로그인 보호 규칙이 누적되면 각각은 동작하더라도 전체 운영 기준이 흐려질 수 있습니다.
이번에는 새로운 보안 기능을 추가하기보다 외부 공개가 꼭 필요한 서비스를 다시 구분하고, 남겨야 할 WordPress 블로그의 TLS·캐시·DNS 정책을 정리했습니다. Cloudflare Tunnel도 검토했지만, 현재 서비스 구성과 호환성을 고려해 즉시 도입하지 않고 2차 개선 과제로 남겼습니다.
이 글은 특정 설정값을 모든 NAS 환경에 적용하는 방법이 아닙니다. 서비스별 공개 필요성, 앱 호환성, 인증 방식, 장애 발생 시 되돌릴 방법을 기준으로 정리한 개인 운영 기록입니다.
Cloudflare의 역할과 적용 범위
Cloudflare는 방문자와 원본 서버 사이에서 DNS, HTTPS 연결, 캐시, 리디렉션, 보안 규칙 등을 관리할 수 있는 서비스입니다. WordPress 블로그를 Cloudflare의 Proxied 상태로 운영하면 방문자 요청은 먼저 Cloudflare를 거친 뒤 원본 NAS에 전달됩니다.
이 과정에서 정적 파일 캐시, HTTPS 리디렉션, WAF 규칙, Rate Limiting 같은 기능을 적용할 수 있습니다.
다만 Cloudflare가 NAS 운영, WordPress 업데이트, 계정 보안, 백업을 대신해 주는 것은 아닙니다. 원본 서버와 WordPress 자체의 보안 관리도 계속 필요합니다.
DNS only 상태에서는 Cloudflare가 DNS 응답만 제공하고, 방문자의 HTTP(S) 요청은 원본 서버로 직접 전달됩니다.
따라서 원본 IP가 노출될 수 있고 Cloudflare의 캐시·WAF·프록시 보호도 적용되지 않습니다. DNS only가 앱 호환성에 필요할 수는 있지만, 외부 공개 필요성과 별도 접근 통제를 함께 검토해야 합니다.
Cloudflare의 Proxy status 공식 문서
외부 공개 서비스와 접근 경로 정리
Cloudflare 설정을 바꾸기 전에 먼저 확인한 것은 각 서비스가 인터넷에 직접 공개될 필요가 있는지였습니다.
판단 기준은 다음과 같습니다.
- 외부에서 반드시 사용해야 하는 서비스인가
- WireGuard 같은 VPN으로 대체할 수 있는가
- Cloudflare의 HTTP(S) 프록시와 호환되는가
- 외부 공개를 유지할 때 DNS, 인증서, 접근 제어 관리가 늘어나는가
이 기준으로 Router 관리 기능, Transmission, WebDAV처럼 개인 원격 접속 성격이 강한 서비스는 외부 공개와 DSM Reverse Proxy 구성을 제거하고 VPN 전용으로 전환했습니다.
사용하지 않는 백업 서비스의 공개 도메인과 DNS 레코드도 함께 제거했습니다.
외부 접속을 모두 없앤 것은 아닙니다. 공개 목적이 분명한 WordPress 블로그는 유지했습니다.
다만 서비스별 공개 목적과 접근 방법을 분리하니 관리해야 할 도메인, Reverse Proxy, 포트포워딩 정책도 줄어들었습니다.
외부 공개 경로를 줄이는 기준은 포트포워딩 보안과도 연결됩니다.
필요한 포트만 남겨야 하는 이유는 ipTIME 포트포워딩 보안, 홈서버는 꼭 필요한 포트만 열어야 하는 이유에서 확인할 수 있습니다.
VPN 전용으로 전환한 서비스는 인터넷에 직접 공개하는 대신, 인증된 개인 기기에서 내부망으로 접속하는 방식을 사용합니다. WireGuard를 이용한 외부 PC의 NAS 접속 방법은 ipTIME WireGuard VPN으로 외부 PC에서 집 NAS에 접속하는 방법을 참고하면 됩니다.
DNS 레코드 및 Reverse Proxy 구성 정리
DNS 레코드는 단순한 주소 목록이 아닙니다. 하나의 레코드가 남아 있으면 그 이름이 어느 서비스에 연결되는지, 인증서와 프록시 상태는 어떤지, 계속 관리해야 하는지 확인할 대상이 됩니다.
이번 정리에서는 사용하지 않는 공개 도메인과 DNS 레코드를 제거했고, VPN 전용으로 전환한 서비스의 DSM Reverse Proxy도 함께 제거했습니다. 서비스만 중단하고 연결 정보가 남아 있으면 나중에 점검할 때 혼란이 생길 수 있기 때문입니다.
Proxied와 DNS only의 서비스별 적용 기준
Proxied 상태에서는 Cloudflare가 방문자와 원본 서버 사이에 위치합니다. HTTP(S) 요청에 캐시, WAF, 리디렉션 규칙 같은 Cloudflare 기능을 적용할 수 있습니다.
반면 DNS only는 DNS 질의에 원본 서버의 실제 IP 주소가 응답되는 방식입니다. Cloudflare 프록시를 거치지 않으므로 HTTP 캐시와 WAF, 프록시 기반 보호를 받을 수 없습니다. 원본 IP 공개를 감수할 이유가 분명할 때만 선택해야 합니다.
Cloudflare의 DNS only 동작 설명
WordPress 블로그처럼 일반 웹 트래픽과 호환되는 서비스는 Proxied 상태를 유지했습니다. 이처럼 특정 NAS 앱이나 프로토콜은 Cloudflare 프록시와의 호환성을 먼저 확인한 뒤 적용 여부를 판단해야 합니다.
DNS only를 유지한 앱 호환성 사례는 Synology DS audio 앱 로그인 오류 해결기: Cloudflare Proxied와 DNS only 차이에서 자세히 다뤘습니다.
DNS only가 필요한 서비스라면 다음 항목을 별도로 확인하는 편이 좋습니다.
- HTTPS 연결을 지원하는지
- 외부 접속에 별도 인증, VPN 또는 접근 제어가 있는지
- 원본 IP 공개를 감수할 이유가 분명한지
- 현재도 외부 공개가 필요한 서비스인지
방문자 구간과 원본 구간의 TLS 정책
이번 정리에서 유지한 SSL/TLS 설정은 Full (strict), Universal SSL, Always Use HTTPS, TLS 1.3, 최소 TLS 1.2입니다.
Full (strict)과 원본 인증서 검증
Full (strict)은 방문자와 Cloudflare 사이만 HTTPS로 암호화하는 데서 끝나지 않습니다. Cloudflare와 원본 서버 사이도 암호화하고, 원본 서버 인증서의 유효 기간과 도메인 이름 일치 여부 등을 확인합니다.
원본 인증서 조건이 맞지 않으면 방문자에게 526 오류가 나타날 수 있습니다.
Cloudflare의 Full (strict) 공식 안내
이 설정은 원본 인증서 관리가 필요하다는 뜻이기도 합니다.
인증서 문제로 WordPress 블로그 접속이 막혔던 사례는 워드프레스 블로그 접속 불가, Cloudflare 526 오류 해결 기록에서 확인할 수 있습니다.
최소 TLS 1.2 적용 범위
최소 TLS 버전을 1.2로 설정한 것은 오래된 TLS 방식으로 Cloudflare에 접속하는 방문자를 제한하기 위한 선택입니다. 이 설정은 Cloudflare 프록시를 통과하는 HTTPS 연결에 적용되며, Cloudflare와 원본 NAS 사이의 TLS 설정을 직접 바꾸는 항목은 아닙니다.
최소 버전을 TLS 1.2로 설정하면 TLS 1.0과 TLS 1.1 기반 연결은 허용되지 않으며, TLS 1.2 이상을 지원하는 방문자는 접속할 수 있습니다.
Cloudflare Minimum TLS Version 문서
TLS 1.3도 유지했지만, 모든 방문자가 TLS 1.3을 사용해야 한다는 뜻은 아닙니다. 최소 TLS 1.2라는 기준 안에서 호환 가능한 연결을 허용하는 방식입니다.
Certificate Transparency Monitoring의 역할과 한계
Certificate Transparency Monitoring과 이메일 알림도 활성화했습니다. 이 기능은 모니터링 중인 도메인을 포함하는 인증서가 발급되고 공개 CT 로그에 기록되었을 때 알림을 보내는 방식입니다.
다만 유사 철자의 피싱 도메인 발급까지 찾아내는 기능은 아니며, Cloudflare가 발급한 인증서는 기본적으로 알림에서 제외됩니다.
Cloudflare CT Monitoring 문서
알림이 오면 발급 기관, 도메인 이름, 유효 기간이 예상한 범위인지 확인하는 용도로 사용하고 있습니다. 알림만으로 모든 인증서 관련 위험을 막을 수 있다고 보기는 어렵습니다.
HSTS 적용 전 하위 도메인 호환성 검토
HSTS는 브라우저가 이후 HTTPS로만 접속하도록 기억시키는 설정입니다. 편리해 보이지만, 넓은 범위로 적용하면 HTTP만 지원하는 하위 도메인이나 인증서 구성이 불완전한 서비스까지 영향을 받을 수 있습니다.
따라서 DNS only 여부만으로 HSTS를 판단하기보다, 실제로 사용하는 모든 하위 도메인의 HTTPS 지원, 인증서 상태, 앱 호환성을 점검한 뒤 검토하는 편이 안전합니다. 이번 1차 정리에서는 이 검증을 마치지 않았으므로 HSTS는 보류 항목으로 남겼습니다.
정적 파일과 동적 응답의 캐시 정책 분리
WordPress에서 캐시는 단순히 속도를 높이는 기능이 아니라, 어떤 응답을 누구에게 재사용해도 되는지 결정하는 정책에 가깝습니다.
이번에는 이미지, CSS, JavaScript 같은 정적 파일에만 Edge TTL 1개월과 브라우저 TTL 7일을 적용했습니다. Edge TTL은 Cloudflare 네트워크에서 리소스를 캐시하는 최대 시간이고, Browser TTL은 방문자 브라우저의 캐시 기간입니다.
브라우저 캐시는 Cloudflare 캐시를 비워도 즉시 사라지지 않을 수 있습니다. 변경된 CSS, JavaScript, 이미지가 바로 보이지 않는다면 Cloudflare 캐시 삭제와 함께 브라우저 캐시, 파일명 또는 파일 버전 변경 여부를 확인해야 합니다.
Cloudflare Edge and Browser Cache TTL 문서
로그인·관리자·REST API 응답의 캐시 제외
WordPress 관리자와 로그인 화면은 사용자 상태, 쿠키, 권한에 따라 응답이 달라질 수 있습니다. 따라서 HTML 전체를 일괄 캐시하는 방식은 사용하지 않았습니다.
로그인 페이지에서는 DYNAMIC, no-store, private 응답을 확인했고, 정적 이미지 재요청에서는 HIT을 확인했습니다. 이는 당시 확인한 응답 상태이며, 플러그인·테마·캐시 규칙을 바꾸면 다시 점검해야 합니다.
/wp-admin은 /wp-admin/으로 정규화하고, www는 apex 도메인으로 301 리디렉션했습니다. 리디렉션 규칙을 만들었다면 다음도 함께 확인하는 것이 좋습니다.
- 관리자 하위 경로가 의도한 주소로 이동하는지
- 로그인 후 원래 요청한 주소로 정상 복귀하는지
- 필요한 쿼리 문자열이 유지되는지
- REST API, 미리보기, 플러그인 기능에 예상하지 못한 리디렉션이 생기지 않는지
XML-RPC 차단과 로그인 요청 Rate Limiting도 유지했습니다. Rate Limiting은 특정 경로의 반복 요청을 제한하는 데 도움이 될 수 있지만, 설정한 요청 수를 정확하게 보장하는 장치는 아닙니다. Cloudflare도 요청 감지와 카운터 갱신 사이에 일부 추가 요청이 원본 서버에 도달할 수 있다고 안내합니다.
Cloudflare Rate Limiting 문서
Free 플랜에서 가능한 규칙 수와 조건 범위는 바뀔 수 있으므로, 발행 시점에는 실제 콘솔에 표시되는 플랜 범위와 현재 사용 중인 규칙을 다시 확인하는 것이 좋습니다. 이 글에서는 방어 규칙의 구체적인 임계값은 공개하지 않습니다.
Bot Fight Mode 및 HTML 전체 캐시 보류 사유
보안과 캐시 기능은 많이 활성화한다고 항상 운영이 편해지는 것은 아닙니다.
Bot Fight Mode는 정상 방문자, 검색 엔진, 관리자 작업, 특정 플러그인 요청에 미치는 영향을 충분히 검증하지 못해 사용하지 않았습니다. HTML 전체 캐시도 로그인 쿠키, 관리자 기능, 댓글이나 동적 응답과 충돌할 가능성을 고려해 보류했습니다.
이는 해당 기능이 필요 없다는 의미가 아닙니다. 현재 환경에서 정상 동작 여부를 충분히 확인하기 전까지 적용 범위를 넓히지 않겠다는 판단입니다. 추후 적용한다면 로그인 흐름, 모바일 앱, 플러그인, 예외 경로를 먼저 작은 범위에서 점검할 예정입니다.
Cloudflare Tunnel 도입 보류 판단
Cloudflare Tunnel은 NAS나 서버에서 cloudflared가 Cloudflare로 나가는 연결을 만들기 때문에, HTTP(S) 서비스를 공개할 때 인바운드 포트포워딩을 줄일 수 있는 선택지입니다. 공개 호스트 이름을 내부 HTTP 또는 HTTPS 서비스에 연결하는 구조라면 검토할 가치가 있습니다.
Cloudflare Tunnel 공식 안내
다만 Tunnel이 모든 외부 접속 방식을 같은 방식으로 대체하는 것은 아닙니다.
HTTP(S) 및 일반 TCP·UDP 서비스의 적용 차이
WordPress처럼 HTTP(S) 기반 서비스는 Tunnel 전환 검토 대상이 될 수 있습니다. 반면 Electrum, Bitcoin P2P, WireGuard, 특정 NAS 앱처럼 일반 TCP·UDP 클라이언트 연결 또는 앱 고유 동작이 필요한 서비스는 별도 검증이 필요합니다.
Cloudflare는 비HTTP 서비스에 Tunnel을 사용할 수 있는 방법도 제공하지만, 일반 TCP·SSH·RDP 등의 연결은 최종 사용자 측에도 cloudflared 설치와 실행이 필요할 수 있다고 안내합니다. 기존 클라이언트가 원래 주소와 포트로 바로 접속하던 방식을 단순히 바꾸는 작업은 아닙니다.
Cloudflare Tunnel Routing 문서
WireGuard처럼 UDP 기반 VPN을 일반적인 공개 Tunnel로 대체할 수 있다고 전제해서도 안 됩니다. 프로토콜 지원 방식, 클라이언트 요구 사항, 장시간 연결 안정성, 기존 앱의 호환성을 각각 확인해야 합니다.
Cloudflare Tunnel의 2차 개선 과제화
이번 결론은 Tunnel을 포기한 것이 아닙니다. 현재 환경에서 안정성과 호환성을 확인하지 않은 상태로 전환하지 않기로 한 것입니다.
추후 도입 전에는 다음 항목을 확인할 예정입니다.
- 외부 공개가 필요한 HTTP(S) 서비스가 실제로 있는지
cloudflared의 실행 위치, 업데이트, 장애 대응 방법을 관리할 수 있는지- 원본 서비스의 인증서, Host 헤더, 로그인·관리 기능이 정상 동작하는지
- 일반 TCP·UDP 클라이언트가 추가 프로그램 없이 접속해야 하는지
- DNS 변경과 서비스 전환 전후의 되돌리기 절차가 준비되어 있는지.
마무리
이번 작업은 Cloudflare 기능을 최대한 많이 활성화하는 과정이 아니었습니다.
공개할 서비스는 줄이고, 남겨야 할 WordPress 블로그는 TLS·DNS·캐시·로그인 보호를 역할별로 나누어 관리하는 과정이었습니다.
정리하면 다음과 같습니다.
- VPN으로 대체할 수 있는 서비스는 인터넷 공개와 Reverse Proxy를 제거한다.
- 사용하지 않는 DNS 레코드와 공개 도메인은 함께 정리한다.
- WordPress는 Proxied 환경에서
Full (strict)과 HTTPS 정책을 유지한다. - DNS only는 앱 호환성 때문에 필요할 수 있지만, 원본 IP 노출과 보호 범위 축소를 함께 이해한다.
- 캐시는 정적 파일에 제한하고 로그인·관리자·REST API처럼 상태가 달라지는 응답은 분리한다.
- Cloudflare Tunnel은 HTTP(S) 공개 경로를 줄일 가능성이 있지만, 모든 TCP·UDP 서비스와 앱을 즉시 대체하는 해법은 아니다.
Cloudflare 설정에는 하나의 정답이 없습니다.
자신의 서비스가 외부 공개를 정말 필요로 하는지, 프록시와 호환되는지, 문제가 생겼을 때 되돌릴 수 있는지를 먼저 확인하는 과정이 설정값 자체보다 중요하다고 느꼈습니다.