홈서버 외부 접속 방식을 두 번 바꾼 이유
홈서버의 외부 접속은 한 번 설정하고 끝나지 않았습니다. Home Assistant만 연결할 때는 Cloudflare Tunnel로 시작했지만, NAS의 다른 서비스와 관리 방식을 맞추면서 DSM 역방향 프록시로 옮겼습니다. 이후 맥미니에서 운영하는 서비스가 늘자 접속 경로를 다시 나눴습니다.
같은 서비스를 다시 Tunnel로 옮긴 기록만 보면 앞선 설정을 되돌린 것처럼 보입니다. 실제로는 그때마다 관리할 서비스와 함께 중단돼도 되는 범위가 달랐습니다. 이 글에서는 그 구성이 바뀐 이유와 연결 오류를 확인한 과정을 정리합니다.
Cloudflare Tunnel을 통한 외부 접속
3월 초에는 NAS에서 cloudflared를 실행해 Home Assistant로 연결했습니다. 공유기에 새 포트포워딩을 추가하지 않고 도메인으로 접속할 수 있었습니다.
며칠 뒤에는 DSM 역방향 프록시로 옮겼습니다. NAS의 다른 서비스는 이미 DSM에서 관리하고 있었는데 Home Assistant만 별도 컨테이너와 Tunnel 설정을 확인해야 했습니다. 당시에는 기존 관리 방식에 맞추는 편이 편했습니다.
| 시기 | 외부 접속 경로 | 변경 이유 |
|---|---|---|
| 3월 초 | Tunnel → HA | 외부 접속 구성 |
| 3월 중순 | NAS 프록시 → HA | NAS의 기존 서비스 관리 방식과 통일 |
| 9월 | Tunnel → HA 직접 연결 | 로컬 게이트웨이와 장애 범위 분리 |
NAS 프록시 경로에서는 포트포워딩과 인증서, WebSocket 설정도 관리해야 했습니다. Cloudflare 프록시를 사용하더라도 원본 서버의 접근 제어나 인증서 설정을 생략할 수 있는 것은 아닙니다.
서비스별 접속 경로 분리
9월에는 PogoAtlas와 ErinDex 같은 API를 로컬 게이트웨이에 모았습니다. Home Assistant는 같은 Tunnel의 별도 호스트명으로 VM에 직접 연결했습니다. 게이트웨이에 문제가 생겨도 집 자동화의 외부 접속까지 함께 끊기지 않게 하기 위해서입니다. 상태 페이지는 맥미니 밖의 NAS에 남겼습니다.
전환 중에는 맥미니에서 Home Assistant에 직접 접속할 수 있는데 cloudflared에서는 연결되지 않는 문제가 있었습니다. 우선 DNS를 기존 경로로 되돌려 외부 접속을 복구한 뒤 조사했습니다. 이후 공식 서명 바이너리로 정리하고 HTTP 요청과 HA WebSocket 연결을 확인했습니다.
이 과정에서 원본 서비스의 응답과 Tunnel을 통한 접속을 따로 확인해야 했습니다. 같은 컴퓨터에서 실행해도 두 경로가 항상 같은 결과를 내는 것은 아니었습니다.
요청 경로를 그려 두는 이유
외부 주소는 같아 보여도 안쪽 경로가 달라질 수 있습니다. 다음은 9월 이후의 역할 분담을 단순화한 그림입니다. 실제 호스트명과 내부 주소는 생략했습니다.
HA를 게이트웨이 뒤에 함께 넣으면 게이트웨이 점검이 HA의 외부 접속에도 영향을 줍니다. 전용 경로를 두면 게이트웨이를 다시 올리는 동안에도 HA 쪽을 따로 확인할 수 있습니다. 물론 두 경로가 같은 Tunnel이나 네트워크를 사용한다면 그 의존성은 여전히 공유합니다. 서비스별 분리와 전체 장애 격리는 같은 뜻이 아닙니다.
내부·외부 요청 비교
외부 오류를 확인할 때는 같은 시간대에 원본과 공개 주소를 나눠 조회합니다. 아래는 URL을 환경에 맞춰 넣는 읽기 전용 점검 예시입니다. HA의 포트는 설치 버전과 설정에 따라 다르므로 실제 값을 사용합니다.
# ORIGINAL_URL, PUBLIC_URL에는 점검할 두 주소를 지정합니다.
curl --silent --show-error --output /dev/null \
--max-time 10 --write-out 'original: %{http_code} %{time_total}s\n' "$ORIGINAL_URL"
curl --silent --show-error --output /dev/null \
--max-time 10 --write-out 'public: %{http_code} %{time_total}s\n' "$PUBLIC_URL"이 명령에서 000과 연결 오류가 나오면 유효한 HTTP 응답을 받지 못한 것입니다. 반면 400이나 502는 응답을 반환한 구간이 있다는 뜻이므로 그 앞뒤 로그를 이어서 봅니다. 내부 200·외부 실패라면 원본 재시작보다 프록시의 원본 주소, DNS, 인증서와 연결 로그를 먼저 비교할 수 있습니다.
프록시 뒤의 Home Assistant에서는 전달 헤더와 신뢰할 프록시 주소도 맞아야 합니다. 현재 HTTP 통합 문서 는 Network 설정의 HTTP 항목에서 이를 관리하도록 설명합니다. 예전 http: YAML 설정을 그대로 새 설치의 안내로 복사하지 않고, 설치 버전과 실제 프록시 출발 주소를 확인해야 합니다.
마지막에는 브라우저에서 로그인 화면만 보는 데서 끝내지 않고 HA의 WebSocket 연결도 봤습니다. HTTP 응답과 지속 연결은 통과하는 설정이 다를 수 있습니다. 원본 HTTP 정상, 공개 HTTP 정상, 공개 WebSocket 연결을 나눠 기록하면 다음에 같은 증상이 생겼을 때 비교할 기준이 남습니다.
외부 접속 오류와 서비스 중단 구분
9월 말에는 내부와 외부에서 같은 NAS 서비스를 조회해 비교했습니다. 외부 요청이 실패한 시점에도 내부 요청은 정상인 경우가 있었습니다. 이때 원본 서비스만 재시작해서는 외부 경로의 문제를 해결할 수 없습니다.
Tunnel에 연결된 서비스에서는 QUIC 연결 시간 초과와 외부 오류의 발생 시각이 겹쳤습니다. HTTP/2로 고정해 비교했지만 이후에도 외부 오류가 남았습니다. 따라서 프로토콜 변경만으로 원인을 해결했다고 정리하지는 않았습니다.
9월에 정리한 구성에서는 일반 API는 게이트웨이로, Home Assistant는 별도 호스트명으로 VM에 직접 연결했습니다. 전환 후 HTTP 요청과 HA WebSocket 연결을 확인했고, 상태 페이지는 NAS에 남겼습니다.
다만 이후 NAS 서비스의 외부 접속 오류까지 모두 해결한 것은 아닙니다. HTTP/2로 바꿔 비교한 뒤에도 오류가 남아, 원본 서비스의 상태와 Tunnel 연결 문제를 나눠 조사할 대상으로 남겼습니다.