Clash 포트 충돌 해결: 점유 프로세스 찾기와 혼합 포트 변경

Clash 클라이언트(그리고 Clash Meta / mihomo 코어 기반의 각종 파생 클라이언트)는 실행 시 로컬에서 하나 이상의 포트를 열어 시스템이나 브라우저가 전달하는 프록시 트래픽을 받습니다. 가장 흔한 것은 mixed-port(혼합 포트)로, 기본값은 보통 7890이며 HTTP와 SOCKS5 프로토콜을 동시에 처리해 예전에 port(HTTP)와 socks-port(SOCKS5)를 따로 설정해야 했던 방식을 대체합니다. 이 외에도 관리 패널 통신용 external-controller 포트가 있는데, 흔히 9090을 씁니다.

클라이언트가 실행 단계에서 이 포트들을 열려고 할 때, 운영체제가 해당 포트를 다른 프로세스가 이미 쓰고 있다고 알려오면 bind: address already in use 같은 오류가 발생하고, 프로그램은 실행을 멈추거나 연결 실패를 알립니다. 이는 운영체제 차원의 자원 독점 원칙 때문입니다. 같은 TCP 포트는 동시에 하나의 프로세스만 독점적으로 리스닝할 수 있으며, 먼저 잡은 쪽이 이기고 나중에 온 쪽은 거부당합니다.

운영체제마다 포트 점유 확인 명령은 다르지만 원리는 같습니다. 먼저 포트 번호로 프로세스 ID(PID)를 찾고, PID로 다시 프로세스 이름을 확인해 정체를 파악합니다.

Windows

명령 프롬프트나 PowerShell을 열고 다음을 실행합니다:

netstat -ano | findstr :7890

출력의 맨 끝 숫자가 PID입니다. 예를 들어 12480이 보이면 이어서 다음을 실행합니다:

tasklist /FI "PID eq 12480"

포트를 점유한 프로세스 이름이 나옵니다. 흔히 남아 있는 clash.exe, clash-verge.exe, 다른 프록시 프로그램의 실행 파일, 또는 일부 보안 소프트웨어의 트래픽 전달 컴포넌트인 경우가 많습니다.

macOS / Linux

macOS와 대부분의 Linux 배포판에는 lsof가 기본 내장되어 있습니다. 다음을 실행합니다:

lsof -i :7890

출력의 COMMAND 열이 프로세스 이름, PID 열이 프로세스 번호입니다. lsof가 없는 시스템이라면 Linux에서는 아래 명령도 쓸 수 있습니다:

netstat -anp | grep 7890
# 또는 최신 ss 명령 사용
ss -ltnp | grep 7890

일부 배포판에서는 netstat -anp가 프로세스 이름을 보려면 sudo 권한이 필요하며, 권한이 없으면 PID 열이 비어 보일 수 있습니다.

포트를 점유한 프로세스를 찾았다고 바로 강제 종료하지 마세요. 먼저 어떤 프로세스인지, 왜 실행 중인지 파악한 뒤 처리 방법을 결정합니다.

1. Clash 자체의 남은 프로세스인 경우. 지난번 클라이언트 창은 닫혔지만 백그라운드 프로세스가 완전히 종료되지 않았거나, 시스템 오류로 좀비 프로세스가 남은 경우 흔히 발생합니다. 이때는 해당 프로세스를 종료하고 클라이언트를 다시 실행하면 되며, 설정을 바꿀 필요는 없습니다.
2. 다른 프록시나 VPN 프로그램이 상시 실행 중인 경우. 예를 들어 두 개의 프록시 클라이언트를 동시에 설치했거나, 회사에서 강제로 설치한 VPN 컴포넌트가 같은 포트를 계속 점유하는 경우입니다. 이런 프로세스는 대개 의도적으로 유지되므로 강제 종료하면 다른 기능에 문제가 생길 수 있습니다. Clash 쪽 포트를 바꿔서 매번 부팅할 때마다 충돌을 수동으로 처리하지 않도록 하는 편이 낫습니다.
3. 시스템 서비스나 컨테이너 포트 매핑인 경우. 일부 라우팅 소프트웨어, Docker 컨테이너, 로컬 개발 서비스가 마침 같은 포트대를 쓰는 경우입니다. 이런 포트는 함부로 종료하기 어려우니 마찬가지로 Clash 쪽 포트를 바꿔 양보하는 것을 권장합니다.

