Synology DSM의 Reverse Proxy를 설정하는 방법 자체는 단순하다.
예를 들어:
app.example.com → 127.0.0.1:8080
같은 규칙을 만들면 사용자는 포트번호 대신 도메인으로 애플리케이션에 접근할 수 있다.
하지만 production 운영에서 reverse proxy의 목적은 주소를 예쁘게 만드는 것이 아니다.
인터넷에서 들어오는 요청이 어떤 서비스에 어떤 조건으로 도달할지를 통제하는 ingress layer를 만드는 것이다.
요청은 다섯 단계를 거친다고 생각하면 쉽다
외부 사용자가 https://app.example.com에 접근하는 흐름을 단순화하면:
DNS → Public Edge/Router → TLS/Reverse Proxy → Origin Service → Application
이다.
문제가 생겼을 때도 이 순서로 확인하면 원인을 빠르게 좁힐 수 있다.
1. DNS: 도메인이 어디를 가리키는가
Reverse Proxy를 아무리 잘 설정해도 DNS가 잘못된 IP를 가리키면 요청은 NAS에 도달하지 않는다.
따라서 먼저:
- FQDN이 어떤 public endpoint를 가리키는가
- A/AAAA 또는 CNAME이 의도한 값인가
- Cloud proxy/CDN을 사용하는가
- DNS 변경 후 기존 cache가 남아 있지 않은가
를 확인한다.
Synology의 공식 reverse proxy 안내에서도 사용하는 FQDN이 올바른 external endpoint로 resolve되어야 한다고 설명한다.
2. TLS: 인증서는 사용자가 접속하는 이름과 맞아야 한다
HTTPS의 목적은 자물쇠 아이콘 하나를 보여주는 것이 아니다.
사용자가 접속한 hostname이 실제 certificate의 대상인지 확인하고 client와 ingress 사이의 통신을 암호화한다.
여러 subdomain을 운영하면:
- 서비스별 certificate
- wildcard certificate
- edge provider의 certificate
등을 사용할 수 있다.
중요한 것은 실제 TLS termination 위치와 origin까지의 구간이 어떻게 보호되는지 이해하는 것이다.
TLS가 Edge에서 끝난다고 Origin 구간을 무조건 HTTP로 둘 필요는 없다
Cloudflare 같은 외부 proxy를 사용하면 client와 edge 사이에는 HTTPS가 적용될 수 있다.
하지만 edge와 NAS origin 사이를 HTTP로 구성하면 그 구간은 별도의 trust boundary가 된다.
환경에 따라 origin까지 HTTPS를 유지하거나 private tunnel/network를 사용하는 방식도 검토할 수 있다.
어떤 구조를 선택하든:
어디에서 암호화가 시작되고 어디에서 끝나는지
운영자가 정확히 알아야 한다.
3. Reverse Proxy: Hostname을 올바른 Origin으로 보내는가
Reverse Proxy는 source hostname과 port를 보고 내부 destination으로 요청을 전달할 수 있다.
예를 들어:
| Public Host | Origin |
|---|---|
| blog.example.com | 127.0.0.1:8081 |
| media.example.com | 127.0.0.1:8096 |
| dev.example.com | 127.0.0.1:8088 |
이렇게 하면 외부에서는 모두 HTTPS 443을 사용하더라도 내부 application은 서로 다른 port에서 실행할 수 있다.
Origin Port를 public internet에 다시 열면 Reverse Proxy 경계가 약해진다
blog.example.com이 reverse proxy를 통해 8081로 연결된다고 하자.
그런데 공유기에서 8081도 인터넷에 직접 port forwarding되어 있다면 공격자는 reverse proxy를 거치지 않고 origin service에 직접 접근할 수 있을 수 있다.
그러면 reverse proxy에 설정한:
- TLS 정책
- Access Control
- 추가 인증
- Logging
을 우회할 가능성이 생긴다.
그래서 가능한 경우 origin은 localhost 또는 내부 network에서만 접근하도록 하고 외부 ingress는 의도한 proxy path로 제한하는 편이 좋다.
‘포트를 숨긴다’는 표현이 위험한 이유
Reverse Proxy를 쓰면 사용자가 내부 8081 같은 port를 직접 입력하지 않아도 된다.
하지만 port 번호가 보이지 않는다고 서비스가 안전해지는 것은 아니다.
실제 보안은:
- origin이 직접 노출되는지
- 누가 proxy endpoint에 접근할 수 있는지
- application 인증이 있는지
- TLS와 patch가 적절한지
가 결정한다.
보이지 않는 port는 security control이 아니다.
Public Service와 Admin Service는 같은 Reverse Proxy 정책을 쓰지 않는다
공개 WordPress는 누구나 접근해야 한다.
반면 DSM, code-server, 내부 monitoring 도구는 관리자만 접근하면 된다.
따라서 같은 reverse proxy 기능을 사용하더라도 노출정책은 달라야 한다.
| 서비스 | 권장 접근개념 |
|---|---|
| Public website | 공개 HTTPS ingress |
| DSM/SSH | Private VPN 또는 제한된 management path |
| code-server | Private access 또는 강한 추가 인증 |
| 개인 media | 허가된 사용자 범위 |
모든 것을 something.example.com으로 만들 수 있다는 이유만으로 모두 internet-public으로 만들 필요는 없다.
Synology Reverse Proxy에는 Access Control Profile도 연결할 수 있다
현재 DSM의 Login Portal > Advanced에서는 Reverse Proxy와 함께 Access Control Profile을 관리할 수 있다.
이를 이용해 network 조건 등에 따라 접근범위를 제한할 수 있다.
다만 IP 제한 하나만으로 application 인증을 대체한다고 생각해서는 안 된다.
Reverse Proxy 접근제어와 application 자체의 authentication은 서로 다른 방어층으로 보는 편이 좋다.
WebSocket을 사용하는 서비스는 별도 확인이 필요하다
단순 웹페이지는 잘 열리는데 code-server, 실시간 dashboard, 특정 video service의 연결이 끊기는 경우가 있다.
이런 application은 WebSocket을 사용할 수 있다.
Synology도 Reverse Proxy 환경에서 WebSocket 문제가 발생할 때 custom WebSocket header 설정을 확인하도록 안내한다.
따라서:
- HTTP 페이지 로딩
- WebSocket upgrade
- long-lived connection
을 별도로 검증해야 한다.
Host Header도 Application 동작에 영향을 줄 수 있다
Origin application이 자신이 어떤 hostname으로 호출되었는지 알아야 absolute URL, redirect 또는 cookie를 올바르게 만들 수 있다.
Reverse Proxy가 Host와 forwarding header를 예상과 다르게 전달하면:
- HTTP↔HTTPS redirect loop
- 잘못된 canonical URL
- 로그인 cookie 문제
- application-generated link 오류
가 발생할 수 있다.
따라서 proxy 문제를 단순히 “502가 나는가”로만 검증해서는 안 된다.
502 오류는 Domain 문제가 아닐 수도 있다
Reverse Proxy에서 502 Bad Gateway가 발생하면 DNS부터 다시 만지는 경우가 있다.
하지만 client가 이미 Synology proxy까지 도달했다면 문제는 그 다음 단계일 수 있다.
확인 순서는:
- Origin container/process가 실제 실행 중인가
- 예상 port에서 listen하는가
- Proxy host에서 origin으로 연결 가능한가
- HTTP/HTTPS protocol 설정이 origin과 맞는가
- Application health endpoint가 정상인가
이다.
즉 DNS → Proxy → Origin을 단계별로 분리해야 한다.
Container를 localhost에만 publish하면 공격면을 줄일 수 있다
Container service가 같은 NAS의 reverse proxy를 통해서만 사용될 예정이라면 host port를:
127.0.0.1:8181:80
처럼 loopback에만 publish하는 구조를 사용할 수 있다.
그러면 NAS LAN IP의 8181로 직접 접근되는 범위를 줄이고 reverse proxy가 사실상 의도한 entry point가 된다.
다만 Container networking 구조와 실제 proxy가 origin에 접근하는 방식을 먼저 확인해야 한다.
Reverse Proxy 변경에는 Rollback 지점이 필요하다
운영 사이트의 domain routing을 한 번에 바꾸면 잘못된 destination이나 certificate 설정 때문에 모든 사용자가 영향을 받을 수 있다.
특히 새 플랫폼으로 cutover할 때는:
- 기존 origin
- 신규 origin
- 변경 전 route
- 변경 후 verification
을 명확히 기록한다.
신규 origin이 정상이라는 것이 확인되기 전에는 기존 서비스와 rollback path를 제거하지 않는 편이 안전하다.
Cutover 후에는 페이지 하나만 열어보면 부족하다
최소한 다음 계층을 검증한다.
- DNS가 의도한 endpoint를 가리키는가
- HTTPS certificate가 정상인가
- 올바른 origin으로 연결되는가
- redirect가 예상대로인가
- login·POST·upload 같은 dynamic request가 동작하는가
- WebSocket이 필요한 서비스는 연결되는가
- 직접 origin port가 불필요하게 공개되지 않았는가
Reverse Proxy와 Backup은 다른 문제다
Reverse Proxy 설정을 잘 관리해도 application data가 보호되는 것은 아니다.
반대로 data backup이 완벽해도 DNS와 certificate, proxy route를 복구하지 못하면 사용자는 서비스에 접근하지 못한다.
따라서 서비스 복구에는 최소:
Application Data + Runtime Configuration + DNS + TLS + Reverse Proxy Route
가 모두 필요하다.
결론
Synology Reverse Proxy는 “서브도메인을 내부 port에 연결하는 기능”보다 넓게 봐야 한다.
운영 흐름은:
DNS → TLS → Public/Private Access Policy → Reverse Proxy → Origin → Application Verification
이다.
그리고 origin service를 직접 공개하지 않고, 공개해야 할 서비스와 관리용 서비스를 분리하며, WebSocket과 header까지 application 요구에 맞게 검증해야 한다.
좋은 Reverse Proxy 설계는 port 번호를 숨기는 것이 아니라 NAS로 들어오는 모든 외부 요청이 의도한 하나의 통제된 경계를 지나가게 만드는 것이다.