Clash 포트 사용 중 오류 해결법: 7890 충돌 프로세스 확인과 포트 변경 절차

Clash 계열 클라이언트(mihomo 코어 기반 각종 GUI 포함)는 실행 시 시스템이나 브라우저에서 오는 프록시 요청을 받기 위해 일련의 로컬 포트를 열려고 시도합니다. 가장 대표적인 것이 믹스 포트 7890(mixed-port)으로, HTTP와 SOCKS5 두 프로토콜의 연결을 동시에 처리합니다. 이 포트가 이미 다른 프로그램에 점유되어 있으면 코어는 로그에 아래와 같은 오류를 남기고 즉시 종료됩니다:

FATA[0000] Start Mixin server error: listen tcp 127.0.0.1:7890: bind: address already in use

이 로그의 핵심은 bind: address already in use입니다. 구독이나 규칙 문제가 아니라 운영체제 차원에서 이 포트 번호가 이미 사용 중이라서 새 프로세스가 같은 포트에 바인딩할 수 없다는 뜻입니다. 흔히 함께 문제가 되는 포트로는 7891(일부 클라이언트의 SOCKS 포트), 9090(외부 컨트롤러 포트, external-controller), 53(DNS 리스닝 포트)이 있습니다. 확인 방법은 모두 동일하므로, 이 글에서는 가장 흔히 마주치는 7890을 예로 설명합니다.

7890은 시스템 예약 포트가 아니므로 이론상 어떤 프로그램이든 먼저 점유할 수 있지만, 실제로 가장 자주 발생하는 상황은 다음과 같습니다:

• 같은 기기에서 Clash 계열 클라이언트를 두 개 실행한 경우. 예를 들어 Clash Verge Rev와 Clash Plus를 동시에 설치하고 둘 다 기본값인 7890을 사용하면, 앞서 실행한 것이 완전히 종료되지 않은 상태에서 뒤에 실행한 쪽이 포트를 잡지 못합니다.
• 이전 프로세스가 정상적으로 종료되지 않은 경우. 시스템 절전, 작업 관리자에서 강제 종료, 코어 크래시로 하위 프로세스가 정리되지 않는 등의 상황에서 좀비 프로세스가 포트를 계속 점유합니다.
• 다른 프록시 도구가 같은 기본 포트를 사용하는 경우. 일부 구버전 프록시 도구나 패킷 캡처 도구(특정 설정의 디버그 프록시 등)도 기본값으로 7890 또는 인근 번호대를 사용합니다.
• Docker 컨테이너나 WSL2 내부 서비스가 포트 매핑을 한 경우로, 컨테이너 내부 서비스를 호스트의 7890에 매핑한 상태입니다.

어떤 경우든 먼저 누가 점유하고 있는지 확인한 뒤, 그것을 종료할지 아니면 Clash 쪽 포트를 바꿀지 결정하는 것이 순서입니다. 무작정 컴퓨터를 재부팅하면 일시적으로 해결되기도 하지만, 원인을 모르면 다음에 또 재발합니다.

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

netstat -ano | findstr :7890

정상적으로는 아래와 같은 한 줄 또는 여러 줄이 출력됩니다:

TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    18420

마지막 열의 18420이 해당 포트를 점유한 프로세스의 PID입니다. 이 PID로 프로세스 이름을 조회합니다:

tasklist | findstr 18420

출력 결과가 이전에 종료되지 않은 클라이언트 메인 프로세스(예: clash-verge.exe 또는 mihomo.exe)라면, 잔류 프로세스가 확실하므로 작업 관리자에서 직접 종료하거나 다음을 실행합니다:

taskkill /PID 18420 /F

종료 후 클라이언트를 다시 실행하면 됩니다. PID가 낯선 프로그램에 해당한다면 먼저 그 용도를 확인한 뒤 해당 프로그램을 종료할지, 혹은 Clash의 리스닝 포트를 바꿀지(아래 참고) 판단합니다.