대부분의 GUI 클라이언트는 포트 설정 항목을 제공하며, 보통 '설정' 또는 '기본' 화면에서 혼합 포트 값을 바로 바꿀 수 있고 저장하면 클라이언트가 자동으로 재시작되어 다시 리스닝합니다. 해당 항목이 없거나 설정 파일을 직접 편집하는 경우라면 YAML에서 아래 줄을 찾아 수정합니다:

mixed-port: 7891
external-controller: 127.0.0.1:9091

기본값 7890을 현재 점유되지 않은 포트 번호로 바꾸면 됩니다. 다른 흔한 소프트웨어와 충돌하지 않는 7891, 17890 같은 값이 자주 쓰입니다. 설정 파일이 mixed-port 대신 port(HTTP)와 socks-port(SOCKS5)를 따로 선언하는 옛 방식이라면 두 포트를 모두 함께 바꿔야 하고, 서로 값이 같지 않은지도 확인해야 합니다. 그렇지 않으면 마찬가지로 바인딩에 실패합니다.

변경 후에는 클라이언트를 완전히 재시작해야 합니다(설정만 다시 불러오는 것이 아니라). 포트 리스닝은 프로세스 시작 단계에서 이루어지기 때문에, 설정만 핫 리로드하면 포트가 다시 바인딩되지 않는 경우가 많습니다.

Clash 포트를 바꾼 뒤, 기존에 '시스템 프록시' 모드로 연결했다면(TUN 모드로 전체 트래픽을 처리하는 경우가 아니라면) 시스템에 기록된 프록시 포트도 함께 바꿔야 합니다. 그렇지 않으면 브라우저와 다른 프로그램이 여전히 예전 포트로 요청을 보내 연결이 바로 거부됩니다.

• Windows: '설정 → 네트워크 및 인터넷 → 프록시'의 수동 프록시 포트 번호 항목을 새 포트로 바꿔야 합니다. 클라이언트에 '시스템 프록시 자동 설정' 옵션이 있다면 재시작 후 보통 자동으로 갱신되므로 수동으로 바꿀 필요는 없습니다.
• macOS: '시스템 설정 → 네트워크 → 사용 중인 네트워크 인터페이스 → 세부 정보 → 프록시'에서 웹 프록시(HTTP)와 보안 웹 프록시(HTTPS) 포트를 모두 새 포트로 맞춰야 합니다.
• Linux: 환경 변수로 프록시를 설정하는 경우 http_proxy, https_proxy, all_proxy 등 변수에 들어있는 포트 번호를 갱신해야 합니다. 예:

export all_proxy=http://127.0.0.1:7891
export http_proxy=$all_proxy
export https_proxy=$all_proxy

PAC 자동 설정 스크립트나 시스템의 '자동 감지' 설정을 쓴다면 대개 수동으로 포트를 바꿀 필요가 없지만, 변경 후에는 브라우저로 사이트에 접속해 프록시가 실제로 동작하는지 확인하는 것을 권장합니다. 포트 변경 후 모르는 사이에 프록시가 꺼져 있는 상황을 피할 수 있습니다.

첫째, mixed-port만 바꾸고 external-controller 포트는 그대로 둔 상태에서 9090/9091도 마침 점유되어 있다면, 클라이언트 관리 패널(Dashboard)이 열리지 않지만 프록시 전달 기능 자체는 정상입니다. 이를 '설정이 또 망가졌다'고 오해하지 마세요. 둘째, 일부 클라이언트는 포트 번호를 로컬 캐시나 이전 설정 스냅샷에 저장해 두는데, YAML 파일을 직접 수정해도 클라이언트가 여전히 캐시된 값을 읽는다면 클라이언트에서 캐시를 수동으로 지우거나 설정을 다시 불러와 새 포트가 실제로 적용되었는지 확인하는 것을 권장합니다.