Clash 포트 사용 중 오류 해결: 7890 포트 충돌 프로세스 찾기와 mixed-port 변경

오류 메시지가 의미하는 것

Clash 코어는 실행될 때 설정 파일의 포트 값에 따라 로컬 포트를 리스닝합니다. 기본 혼합 포트인 mixed-port는 7890이며, HTTP와 SOCKS5 두 프로토콜을 동시에 지원합니다. 실행 로그에 아래와 같은 문구가 나타난다면 코어가 7890 포트에 바인딩하는 데 실패했다는 뜻입니다:

level=fatal msg="Start Http Server error: listen tcp 127.0.0.1:7890: bind: address already in use"

이 오류는 네트워크 연결 상태와는 무관하며, 순전히 운영체제 차원의 포트 점유 충돌입니다. 이미 다른 프로세스가 7890 포트를 리스닝하고 있어서 새로 시작한 Clash 코어가 해당 포트를 차지하지 못하고, 그대로 종료되거나 대시보드에 "실행되지 않음"으로 표시됩니다. 흔한 발생 상황은 이전 Clash 프로세스가 완전히 종료되지 않은 경우, 같은 기기에 Clash 계열 클라이언트를 두 개 설치한 경우, 또는 다른 프록시 소프트웨어(일부 다운로드 도구, 개발용 디버깅 프록시 등)가 마침 기본 포트를 7890으로 설정한 경우입니다.

해결 순서는 간단합니다. 먼저 누가 해당 포트를 점유하고 있는지 확인한 뒤, 그 프로세스를 종료할지 Clash의 포트를 다른 번호로 바꿀지 결정하면 됩니다. 아래는 플랫폼별 구체적인 명령입니다.

Windows: netstat로 점유 프로세스 찾기

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

netstat -ano | findstr 7890

출력의 마지막 열이 프로세스 PID입니다. 예:

TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    8824

PID를 확인한 뒤 작업 관리자에서 해당 PID의 프로세스 이름을 검색하거나, 명령줄로 계속 확인할 수 있습니다:

tasklist /FI "PID eq 8824"

남아있던 예전 Clash 프로세스나 더 이상 유지할 필요 없는 프로그램임을 확인했다면 바로 종료할 수 있습니다:

taskkill /PID 8824 /F

점유 프로세스가 Clash 자신의 남아있던 인스턴스라면(강제 종료 후 프로세스가 완전히 정리되지 않은 경우 흔함) 종료 후 클라이언트를 다시 실행하면 정상으로 돌아옵니다. 점유 주체가 장기간 실행이 필요한 다른 프로그램이라면, 매번 수동으로 프로세스를 종료하기보다는 아래에서 다룰 포트 변경 방법을 권장합니다.

macOS와 Linux: lsof 또는 ss로 점유 프로세스 찾기

macOS와 대부분의 Linux 배포판에는 lsof 명령이 기본 내장되어 있어 포트 번호로 바로 조회할 수 있습니다:

lsof -i:7890

출력에서 COMMAND 열은 프로세스 이름, PID 열은 프로세스 번호입니다. 예:

COMMAND     PID   USER   FD   TYPE   NODE NAME
clash-core 3021   dev    3u  IPv4        TCP *:7890 (LISTEN)

확인 후 kill로 해당 프로세스를 종료합니다:

kill -9 3021

일부 경량화된 Linux 시스템(예: 일부 컨테이너 이미지나 OpenWrt 라우터)에는 lsof가 기본 설치되어 있지 않을 수 있는데, 이 경우 ss 명령을 사용하면 동일한 효과를 얻을 수 있습니다:

ss -tulnp | grep 7890

ss의 출력은 마지막 열에 프로세스 이름과 PID를 바로 보여주며, users:(("clash",pid=3021,fd=3))와 같은 형식입니다. 마찬가지로 kill -9로 종료할 수 있습니다. ss조차 없는 구버전 시스템이라면 netstat -tulnp | grep 7890으로 대체할 수 있으며 원리는 동일합니다.

클라이언트에서 mixed-port 변경하기

7890 포트를 점유한 프로그램을 종료하기 어렵거나 이런 충돌이 반복적으로 발생한다면, Clash의 리스닝 포트를 다른 번호로 바꿔서 충돌을 근본적으로 피하는 편이 더 편리합니다. 변경 방식은 클라이언트마다 다르지만 내부적으로 수정하는 설정 항목은 동일합니다.

방법 1: 클라이언트 설정 화면에서 직접 변경

