Plex에서 프록시를 켠 뒤 메타데이터 접속은 좋아졌는데 원격 접속에 문제가 생겼다면, 먼저 분기(라우팅) 정책을 확인해 보자. 하지만 "원격 접속 문제는 전부 프록시 때문"이라는 말은 성립하지 않는다.
먼저 세 가지 연결을 구분하자
Plex 서버가 포스터와 메타데이터를 가져오는 것은 아웃바운드 접속이다. 서버가 Plex 서비스에 연결 정보를 등록하는 것도 아웃바운드다. 반면 원격 클라이언트가 집 안의 Plex 서비스에 접속하는 것은 실제로 도달 가능한 인바운드 경로에 달려 있다.

설명 이미지: Plex — 아웃바운드 요청과 원격 인바운드는 같은 길이 아니다
프록시는 외부에서 보이는 출구 주소를 바꿀 수도 있고, 등록이나 탐지가 다른 경로를 쓰게 만들 수도 있다. 이는 점검 방향 중 하나일 뿐, 원인이라고 이미 증명된 것은 아니다.
순서대로 확인하기
먼저 LAN 클라이언트가 Plex에 직접 접속할 수 있는지 확인한다. 그다음 라우터의 공인 주소가 정말 외부에서 접속 가능한 공인 주소인지 점검한다. 이중 NAT나 CGNAT는 분기 규칙을 바꾸는 것만으로는 해결되지 않는다.
포트를 수동으로 매핑할 때는 라우터의 지정 외부 TCP 포트를 Plex 호스트의 TCP 32400으로 포워딩하고, Plex 원격 접속 설정에 해당 외부 포트를 입력해야 한다. "외부 포트도 반드시 32400이어야 한다"고 생각하지 말자. 호스트 방화벽과 대상 주소가 바뀌지 않았는지도 확인한다.
휴대폰 모바일 네트워크 같은 진짜 외부 네트워크로 테스트하고, LAN 안에서만 루프백 접속을 시험하지 않도록 한다. 패널에 잠깐 초록불이 들어왔다고 해서 모든 클라이언트 경로가 정상이라는 뜻은 아니다.
그다음 프록시와 DNS 확인하기
현재 정책을 백업해 두고, Plex 등록과 탐지 관련 요청이 실제로 어느 경로로 가는지 살펴본다. 조정이 필요하면 관련 있다고 확인된 도메인이나 기기 정책만 바꾸고, 프록시를 켰을 때와 껐을 때의 동작을 비교한다.
*.amazonaws.com 전체를 직결로 지정하는 것은 범위가 너무 넓어 기본 규칙으로 적합하지 않다. 모든 Plex 메타데이터 도메인을 강제로 같은 출구로 보내고 원격 문제를 전부 고칠 수 있다고 주장하는 것도 권하지 않는다.
보안 연결은 DNS 리바인딩 보호의 영향을 받을 수도 있다. Plex 공식 보안 연결 안내에 plex.direct 처리 방법이 나와 있다. 리바인딩 보호를 통째로 끄지 말고, 사용하는 DNS 서비스에 맞춰 해당 도메인에 대한 예외를 설정하자.
포트 도달 가능성과 재생 권한은 별개다
네트워크 연결이 정상이라고 해서 계정이 현재 제품 규칙에 따라 원격으로 영상을 재생할 수 있다는 뜻은 아니다. 현재 Plex Pass, Remote Watch Pass 등 적용 조건도 확인해야 한다. 연결 실패인지, Relay를 거치는 것인지, 재생 권한 안내인지 먼저 구분한 뒤 그에 맞는 해결책을 찾자.
점검 자료에 Plex Token이 포함되어 있다면, 토큰이 들어간 전체 주소를 댓글이나 스크린샷, 공개 로그에 올리지 말자. 점검할 때는 URL 안의 자격 증명을 가려야 한다.
참고: 원격 접속 문제 해결, 보안 연결과 DNS. 이 글은 공식 안내에 맞춰 수정한 것으로, 여러분의 라우터나 프록시, Plex 서비스를 변경하지 않았습니다.