macOS와 대부분의 Linux 배포판에는 lsof(List Open Files)가 기본 포함되어 있어, netstat보다 더 직관적으로 포트를 확인할 수 있습니다:

lsof -i :7890

출력 예시:

COMMAND     PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
mihomo    22187 alice    7u  IPv4 0x1a2b      0t0  TCP 127.0.0.1:7890 (LISTEN)

COMMAND 열에 프로세스 이름이, PID 열에 프로세스 번호가 바로 표시됩니다. 잔류한 Clash 코어 프로세스임을 확인했다면 종료합니다:

kill -9 22187

시스템에 lsof가 없는 경우(일부 경량 Linux 컨테이너), ss 명령으로 대체할 수 있습니다:

ss -tlnp | grep 7890

이 명령도 끝부분에 pid= 필드를 표시하며 조작 방식은 앞과 동일합니다. Linux에서 일반 사용자 권한으로 종료할 수 없는 프로세스가 포트를 점유하고 있다면 명령 앞에 sudo를 붙여야 합니다.

7890을 점유한 것이 함부로 끄기 어려운 상시 실행 프로그램(예: 장기간 실행이 필요한 다른 도구)이라면, 남을 건드리기보다 Clash 쪽 포트를 바꾸는 것이 더 간단합니다. 대부분의 GUI 클라이언트는 설정 화면에 포트 변경 메뉴를 제공하며, 일반적인 절차는 다음과 같습니다:

1. 클라이언트 설정 패널 열기

   메인 화면에서 "설정" 또는 톱니바퀴 아이콘을 찾아 네트워크 / 포트 관련 설정 영역으로 이동합니다. 클라이언트마다 명칭은 조금씩 다르지만 믹스 포트, HTTP 포트, SOCKS 포트 등의 항목이 함께 모여 있습니다.

2. 믹스 포트(Mixed Port) 항목 찾기

   기존의 7890을 점유되지 않은 포트 번호, 예를 들어 17890이나 7899로 변경합니다. 1024 이상 10000 이하이면서 흔하지 않은 번호대를 선택해 다른 소프트웨어와 다시 충돌하지 않도록 하는 것이 좋습니다.

3. 저장 후 코어 재시작

   대부분의 클라이언트는 포트 변경 후 "코어 재시작" 또는 "적용" 버튼을 눌러야 반영됩니다. 설정 페이지만 저장하면 즉시 재바인딩되지 않을 수 있습니다.

4. 시스템 프록시 포트도 함께 업데이트

   클라이언트에서 "시스템 프록시로 설정" 기능을 사용 중이라면, 믹스 포트 변경 후 시스템 프록시 설정의 포트 번호도 함께 갱신됐는지 반드시 확인하세요. 그렇지 않으면 코어는 정상 작동하지만 트래픽이 연결되지 않는 문제가 발생합니다.

직접 관리하는 설정 파일을 사용 중이거나 클라이언트 화면에 일시적으로 접근할 수 없다면, YAML 설정을 직접 편집해도 됩니다. 구독 설정 파일에서 아래 몇 줄을 찾습니다(필드명은 버전에 따라 다소 다를 수 있습니다):

mixed-port: 7890
allow-lan: true
external-controller: 127.0.0.1:9090

mixed-port 뒤의 값을 비어 있는 포트로 바꾸면 됩니다. 예를 들면:

mixed-port: 17890

클라이언트가 통합 mixed-port가 아니라 별도의 HTTP 포트와 SOCKS 포트를 사용하는 경우, 해당 필드는 보통 다음과 같습니다:

port: 7890
socks-port: 7891

필요에 따라 각각 수정합니다. external-controller는 별도의 포트(기본값 9090)를 사용하며, 패널 / 대시보드용 관리 인터페이스로 트래픽 포워딩 포트와는 완전히 다른 용도입니다. 오류 메시지에서 9090이 점유되었다고 나온다면 mixed-port가 아니라 이 항목을 수정해야 합니다. 수정 후 저장하고 클라이언트를 재시작하거나 설정을 다시 불러와야 새 포트가 적용됩니다.