Clash Verge, Clash Nyanpasu, FlClash 등 주요 클라이언트는 "설정" 또는 "일반" 화면에 포트 입력란을 제공합니다. "Mixed Port", "혼합 포트" 또는 "로컬 포트" 항목을 찾아 아직 사용되지 않은 번호로 바로 변경하면 됩니다. 10000 이상의 상위 포트, 예를 들어 17890이나 27890을 추천하며, 시스템에서 자주 쓰는 포트 구간은 피하는 것이 좋습니다. 저장하면 클라이언트가 자동으로 코어를 재시작해 적용됩니다.

방법 2: 설정 파일 직접 수정

클라이언트에 해당 설정 항목이 없거나 명령줄로 코어를 직접 실행하는 경우, 설정 파일에서 수동으로 수정할 수 있습니다:

mixed-port: 17890
allow-lan: false
mode: rule
log-level: info

설정 파일이 통합된 mixed-port 대신 예전 방식의 분리형 포트(port는 HTTP, socks-port는 SOCKS5)를 사용한다면, 충돌하는 쪽의 포트 번호를 마찬가지로 변경해야 합니다:

port: 17891
socks-port: 17892

포트 변경 후 함께 확인해야 할 항목

포트를 바꾸고 설정을 저장하는 것으로 끝이 아닙니다. 몇 가지 연동되는 부분을 놓치기 쉬운데, 이럴 경우 프록시가 "켜져 있지만 실제로 적용되지 않는" 상태처럼 보일 수 있습니다:

• 시스템 프록시 설정: 클라이언트에서 "시스템 프록시로 설정"과 같은 옵션을 켜둔 경우, 시스템에 기록된 포트 번호는 이전 값 그대로입니다. 이 옵션을 껐다가 다시 켜서 새 포트로 갱신해야 합니다.
• 브라우저 확장 프로그램: SwitchyOmega와 같은 일부 프록시 전환 확장 프로그램은 별도로 포트 설정을 저장하며, 클라이언트 설정과는 독립된 데이터입니다. 확장 프로그램 설정에 들어가 새 포트로 직접 수정해야 합니다.
• 명령줄 도구의 프록시 환경변수: export https_proxy=http://127.0.0.1:7890처럼 터미널에 프록시를 지정하는 습관이 있다면 포트 번호도 함께 바꿔야 합니다. 그렇지 않으면 터미널 요청이 여전히 이전 포트를 향하다가 연결에 실패합니다.
• 같은 네트워크의 다른 기기: 이 컴퓨터의 로컬 네트워크 프록시를 통해 인터넷을 쓰는 다른 기기가 있다면, 그쪽에 저장된 주소의 포트 번호도 갱신해야 합니다.

흔한 포트 점유 원인

Clash 자체의 잔여 프로세스 외에도 7890 포트 충돌은 다음과 같은 프로그램에서 자주 발생하니, 점검 시 우선적으로 의심해 볼 수 있습니다:

1. Clash 계열 클라이언트를 두 개 설치: 예를 들어 컴퓨터에 Clash Verge와 ClashX Meta를 동시에 설치했다면 둘 다 기본 포트가 7890이므로, 하나가 먼저 실행되면 다른 하나는 반드시 충돌합니다. 상시 사용할 클라이언트는 하나만 유지하는 것을 권장합니다.
2. 명령줄로 실행한 코어가 정상적으로 종료되지 않음: 터미널에서 수동으로 코어 프로그램을 디버깅할 때 Ctrl+C가 아닌 방식으로 터미널 창을 강제로 닫으면 코어 프로세스가 고아 프로세스로 남아 포트를 계속 점유할 수 있습니다. 앞서 소개한 명령으로 직접 찾아서 종료해야 합니다.
3. 다른 프록시나 패킷 캡처 도구: 일부 네트워크 디버깅 도구, 다운로드 관리자에 내장된 프록시 모듈이 종종 7890이라는 흔한 포트 번호를 사용하는 경우가 있어 Clash와 충돌할 가능성이 낮지 않습니다.
4. 가상 머신이나 컨테이너 포트 매핑: 로컬에서 가상 머신이나 Docker 컨테이너를 실행 중이고 컨테이너 내부 서비스를 호스트의 7890 포트로 매핑해 두었다면 마찬가지로 점유가 발생합니다. 이 경우 Clash가 아니라 컨테이너의 매핑 포트를 바꾸는 것을 권장합니다.

충돌 원인을 찾은 뒤에는 점유 프로세스를 종료할지 Clash의 포트를 변경할지, 어느 프로그램이 기본 포트를 더 필요로 하는지에 따라 결정하면 됩니다. 대부분의 일상적인 사용 환경에서는 Clash의 mixed-port를 자주 쓰이지 않는 상위 포트로 바꾸는 것이 가장 간단한 일회성 해결책이며, 변경 후에는 같은 충돌을 다시 겪는 경우가 거의 없습니다.