Clash 포트 충돌 해결: 7890 already in use 원인 진단 및 리스닝 포트 변경 가이드

포트 충돌은 왜 발생하는가

Clash 코어(원조 Clash든 Mihomo든)는 실행 시 프록시 트래픽을 받기 위해 로컬 포트 하나를 바인딩하는데, 기본값은 보통 7890입니다. 이 포트는 설정 파일의 mixed-port 필드에 해당합니다(초기 버전에서는 port와 socks-port로 나뉘어 있었지만, 현재 대부분의 클라이언트는 HTTP와 SOCKS5를 동시에 지원하는 mixed-port로 통합되었습니다). 이미 다른 프로세스가 해당 포트를 점유하고 있으면 코어가 리스닝 포트를 바인딩하는 과정에서 실패하며, 로그에는 대개 아래와 비슷한 메시지가 출력됩니다.

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

이 오류의 본질은 간단합니다. 같은 포트는 동시에 한 프로세스만 독점적으로 리스닝할 수 있습니다. 충돌 원인은 대체로 세 가지입니다. 첫째는 중복 실행으로, 이전 Clash 프로세스가 정상적으로 종료되지 않은 상태에서 새 인스턴스를 또 실행해 옛 프로세스가 포트를 계속 점유하는 경우입니다. 둘째는 다른 프로그램이 먼저 포트를 점유한 경우로, 다른 프록시 도구(v2ray, trojan, 다른 Clash 파생 클라이언트 등), 개발 환경의 로컬 서비스, 심지어 일부 컨테이너의 포트 매핑 등이 흔한 사례입니다. 셋째는 같은 컴퓨터에서 Clash 관련 서비스 두 개가 동시에 돌아가는 경우로, 예를 들어 시스템 서비스로 등록된 clash와 사용자가 수동으로 실행한 테스트 인스턴스가 함께 존재하는 상황입니다.

원인이 무엇이든 처리 방식은 동일합니다. 먼저 누가 포트를 점유하고 있는지 정확히 찾아낸 뒤, 그 프로세스를 종료할지 아니면 Clash의 포트를 바꿀지 결정하면 됩니다.

ss / lsof / netstat으로 점유 프로세스 찾기

리눅스에서 포트 점유 여부를 확인하는 데 흔히 쓰는 도구는 세 가지이며, 아무거나 골라 사용하면 됩니다. 다만 최신 배포판에 기본 탑재되어 있고 성능도 가장 좋은 ss를 우선 추천합니다.

방법 1: ss 명령어

sudo ss -tulnp | grep 7890

출력에서 로컬 주소, 포트 번호, 그리고 해당 포트를 점유한 프로세스명과 PID를 확인할 수 있습니다. 예를 들면 다음과 같습니다.

tcp   LISTEN 0      4096   127.0.0.1:7890   0.0.0.0:*   users:(("mihomo",pid=8123,fd=12))

괄호 안의 pid=8123이 포트를 점유한 프로세스 ID이고, "mihomo"가 프로세스명입니다. 여기서 표시된 것이 Clash 자체의 코어 프로세스(mihomo 또는 clash)라면 이전 인스턴스가 제대로 종료되지 않았다는 뜻이므로, 해당 프로세스를 종료하고 클라이언트를 다시 실행하면 됩니다.

방법 2: lsof 명령어

시스템에 ss가 설치되어 있지 않거나 lsof를 더 즐겨 쓴다면 다음과 같이 확인할 수 있습니다.

sudo lsof -i :7890

출력에는 COMMAND, PID, USER 등의 항목이 나열되며, 마찬가지로 점유 프로세스의 이름과 PID를 확인할 수 있습니다. lsof는 일부 경량화 배포판에는 기본 설치되어 있지 않아 별도로 설치해야 할 수 있습니다. Ubuntu/Debian 계열은 sudo apt install lsof, Fedora 계열은 sudo dnf install lsof로 설치합니다.

방법 3: netstat 명령어

netstat은 최신 배포판에서 점차 ss로 대체되고 있지만, 여전히 많은 스크립트와 오래된 튜토리얼에서 사용되고 있습니다. 확인 방법은 다음과 같습니다.

sudo netstat -tulnp | grep 7890

세 명령어로 얻는 정보는 본질적으로 동일하므로, 자신의 시스템에서 잘 작동하는 것 하나만 선택하면 되며 모두 설치할 필요는 없습니다.

참고

