라우터를 교체하면 새 라우터에서 로컬 주소 지정, NAT 규칙, WAN 동작 또는 DNS 업데이트가 변경되기 때문에 원격 액세스가 대개 중단됩니다.
홈 서버는 로컬에서 계속 작동하더라도, 교체한 라우터가 다른 DHCP 서브넷을 사용하거나 NAS에 새 주소를 할당하고, 수동 포트 포워딩을 잃거나, 다른 방화벽 프로필을 활성화하거나, 기존 모뎀의 NAT 뒤에 놓이거나, 잘못된 엔드포인트로 DDNS를 업데이트하면 모든 외부 경로가 실패할 수 있습니다. 가장 안전한 복구 방법은 서버에서 바깥쪽으로 경로를 다시 구축하고 각 단계가 끝날 때마다 실제 외부 네트워크에서 테스트하는 것입니다.
기존 라우터와 새 라우터 사이에 변경된 사항 기록하기
기존 LAN 서브넷, 서버 주소, DHCP 예약, 포워딩된 포트, WAN 모드, DDNS 제공업체, IPv6 상태, VPN 설정, 그리고 라우터 앞단에 있는 모뎀 또는 ISP 게이트웨이의 정보를 기록합니다. 그런 다음 해당 값을 교체한 장치와 비교합니다.
Synology 커뮤니티의 한 사례에서는 라우터 업그레이드 후 NAS 원격 액세스가 중단되고 기존 포트 포워딩이 더 이상 응답을 생성하지 않았습니다. 이는 라우터별 포워딩 상태가 자동으로 이전된다고 가정하지 말고 다시 구성해야 하는 이유를 보여 줍니다.
기존 설정을 모두 무작정 가져오지 마세요. 현재도 필요한 공개 서비스를 확인하고 해당 서비스에 필요한 최소한의 규칙, 예약, 인증서 및 DNS 항목만 다시 생성합니다.
홈 서버의 현재 LAN 주소 예약하기
새 LAN에서 서버의 실제 IPv4 및 IPv6 주소, 기본 게이트웨이, 서브넷 마스크를 확인합니다. 그런 다음 포트 포워딩 또는 VPN 규칙에 저장된 대상 주소와 사설 주소를 비교합니다.
포트 포워딩 안내에서는 대상 장치에 안정적인 로컬 주소가 필요하다고 강조합니다. DHCP 변경으로 인해 서버가 LAN의 다른 곳에서는 표시되더라도 규칙이 잘못된 내부 장치를 가리킬 수 있기 때문입니다.
서버의 현재 MAC 주소를 사용해 DHCP 예약을 생성한 다음 서버를 한 번 다시 연결합니다. 새 라우터의 DHCP 풀과 충돌하거나 이전 서브넷의 기존 게이트웨이를 유지하는 고정 주소는 설정하지 마세요.
수동 포트 포워딩 및 로컬 방화벽 규칙 다시 생성하기
먼저 서비스가 로컬에서 수신 대기 중인지 확인한 다음, 정확한 외부 포트, 내부 주소, 내부 포트 및 TCP 또는 UDP 프로토콜을 다시 설정합니다. 한 번에 하나의 서비스만 모바일 데이터에서 테스트합니다.
Plex 원격 액세스 문제 해결 안내에 따르면, 라우터가 UPnP 매핑을 변경하거나 이전과 다르게 다시 생성할 수 있으므로 수동 포워딩이 UPnP 매핑에 의존하는 것보다 더 안정적인 경우가 많습니다. 안정적인 서버 주소를 예약한 뒤 사용하는 고정 수동 포트 포워딩이 유용한 제어 방식입니다.
라우터 방화벽과 서버 방화벽을 별도로 확인합니다. 새 라우터가 WAN 입력을 차단하거나, 서버가 기존 서브넷만 신뢰하거나, 애플리케이션이 다른 인터페이스에서 수신 대기 중이면 포워딩된 패킷도 여전히 실패합니다.
새 라우터의 WAN 주소와 공인 주소 비교하기
교체한 라우터에 표시된 WAN 주소를 확인하고 외부 공인 IP 조회 결과와 비교합니다. 두 주소가 다르면 기존 ISP 게이트웨이가 여전히 라우팅 중이거나, 새 라우터가 이중 NAT 뒤에 있거나, ISP가 연결을 CGNAT 뒤로 이동했을 가능성이 있습니다.
최신 홈랩 원격 액세스 가이드에서는 CGNAT와 동적 IP 변경이 일반적인 포워딩 오류처럼 보일 수 있으므로 WAN 주소와 공인 주소를 비교할 것을 권장합니다. 이 비교를 통해 새 라우터가 공인 엔드포인트를 보유하고 있는지 확인할 수 있습니다.
기존 모뎀이 여전히 라우팅 중이라면 브리지 또는 패스스루 모드를 사용하거나 두 계층을 모두 통과하도록 포워딩합니다. ISP가 업스트림 NAT를 제어한다면 더 광범위한 로컬 규칙을 개방하는 대신 공인 주소, IPv6, 아웃바운드 터널 또는 릴레이를 선택합니다.
DDNS, IPv6 및 VPN 설정을 신중하게 다시 구성하기
라우터의 DDNS 클라이언트가 의도한 호스트 이름, 계정, 인터페이스 및 주소 체계를 사용하는지 확인합니다. 게시된 A 및 AAAA 레코드를 새 라우터에서 연결 가능한 공용 경로와 비교합니다.
WD 커뮤니티의 한 복구 사례에서는 라우터에서 자동 UPnP 동작을 명시적인 수동 매핑으로 교체하여 원격 액세스를 복구했습니다.
필요한 경우에만 VPN 키와 라우트를 다시 가져옵니다. 라우터를 교체하면 VPN 서브넷, DNS 서버, 방화벽 영역 및 광고되는 LAN 라우트가 변경될 수 있습니다. 새 IPv6 경로가 준비되지 않았다면 오래된 AAAA 레코드를 삭제합니다.
외부에서 검증하고 임시 노출 제거하기
모바일 데이터에서 공용 호스트 이름을 테스트하고 DNS, TCP 연결, TLS 인증서, 애플리케이션 로그인 및 실제 원격 작업 흐름을 기록합니다. NAT 루프백을 통한 로컬 테스트만으로는 인터넷 연결 가능성을 입증할 수 없습니다.
원격 액세스가 이전 주소 상태를 따르는 이유에 관한 ZimaSpace 가이드에서는 라우터는 작동하지만 클라이언트가 여전히 오래된 엔드포인트를 대상으로 할 때 필요한 다음 계층을 설명합니다.
예약된 서버 주소, 제한적인 라우터 규칙, 공용 DNS, 방화벽 및 애플리케이션이 모두 일치할 때만 복구가 완료됩니다. 제어된 테스트가 성공한 후에는 임시 DMZ, 광범위한 허용 규칙 및 중복 UPnP 매핑을 비활성화합니다.
지원 및 팁
더 읽어보기

Plex가 다른 Docker 컨테이너와 GPU를 공유할 수 있나요?
Plex와 다른 컨테이너가 동일한 GPU에 함께 액세스할 수 있는 경우가 많지만, 드라이버 지원, 디바이스 매핑, 비디오 엔진 부하, 메모리, 복구 동작을 테스트해야 합니다.

Plex 오류가 클라이언트에서 발생한 것인지 서버에서 발생한 것인지 확인하는 방법
다른 클라이언트에서 동일한 항목을 재현하고, 세션 경로를 비교한 다음, 범위 분석을 통해 장애가 실제로 발생한 위치를 확인한 후에만 서버 증거를 수집하세요.

Plex 캐시 및 트랜스코딩 임시 저장소 구성 방법
영구 Plex 상태는 보호하면서 트랜스코딩 임시 파일은 적합한 로컬 저장소에 배치한 다음, 정리 상태와 여유 공간 및 재시작 동작을 확인하세요.

