ERR_UNSAFE_PORT: 크롬이 포트를 막았다

문제

크롬이 URL 로딩을 거부하고 ERR_UNSAFE_PORT(net error -312)를 표시합니다. 주소에는 대개 http://example.com:6000이나 http://localhost:6666처럼 명시적 포트가 붙어 있습니다.

증상

• 실패가 즉각적입니다. 로딩 스피너도, 타임아웃도 없이 크롬이 연결을 만들기 전에 주소를 거절합니다.
• 같은 URL이 curl·Postman·평범한 TCP 클라이언트에서는 됩니다. 포트는 도달 가능하고, 브라우저만 손대지 않습니다.
• 특정 포트 번호에서만 발생합니다. 똑같은 서비스를 :8080으로 옮기면 잘 열립니다.
• 파이어폭스는 표현은 다르지만 같은 뜻의 메시지(“주소가 제한됨”)를 보여줍니다 — 이게 서버가 아니라 브라우저 정책이라는 신호입니다.

ERR_UNSAFE_PORT의 실제 의미

크롬에는 HTTP(S)로 열지 않을 포트의 하드코딩된 차단 목록이 들어 있고, 그중 하나를 겨냥하면 나오는 게 ERR_UNSAFE_PORT입니다. 서비스가 돌고 있는지 여부와는 무관합니다. 패킷 하나 나가기 전에 브라우저 안에서 내려지는 결정입니다.

이유는 cross-protocol scripting이라는 오래된 공격군입니다(2001년 문서화된 HTML Form Protocol Attack). SMTP·FTP·IRC·NFS 같은 평문 프로토콜은 이해 못 하는 줄을 무시하며 입력을 관대하게 파싱합니다. 악성 웹 페이지가 예컨대 25번 포트를 겨냥한 폼을 제출하거나 리소스를 fetch하면, 브라우저는 순순히 그리로 HTTP 요청을 보냅니다. 메일 서버는 HTTP 잡음은 무시하지만 요청 본문에 몰래 심어둔 SMTP 명령은 기꺼이 실행합니다. 그 문을 닫으려고, 브라우저는 그런 서비스가 전통적으로 사는 포트로의 연결을 거부합니다.

이 목록은 WHATWG Fetch 표준이 정의한 ‘bad ports’ 집합과 같아서, 크롬·엣지·파이어폭스·사파리가 거의 동일한 ~80개 포트를 막습니다. 대부분은 아무도 웹사이트를 서빙하지 않는 뻔한 인프라 포트입니다. 함정은 개발자가 포트를 즉흥적으로 고를 때 실제로 손이 가는 몇 개입니다. 6000(X11), 6666–6669·6697(IRC), 2049(NFS), 10080. 6666이 비어 보여서 개발 서버를 올리면, 다른 도구는 다 붙는데 크롬만 로딩을 거부합니다.

결정적으로, 포트는 닫혀 있지 않습니다. 진단의 전부가 이것입니다. 포트가 열려 있고 도달 가능함을 증명하면, 문제가 네트워크가 아니라 크롬의 차단 목록임을 증명한 것입니다.

DechoNet으로 진단

• Port Check로 포트가 실제로 열려 연결을 받는지 확인합니다. open으로 나오면 서비스는 멀쩡하고 차단은 100% 브라우저 쪽 — 방화벽을 쫓을 일이 아닙니다.
• HTTP Check로 브라우저 밖에서 URL을 가져옵니다. 정상 응답(또는 어떤 HTTP 상태 코드든)이 오면 서버가 그 포트에서 답한다는 뜻이고, 차단은 크롬에만 존재합니다.
• DNS Lookup은 호스트명이 생각한 곳을 가리키는지 확신이 없을 때 — 포트를 탓하기 전에 낡은 레코드를 배제하세요.

해결 체크리스트

• URL의 포트 번호를 읽고 차단 목록과 대조합니다. 6000·6666·6697·10080 등 웹이 아닌 포트라면, 그게 답입니다.
• 그 호스트·포트로 Port Check를 돌립니다. open + 도달 가능이면 서비스는 정상이고 차단은 크롬 것입니다.
• 진짜 해결: 서비스를 목록 밖 포트로 옮깁니다 — 8080·8000·3000, 또는 443 뒤에 리버스 프록시를 둡니다. 이래야 당신뿐 아니라 모든 방문자에게 고쳐집니다.
• 로컬 테스트 한정: --explicitly-allowed-ports=6666(또는 엣지·크롬의 ExplicitlyAllowedNetworkPorts 정책)으로 본인 기기에서만 차단을 우회합니다. 이걸 해결책이라고 배포하지 마세요 — 다른 사람은 그 플래그가 없습니다.
• 포트를 옮긴 뒤 일반 브라우저 창에서 다시 테스트해 기본 설정에서 오류가 사라졌는지 확인합니다.

에스컬레이션 시점

• 서비스가 반드시 차단된 포트에 있어야 한다면(바꿀 수 없는 고정 포트에 묶인 레거시 내부 도구 등), 사용자에게 브라우저 플래그를 고치라고 하지 말고 허용 포트에 리버스 프록시나 포트 포워딩을 두세요.
• 포트를 옮길 수도, 프록시할 수도 없다면 포트 차단은 버그가 아니라 예상된 동작입니다 — 에스컬레이션은 우회할 브라우저·네트워크 결함이 아니라, 서비스가 어디서 리슨해야 하는지에 대한 설계 결정입니다.