grep 결과가 아무것도 나오지 않는다면 실제로는 7890 포트가 점유된 상태가 아니라는 뜻입니다. 이 경우 오류의 원인은 설정 파일의 다른 부분에 잘못된 주소가 적혀 있거나(예: bind-address 설정 오류) 권한 문제로 바인딩이 실패한 것일 수 있으며, 단순한 포트 충돌이 아닙니다. 이때는 포트 문제에 매달리지 말고 전체 실행 로그를 확인해야 합니다.

프로세스를 종료할지, 포트를 바꿀지 판단하기

점유 프로세스를 찾아낸 뒤의 처리 방식은 그 프로세스가 무엇인지에 따라 달라집니다.

Clash/Mihomo 자신의 잔존 프로세스인 경우: 이전 실행이 정상적으로 종료되지 않았다는 뜻이므로, 해당 PID를 종료하고 클라이언트를 다시 시작하면 됩니다. 설정을 바꿀 필요는 없습니다.
```
sudo kill 8123
# 일반적인 종료가 안 될 때 아래 명령 사용
sudo kill -9 8123
```
다른 프록시 도구나 장기 실행 서비스인 경우: 이런 프로세스는 대개 명확한 용도가 있으므로 함부로 종료하지 않는 것이 좋습니다. Clash 쪽 포트를 충돌하지 않는 값으로 바꾸는 것이 더 안전한 방법입니다.
용도를 알 수 없는 프로세스인 경우: 먼저 ps -p PID -o comm=,args=로 전체 실행 명령을 확인해 시스템 핵심 서비스(일부 컨테이너 네트워크 구성 요소, 데이터베이스 클라이언트 프록시 등)인지 판단합니다. 확실하지 않다면 프로세스를 종료하기보다 포트를 바꾸는 쪽을 우선 선택해 다른 서비스에 영향을 주지 않도록 합니다.

일반적인 기준은 다음과 같습니다. 충돌 상대가 Clash 자신의 옛 프로세스라면 종료하는 것이 가장 깔끔한 해결책이고, 충돌 상대가 무관한 서드파티 서비스라면 프로세스를 종료하기보다 포트를 바꾸는 쪽이 더 안전합니다. 특히 서버나 여러 사람이 함께 쓰는 컴퓨터에서는 익숙하지 않은 프로세스를 함부로 종료하면 위험이 더 큽니다.

mixed-port 수정 후 코어 재시작

포트를 바꾸기로 결정했다면 Clash 설정 파일을 찾습니다(GUI 클라이언트는 대개 설정 화면에서 설정 파일 경로를 확인할 수 있고, CLI로 배포한 경우 ~/.config/clash/config.yaml이나 /etc/clash/config.yaml 같은 경로가 흔합니다). 그런 다음 mixed-port를 아직 점유되지 않은 포트, 예를 들어 7891로 수정합니다.

mixed-port: 7891
allow-lan: false
bind-address: "*"
mode: rule
log-level: info

설정 파일에 예전 방식인 port와 socks-port가 분리되어 남아 있다면 이것도 함께 수정해야 하며, 다른 곳에 옛 포트 번호가 남아 있지 않은지도 확인합니다.

port: 7891
socks-port: 7892

포트를 바꾼 뒤에는 새로 지정한 포트 번호도 이미 점유되어 있지 않은지 먼저 확인해야 합니다. 앞서와 같이 ss -tulnp | grep 포트번호로 다시 한 번 확인해 애써 바꿨는데도 또 다른 충돌과 부딫히는 일을 피하세요. 문제가 없다면 Clash 서비스나 클라이언트를 재시작해 설정을 적용합니다.

# systemd로 관리되는 경우
sudo systemctl restart clash

# 코어를 수동으로 실행하는 경우, 먼저 기존 프로세스를 종료한 뒤 재시작
sudo pkill mihomo
mihomo -d /etc/clash

재시작 후 다시 실행 로그를 확인해 bind: address already in use 오류가 더 이상 나오지 않는지, 그리고 리스닝 포트가 정상적으로 전환되었는지 확인합니다.

sudo ss -tulnp | grep mihomo

시스템 프록시 설정 동기화

mixed-port만 수정하면 코어가 리스닝하는 위치만 바뀔 뿐이며, 운영체제나 브라우저의 프록시 설정에 옛 포트 번호가 여전히 남아 있으면 트래픽이 여전히 통하지 않습니다. 이 단계는 자주 빠뜨리는 부분이라, 포트를 바꿔도 안 되는 것처럼 오해하는 경우가 많습니다.

GNOME 데스크톱 환경