포트 번호를 변경한 뒤에는 기존에 7890을 참조하던 다른 설정도 함께 조정해야 "클라이언트는 실행됐지만 웹 페이지가 열리지 않는" 새로운 문제를 피할 수 있습니다:

• 브라우저 확장 프로그램의 프록시 포트. SwitchyOmega 같은 브라우저 확장에서 프록시 주소 127.0.0.1:7890을 수동으로 설정했다면, 포트 변경 후 확장 프로그램 쪽 포트 번호도 함께 수정해야 합니다.
• 시스템 수준 프록시 설정. Windows의 "설정 → 네트워크 및 인터넷 → 프록시", macOS의 "시스템 설정 → 네트워크 → 프록시"에서 포트 번호를 수동으로 입력해 뒀다면 마찬가지로 업데이트해야 합니다.
• TUN 모드는 영향을 받지 않습니다. 시스템 프록시가 아니라 TUN 모드를 사용 중이라면 트래픽은 mixed-port가 아닌 가상 네트워크 어댑터를 통해 흐르므로, 포트 변경이 기존 TUN 설정에 영향을 주지 않는 경우가 많습니다. 다만 코어가 완전히 재로드되도록 클라이언트를 한 번 재시작하는 것을 권장합니다.

점유 프로세스를 종료하거나 포트를 변경한 뒤, 감으로 "이제 됐겠지"라고 넘기지 말고 명령으로 한 번 더 확인하는 것이 가장 확실합니다. Windows에서 다시 실행합니다:

netstat -ano | findstr :7890

아무 출력이 없다면 해당 포트가 현재 비어 있다는 뜻이므로 안심하고 사용할 수 있습니다. macOS / Linux에서는 다음을 실행합니다:

lsof -i :7890

마찬가지로 출력이 없으면 포트가 비어 있는 상태입니다. 이후 Clash 클라이언트를 다시 실행하면, 정상적인 경우 로그에 이전의 FATA 오류가 아니라 아래와 같은 성공 메시지가 나타납니다:

INFO[0000] Mixed(http+socks) proxy listening at: 127.0.0.1:7890

이 줄이 보이면 믹스 포트 바인딩이 성공했고 클라이언트가 정상적으로 리스닝 상태에 진입했다는 뜻이므로, 이어서 시스템 프록시나 브라우저 확장 설정을 진행하면 됩니다.

극히 드문 경우지만, "비어 있어 보이는" 포트로 바꿔도 동일한 바인딩 오류가 계속 발생한다면 아래 항목을 추가로 확인해 보세요:

1. 실제로 로드되는 설정 파일을 수정했는지 확인

   일부 클라이언트는 여러 설정 파일(프로필)을 관리하는데, A 파일을 수정했지만 클라이언트가 실제로 불러오는 것은 B 파일이라면 변경 사항이 반영되지 않습니다.

2. 보안 소프트웨어가 포트 리스닝을 차단하고 있는지 확인

   일부 보안 프로그램은 알 수 없는 프로그램의 로컬 포트 바인딩을 차단합니다. Clash 클라이언트를 신뢰 목록에 추가하거나 관련 차단 항목을 임시로 해제한 뒤 다시 테스트해 보세요.

3. 완전히 흔하지 않은 포트 번호로 다시 테스트

   일부 번호대는 시스템이나 다른 백그라운드 서비스가 예약해 둔 경우가 있습니다. 다섯 자리에 정천 단위가 아닌 포트(예: 27891)로 바꿔 다시 시도하면 번호대 자체의 문제인지 배제할 수 있습니다.

이 항목들을 하나씩 확인하면 포트 점유 관련 문제의 대부분을 해결할 수 있습니다. 이런 유형의 문제는 결국 한 가지 원칙으로 정리됩니다: 먼저 시스템 명령으로 포트를 누가 점유했는지 확인한 뒤, 그것을 종료할지 Clash 쪽 포트를 바꿀지 결정하면 되며, 클라이언트를 재설치하거나 구독을 다시 받을 필요는 없습니다.