Clash 실행 시 포트 사용 중 오류 해결하기: 점유 프로세스 확인부터 포트 변경까지 전체 과정
7890/9090 포트 충돌은 Clash 실행 실패의 주요 원인입니다. Windows·macOS·Linux에서 점유 프로세스를 찾는 명령어와 설정 파일·클라이언트에서 포트를 안전하게 변경하는 방법을 정리했습니다.
왜 '포트 사용 중' 오류가 발생하는가
Clash 코어는 실행 시 프록시 서비스를 제공하기 위해 몇 개의 고정 포트를 바인딩해야 합니다. 혼합 프록시 포트(보통 7890, 설정 필드명은 mixed-port이며 구버전에서는 port와 socks-port로 나뉘어 있을 수 있음), 외부 컨트롤러 포트(보통 9090, 필드명 external-controller), 일부 클라이언트는 추가로 DNS 리스닝 포트도 점유합니다. 이 포트들이 시스템 내 다른 프로세스에 의해 이미 점유되어 있으면 운영체제가 재바인딩을 거부하며, 코어는 로그에 "address already in use", "bind: 포트가 이미 사용 중입니다"와 같은 메시지를 출력합니다. 클라이언트에서는 실행 버튼을 누르면 즉시 튕기거나 연결 상태가 계속 미연결로 표시되거나, 아예 오류 팝업이 뜨는 형태로 나타납니다.
포트 점유의 원인은 대략 세 가지로 나뉩니다. 첫 번째는 '중복 실행'입니다. 같은 컴퓨터에 두 개의 Clash 계열 클라이언트가 설치되어 있거나(예: Clash Verge와 예전에 쓰던 Clash for Windows를 동시에 설치), 지난번 종료 시 프로세스가 완전히 정리되지 않아 백그라운드에 좀비 인스턴스가 남아 포트를 붙잡고 있는 경우입니다. 두 번째는 '포트 충돌'입니다. 다른 도구가 마침 7890이나 9090을 사용하는 경우로, 일부 개발용 디버깅 프록시, 기업용 VPN 클라이언트, 라우팅 테스트 도구가 흔하며, 심지어 일부 데이터베이스나 메시지 큐 서비스의 기본 포트도 인접한 범위에 걸릴 수 있습니다. 세 번째는 시스템 차원의 포트 예약으로, 특히 Windows에서는 일부 시스템 서비스가 특정 포트 구간을 예약해 두는데 마침 7890이 그 안에 포함되는 경우이며, 이런 경우 작업 관리자에서 직접 대응하는 프로세스 이름을 찾기 어렵습니다.
문제 해결 순서는 두 단계로 통일할 수 있습니다. 먼저 누가 포트를 점유하고 있는지 확인한 뒤, '점유 프로세스 종료' 또는 'Clash 포트 변경' 중 어느 방법을 택할지 결정합니다. 대부분의 경우 포트를 변경하는 쪽이 더 간단합니다. 다른 소프트웨어의 설정을 건드릴 필요가 없고 위험도도 더 낮기 때문입니다.
Windows에서 점유 프로세스 확인하기
명령 프롬프트 또는 PowerShell을 열고, 먼저 netstat 명령으로 포트에 해당하는 프로세스 ID(PID)를 확인합니다:
netstat -ano | findstr "7890"출력 결과의 마지막 열 숫자가 PID입니다. 작업 관리자 또는 아래 명령으로 프로세스 이름을 확인할 수 있습니다:
tasklist | findstr "PID번호"9090 포트에서도 충돌이 발생한다면 명령의 포트 번호를 9090으로 바꿔서 다시 확인하면 됩니다. 무관한 프로세스가 점유하고 있는 것으로 확인되면 해당 프로세스를 바로 종료하거나, 그 소프트웨어의 설정에서 포트를 변경하면 됩니다. 만약 확인된 프로세스가 Clash 자체의 이전 인스턴스라면(예: clash-verge.exe나 mihomo.exe가 백그라운드에 잔류), 작업 관리자에서 해당 프로세스를 수동으로 종료한 뒤 클라이언트를 다시 실행하면 대부분 해결됩니다.
netstat으로 구체적인 프로세스를 찾을 수 없는 경우가 있습니다(PID가 0이나 시스템 프로세스로 표시됨). 이럴 때는 점유 프로세스를 찾으려고 애쓰기보다 바로 Clash 자체의 포트를 변경하는 것이 가장 시간을 절약하는 방법입니다.macOS에서 점유 프로세스 확인하기
터미널을 열고 lsof 명령으로 포트 점유 상태를 확인하는 것이 가장 직접적인 방법입니다:
lsof -i :7890출력 결과의 COMMAND 열이 해당 포트를 점유한 프로세스 이름이고, PID 열이 프로세스 번호입니다. 9090 포트도 숫자만 바꿔서 동일하게 확인하면 됩니다. 점유 프로세스를 종료하려면:
kill -9 해당 PID번호
macOS에서 흔히 발생하는 상황은 Clash Verge와 예전 ClashX 계열 클라이언트를 동시에 설치한 경우입니다. 두 클라이언트의 기본 포트가 같기 때문에 하나가 백그라운드에 상주(예: 로그인 시 자동 실행 설정)하고 있으면 다른 하나를 실행할 때 충돌이 발생합니다. 시스템 설정의 로그인 항목을 한번 점검해서 기본적으로 자동 실행되는 클라이언트를 하나만 남겨두는 것을 권장합니다.
Linux에서 점유 프로세스 확인하기
Linux 시스템에서는 ss 명령을 사용하는 것을 권장합니다(기존 netstat보다 빠르고 대부분의 최신 배포판에 기본 탑재되어 있습니다):
ss -tulnp | grep 7890시스템에 ss가 없다면 netstat이나 lsof를 대신 사용할 수 있습니다:
lsof -i :7890프로세스 PID를 확인한 뒤 kill 명령으로 종료합니다:
kill -9 해당 PID번호명령줄 코어(mihomo/Clash 코어)를 systemd로 서비스 관리하는 사용자는 특히 주의해야 합니다. 코어가 systemd 유닛 파일을 통해 실행된 경우, 프로세스를 직접 kill해도 systemd가 재시작 정책에 따라 자동으로 다시 띄워 포트를 다시 점유할 수 있습니다. 이런 경우에는 반복해서 kill하지 말고, 먼저 systemctl stop으로 해당 서비스 유닛을 중지한 뒤 포트가 해제되었는지 확인하고 충돌 원인을 조사해야 합니다.
설정 파일에서 포트 변경하기
종료할 수 없는 다른 프로그램이 포트를 점유하고 있다면, 그 소프트웨어를 건드리기보다 Clash의 포트를 바꾸는 것이 가장 깔끔한 방법입니다. 핵심 설정 필드는 config.yaml 상단에 모여 있습니다:
mixed-port: 7891
allow-lan: false
external-controller: 127.0.0.1:9091
secret: ""mixed-port를 사용 중이지 않은 포트로 바꿉니다(1024~65535 범위 내에서 일반적인 서비스와 충돌하지 않는 숫자를 권장하며, 7891이나 17890 등이 적절합니다). external-controller 뒤의 포트 번호도 같은 방식으로 수정하되, 여기는 "주소:포트" 형식으로 완전히 작성해야 하므로 콜론 앞의 리스닝 주소를 빠뜨리지 않도록 주의합니다. 일부 오래된 설정 파일에서는 통합된 mixed-port 대신 분리된 port(HTTP 프록시 포트)와 socks-port(SOCKS5 프록시 포트) 두 필드를 여전히 사용하는데, 이 경우도 마찬가지로 필요에 따라 사용 중이지 않은 숫자로 바꾸면 됩니다. 원리는 동일합니다.
클라이언트 화면에서 포트 변경하기
YAML을 직접 편집하고 싶지 않다면, 주요 클라이언트들은 설정 화면에 포트 입력란을 제공합니다. 대체로 다음과 같은 순서로 진행합니다:
클라이언트 설정 열기
'설정' 또는 '일반' 분류에서 '혼합 포트', 'HTTP 포트', 'SOCKS 포트' 또는 '프록시 포트'라는 이름의 입력 항목을 찾습니다.
새 포트 번호 입력
사용 중이지 않은 것으로 확인된 포트 번호를 입력합니다. 앞서 소개한 명령으로 해당 포트가 현재 비어 있는지 먼저 확인하는 것을 권장합니다.
컨트롤 포트도 함께 변경
클라이언트에 '외부 컨트롤 포트'나 'API 포트'(
external-controller에 대응)가 별도로 표시되어 있다면 이것도 비어 있는 값으로 함께 변경합니다. 두 포트가 서로 충돌하지 않으면 됩니다.저장 후 서비스 재시작
설정을 저장하면 클라이언트가 보통 코어 재시작이나 앱 재시작이 필요하다는 안내를 표시합니다. 안내에 따라 진행하면 되며, 재시작 안내가 뜨기 전에 연결 버튼을 반복해서 누르지 않도록 합니다.
시스템 프록시 설정 확인
시스템 네트워크 프록시 설정에 포트 번호를 수동으로 입력해 두었다면(클라이언트 자동 설정을 따르지 않는 경우), 시스템 프록시의 포트 번호도 새 값으로 함께 변경해야 합니다. 그렇지 않으면 트래픽이 여전히 이전 포트로 향해 연결에 실패합니다.
포트 변경 후 적용 여부 확인하기
클라이언트를 재시작한 뒤에는 브라우저를 바로 열어 테스트하기보다(브라우저 테스트는 시스템 프록시 설정이나 DNS 캐시 등의 영향을 받아 정확하지 않을 수 있습니다) 먼저 명령줄로 새 포트가 리스닝 상태인지 확인합니다. Windows에서는 netstat -ano | findstr "새포트번호"를 계속 사용하며, LISTENING 상태가 보이면 코어가 정상적으로 바인딩된 것입니다. macOS와 Linux에서는 lsof -i :새포트번호를 사용해 Clash 코어 프로세스 이름(흔히 mihomo, clash-meta 또는 클라이언트에 내장된 코어 실행 파일 이름)이 확인되면 정상입니다.
리스닝 상태를 확인한 뒤에는 시스템 프록시나 브라우저 확장 프로그램에 입력한 포트 번호가 새 포트와 일치하는지 확인합니다. 양쪽이 일치해야 실제로 연결됩니다. 컨트롤 패널형 클라이언트에 내장된 '연결 테스트'나 '지연 시간 측정' 기능을 사용하는 경우, 이제는 정상적으로 결과가 반환되어야 하며 연결 거부 오류는 더 이상 나타나지 않아야 합니다.
포트 충돌을 예방하는 몇 가지 습관
다음에 같은 문제를 겪지 않으려면 몇 가지 작은 습관을 들이는 것이 좋습니다. 첫째, 같은 기기에는 가능한 한 Clash 계열 클라이언트를 하나만 유지하고, 새 버전으로 업그레이드하기 전에 이전 버전을 삭제하거나 완전히 종료해서 두 클라이언트가 백그라운드에서 서로 충돌하지 않도록 합니다. 둘째, PC에서 다른 프록시 도구를 함께 사용하거나 특정 포트를 고정으로 써야 하는 개발 환경이 있다면, Clash의 포트를 미리 잘 쓰이지 않는 숫자(예: 다섯 자리의 높은 번호대)로 설정해 근본적으로 충돌을 피합니다. 셋째, 포트 설정을 변경할 때마다 어떤 값으로 바꾸었는지 기록해 두면 다음에 문제를 조사할 때 대조하기 편합니다. 특히 팀이 설정 파일을 공유하는 경우에는 포트 번호를 변경할 때 설정 파일 상단에 주석으로 설명을 남기는 것이 좋습니다.
만약 같은 프로그램에서 포트 충돌이 반복해서 발생한다면(예: 고정으로 설치된 회사 소프트웨어가 9090을 장기간 점유하는 경우), 매번 임시로 자리를 비켜주기보다 Clash의 기본 포트를 영구적으로 바꾸는 것이 더 근본적인 해결책입니다. 이렇게 하면 설정 파일과 클라이언트 설정을 한 번만 변경하면 되고, 장기적으로 사용해도 다시 중단될 일이 없습니다.