gsettings set org.gnome.system.proxy mode 'manual'
gsettings set org.gnome.system.proxy.http host '127.0.0.1'
gsettings set org.gnome.system.proxy.http port 7891
gsettings set org.gnome.system.proxy.https host '127.0.0.1'
gsettings set org.gnome.system.proxy.https port 7891

「설정 → 네트워크 → 네트워크 프록시」의 그래픽 화면에서 직접 포트 번호를 새 값으로 바꿀 수도 있습니다.

명령줄 환경 변수

환경 변수 방식으로 프록시를 사용하는 데 익숙하다면 이쪽 포트도 함께 바꿔야 하며, ~/.bashrc나 ~/.zshrc에 적어 두면 계속 유지됩니다.

export http_proxy="http://127.0.0.1:7891"
export https_proxy="http://127.0.0.1:7891"
export all_proxy="socks5://127.0.0.1:7891"

수정 후에는 source ~/.bashrc를 실행해 현재 터미널에 즉시 적용하는 것을 잊지 마세요. 그러지 않으면 이미 열려 있던 터미널 창은 계속 옛 포트를 사용합니다.

브라우저 확장 프로그램

SwitchyOmega 같은 프록시 전환 브라우저 확장으로 규칙을 설정했다면, 확장 프로그램 설정에 들어가 포트 번호를 7890에서 새 포트로 바꿔야 합니다. 확장 프로그램 쪽 포트와 시스템 포트는 서로 독립된 설정이라 자동으로 연동되지 않습니다.

주의

TUN 모드로 전체 트래픽을 처리하도록 설정했다면, TUN 모드 자체는 mixed-port로 지정하는 HTTP/SOCKS 포트를 사용하지 않으므로 이번 포트 충돌의 영향을 받지 않습니다. 다만 시스템 프록시나 브라우저 확장이 여전히 옛 포트를 가리키고 있다면 TUN 모드를 끄는 순간 해당 설정이 작동하지 않게 되므로 함께 점검해야 합니다.

놓치기 쉬운 그 외 세부 사항

부팅 시 자동 실행 스크립트의 옛 포트 번호: systemd 등으로 부팅 시 자동 실행을 설정했다면 스크립트나 환경 변수 파일에 포트 번호가 별도로 하드코딩되어 있을 수 있습니다. 설정 파일의 mixed-port만 바꾸는 것으로는 충분하지 않으니 시작 스크립트도 함께 확인해야 합니다.
외부 컨트롤 패널 포트: 설정 파일의 external-controller(보통 9090)는 Clash의 API 관리 포트이며, 프록시 포트인 mixed-port와는 별개의 항목입니다. 9090도 점유되어 있으면 패널을 열 수 없게 되므로 같은 방식으로 별도 확인하면 됩니다.
한 컴퓨터를 여러 사용자가 함께 쓰는 경우: 같은 서버에서 여러 사용자가 각자 Clash 설정을 돌린다면, 충돌을 줄이기 위해 사용자별로 다른 포트 구간을 쓰는 것이 좋습니다. 예를 들어 사용자 A는 7890~7899, 사용자 B는 7900~7909로 정해두는 방식입니다.
Docker 컨테이너 환경: Clash를 컨테이너에서 실행 중이라면 포트 충돌이 호스트의 포트 매핑 계층에서 발생할 수도 있습니다. 이때는 컨테이너 내부의 mixed-port가 아니라 호스트에서 docker ps로 확인되는 포트 매핑 설정을 살펴봐야 합니다.

자주 묻는 질문

포트를 바꿨는데도 브라우저에서 프록시가 여전히 안 잡히나요? 대부분은 시스템 프록시 설정이나 브라우저 확장의 포트 번호가 함께 바뀌지 않은 경우입니다. 위쪽 「시스템 프록시 설정 동기화」 항목을 다시 하나씩 확인해 보세요.

컴퓨터를 재부팅할 때마다 포트 충돌이 발생하는 이유는? Clash 서비스가 부팅 시 자동 실행되도록 설정된 상태에서 습관적으로 아이콘을 더블클릭해 클라이언트를 한 번 더 실행하고 있는지 확인해 보세요. 두 인스턴스가 같은 포트를 놓고 순서대로 경합하는 것이며, 실행 방식을 하나로 통일하면 해결됩니다.

점유 프로세스를 종료했는데도 여전히 실행이 안 되나요? ss -tulnp | grep 포트번호로 포트가 정말로 해제되었는지 다시 확인해 보세요. 일부 프로세스는 종료 후에도 잠시 TIME_WAIT 상태로 남아 있을 수 있으니, 몇 초 기다리거나 다른 포트로 테스트해 보면 의심을 해소할 수 있습니다.