Immich는 CGNAT 또는 이중 NAT 환경에서 안정적으로 작동하나요?

예, Immich는 CGNAT 또는 이중 NAT 환경에서도 안정적으로 실행할 수 있습니다. 이러한 네트워크 계층은 주로 원격 클라이언트가 서버에 연결하는 방식에 영향을 주며, 로컬 Immich 처리 자체에는 큰 영향을 주지 않기 때문입니다.

문제는 외부 주소 변환을 제어할 수 없는 홈 서버에 가족이 원치 않는 인바운드 IPv4 연결을 직접 전달하려 할 때 발생합니다. 이중 NAT는 두 라우터를 모두 제어할 수 있다면 관리할 수 있지만, CGNAT에서는 일반적으로 ISP가 외부 주소 변환을 담당하므로 홈 라우터에서 간단히 포트 포워딩을 설정해도 동일한 직접 공인 경로를 만들 수 없습니다.

로컬 Immich는 공인 네트워크 연결에 의존하지 않습니다

같은 홈 네트워크에 있는 휴대폰과 브라우저는 공인 포트 매핑 없이도 사설 주소를 통해 Immich 서버에 연결할 수 있습니다. 따라서 ISP가 가정에 직접 연결 가능한 공인 IPv4 주소를 제공하지 않더라도 업로드, 탐색, 데이터베이스 작업, 썸네일 생성, 로컬 머신 러닝은 정상적으로 작동할 수 있습니다.

이러한 차이는 CGNAT 뒤의 Immich에 관한 커뮤니티 질문에서도 나타납니다. 사용자는 대개 로컬 배포는 정상적으로 작동하지만 원격 액세스를 추가할 때만 제한을 경험한다고 보고합니다. 즉, CGNAT는 애플리케이션이나 스토리지의 문제가 아니라 연결 가능성의 조건입니다.

Immich가 LAN에서도 작동하지 않는다면 CGNAT를 첫 번째 원인으로 보아서는 안 됩니다. 공용 경로를 다시 설계하기 전에 로컬 DNS, 컨테이너 네트워킹, 서버 가용성, 스토리지 또는 인증을 먼저 진단하세요.

이중 NAT와 CGNAT는 서로 다른 제어 경계를 만듭니다

가정 내부의 이중 NAT 환경에서는 관리자가 두 변환 계층을 모두 제어할 수 있습니다. 예를 들어 ISP 게이트웨이와 개인 라우터가 함께 있는 경우입니다. 두 계층을 모두 거쳐 포워딩하거나 네트워크 구성을 변경하면 직접 인바운드 경로를 만들 수 있는 경우가 있습니다. 핵심은 외부 매핑을 가정에서 제어할 수 있는지 여부입니다.

Tailscale의 어려운 NAT 통과 관련 글은 여러 NAT 계층과 통신사급 게이트웨이가 직접 피어 투 피어 경로를 설정할 가능성을 낮추는 이유를 설명합니다. 매핑이 제한적일수록 통과 시스템에서 대체 릴레이를 필요로 할 가능성이 커집니다.

토폴로지를 확인하지 않고 사설 주소처럼 보이는 모든 WAN 주소를 같은 문제로 간주하지 마세요. IPv6, ISP가 제공하는 공인 주소 옵션, 브리지 모드, 서로 다른 상위 네트워크 구조에 따라 사용 가능한 경로가 달라질 수 있으며, 홈 라우터 화면이 비슷해 보여도 마찬가지입니다.

오버레이 네트워크는 포트 포워딩 없이 연결 가능성을 회복할 수 있습니다

사설 오버레이를 사용하면 원격 클라이언트와 홈 서버가 모두 아웃바운드 연결을 시작한 뒤 암호화된 피어 투 피어 경로를 형성할 수 있습니다. 직접 통과가 성공하면 홈 라우터에서 Immich 서비스를 일반적인 공인 포트로 노출하지 않고도 데이터가 흐를 수 있습니다.

오버레이 연결에 대한 자세한 설명에서는 NAT 통과와 직접 경로를 만들 수 없을 때 사용하는 암호화된 릴레이 대체 경로를 다룹니다. 따라서 일반적인 인바운드 IPv4 포워딩을 사용할 수 없는 CGNAT 환경의 가정에서도 Immich 원격 액세스를 구현할 수 있습니다.

대신 클라이언트와 ID에 대한 의존성이 생깁니다. 인증된 원격 기기는 오버레이에 액세스할 수 있어야 하며, 브라우저만 사용하는 게스트가 이용하는 공용 리버스 프록시와는 경로가 다를 수 있습니다. 따라서 안정성을 평가할 때는 관리자 한 명의 휴대폰이 작동하는지만이 아니라 가족 구성원이 실제로 어떻게 연결하는지도 고려해야 합니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

릴레이 대체 경로는 액세스를 유지하지만 성능을 바꿀 수 있습니다

어려운 NAT 또는 방화벽 규칙으로 직접 UDP 연결이 차단되더라도 릴레이 경로를 사용하면 서비스에 계속 연결할 수 있습니다. 이는 접속 가능 여부의 문제를 해결하지만, 추가 홉으로 인해 지연 시간이 늘거나 처리량이 감소할 수 있으며 대용량 사진 업로드와 고해상도 원격 탐색에서 특히 중요합니다.

2026년 릴레이 성능 보고서에서는 더 나은 릴레이 아키텍처를 사용하기 전 장거리 DERP 경로로 인해 수백 밀리초가 추가된 사례를 보여 줍니다. 구체적인 수치는 해당 작성자의 경로에서 나타난 결과로 보되, 직접 경로와 릴레이 경로의 일반적인 작동 방식은 동일하게 이해해야 합니다.

이는 “Tailscale이 CGNAT를 해결한다”는 단순한 설명의 한계가 드러나는 지점입니다. Tailscale은 연결을 복구할 수 있지만 직접 LAN 또는 직접 피어 경로와 동일한 성능을 보장하지는 않습니다. 느린 Immich 동작을 애플리케이션 탓으로 돌리기 전에 실제 경로를 확인하세요.

연결 가능성과 경로를 별도의 테스트로 확인하세요

먼저 WAN 연결을 끊은 상태에서 로컬 Immich를 테스트하세요. 홈 네트워크 안에서는 계속 사용할 수 있어야 합니다. 그런 다음 셀룰러 네트워크나 다른 외부 네트워크에서 선택한 원격 방식을 테스트하세요. 마지막으로 원격 연결이 직접 연결인지 릴레이 연결인지 확인하고, 업로드, 썸네일 열기, 특정 검색 결과를 LAN 기준과 비교하세요.

ZimaSpace의 CGNAT와 이중 NAT 관련 설명은 다른 셀프 호스팅 서비스에도 동일한 네트워크 계층 원리를 적용합니다. 애플리케이션은 로컬에서 안정적으로 작동할 수 있지만, 원격 진입 경로에는 별도의 설계가 필요할 수 있습니다.

인터넷 연결이 끊겨도 로컬 사용이 유지되고, 원격 인증이 의도적으로 구성되어 있으며, 원격 경로가 가정에서 요구하는 지연 시간과 처리량을 충족한다면 이러한 아키텍처를 사용해도 됩니다. 예상보다 느린 릴레이를 통해서만 액세스할 수 있다면 이를 Immich 자체가 NAT 환경에서 불안정하다는 증거가 아니라 경로 품질 문제로 판단하세요.