· 문제 해결 · 읽는 시간 약 12분
Clash 실행 시 포트 충돌 해결: 점유 프로세스 확인 및 mixed-port 변경
Windows, macOS, Linux에서 netstat·lsof·ss로 7890 등 포트를 사용 중인 프로세스를 찾고, 포트 변경 후 시스템 프록시와 브라우저 설정을 함께 바꾸는 방법을 안내합니다.
먼저 로그 확인: 포트·주소·오류 유형 파악
Clash 또는 Clash Meta(현재 mihomo)를 실행할 때 포트 바인딩에 실패하면, 우선 어떤 리스너에서 문제가 발생했는지 확인하세요. 7890은 로컬 프록시 포트로 자주 설정되지만 필수값은 아니며, 원격 노드의 서버 포트도 아닙니다. 로컬 포트를 바꾸더라도 일반적으로 구독에 포함된 노드 주소, 비밀번호, 프록시 규칙은 수정할 필요가 없습니다.
클라이언트의 로그 화면에서 listen, bind, address already in use 등의 키워드를 찾아 전체 로컬 주소와 포트를 확인하세요. 예를 들어 아래 로그는 TCP IPv4 루프백 주소의 바인딩에 실패한 경우입니다.
listen tcp 127.0.0.1:7890: bind: address already in useWindows에서는 Only one usage of each socket address라는 메시지가 표시될 수도 있습니다. permission denied 또는 An attempt was made to access a socket in a way forbidden by its access permissions가 표시된다면 권한, 보안 정책 또는 시스템 예약 포트도 확인해야 합니다. 다른 Clash 프로세스가 포트를 사용 중이라고 단정할 수는 없습니다.
| 설정 항목 | 용도 | 바인딩 실패 시 영향 |
|---|---|---|
mixed-port | HTTP와 SOCKS5 공용 포트 | 해당 포트를 사용하는 앱이 프록시에 연결되지 않음 |
port / socks-port | HTTP / SOCKS 전용 포트 | 해당 프로토콜의 프록시 포트를 사용할 수 없음 |
external-controller | 컨트롤 API(일반적인 예: 9090) | 클라이언트 패널이 코어에 연결되지 않을 수 있음 |
dns.listen | 내장 DNS 리스너 주소 | 관련 DNS 조회가 실패할 수 있음 |
점검할 때는 숫자만 보지 말고 '프로토콜 + 로컬 주소 + 포트'를 함께 확인하세요.
127.0.0.1:7890,0.0.0.0:7890,[::]:7890은 수신 범위가 서로 다릅니다. 와일드카드 주소나 듀얼 스택 리스너는 더 구체적인 주소의 리스너와 충돌할 수 있습니다.
Windows: netstat와 PowerShell로 프로세스 찾기
리스닝 정보 조회 후 PID 확인
PowerShell을 열고 아래 명령을 실행하세요. 첫 번째 명령은 빠르게 확인할 때, 두 번째 명령은 로컬 TCP 포트를 정확히 필터링할 때 사용합니다. 다른 프로세스의 자세한 정보를 보려면 터미널을 관리자 권한으로 실행해야 할 수 있습니다.
netstat -ano -p tcp | findstr ":7890"
Get-NetTCPConnection -LocalPort 7890 -State Listen -ErrorAction SilentlyContinue |
Select-Object LocalAddress, LocalPort, State, OwningProcessnetstat 출력의 마지막 열에는 프로세스 ID인 PID가 표시됩니다. findstr는 원격 주소나 78900 같은 문자열도 찾을 수 있으므로, '로컬 주소' 열의 포트가 7890인지, 상태가 LISTENING인지 확인하세요. TIME_WAIT는 연결 상태를 나타내므로 이를 근거로 프로세스를 임의로 종료하지 마세요.
조회 결과에서 PID가 4321이라고 가정하고 프로세스 이름, 실행 파일 경로, 명령줄을 확인해 보겠습니다. 4321은 예시일 뿐이므로 실행 전 실제 조회 결과로 바꿔야 합니다.
tasklist /FI "PID eq 4321"
Get-CimInstance Win32_Process -Filter "ProcessId = 4321" |
Select-Object Name, ExecutablePath, CommandLine다른 프록시 클라이언트가 실행한 mihomo라면 해당 클라이언트의 트레이 메뉴에서 종료하거나 백그라운드 서비스를 중지하는 것이 우선입니다. 창만 닫아도 코어가 계속 실행될 수 있습니다. PID가 시스템 서비스나 출처를 모르는 프로그램에 속한다면 경로와 용도를 먼저 확인하고 강제 종료하지 마세요.
리스너가 조회되지 않는데도 바인딩 오류가 발생하는 경우
- 로그에 7890이 아니라 7891, 9090 또는 다른 포트가 표시되는지 확인하세요.
- 오류 발생 후 클라이언트가 코어를 반복해서 다시 시작하는지 확인하세요. 조회 시점이 프로세스가 종료되는 순간과 겹쳤을 수 있습니다.
- 로그에 UDP라고 명시되어 있다면
Get-NetUDPEndpoint -LocalPort 7890으로 확인하세요. TCP만 조회해서는 안 됩니다. - 접근 권한 오류라면 아래 명령으로 IPv4 TCP 제외 포트 범위를 확인할 수 있습니다. 포트가 해당 범위에 포함된다면 시스템 예약 범위를 삭제하기보다 사용 가능한 다른 포트를 선택하는 편이 안전합니다.
netsh interface ipv4 show excludedportrange protocol=tcpmacOS: lsof로 리스너와 백그라운드 서비스 확인
‘터미널’에서 아래 명령을 실행하세요. -nP는 주소와 포트를 이름으로 변환하지 않으며, -sTCP:LISTEN은 리스닝 소켓만 표시해 로컬 서비스와 일반적인 외부 연결을 구분하기 쉽게 합니다.
sudo lsof -nP -iTCP:7890 -sTCP:LISTEN출력의 COMMAND는 프로세스 이름, PID는 프로세스 ID, NAME은 리스닝 주소를 나타냅니다. *:7890이 표시되면 특정 로컬 인터페이스 하나에만 바인딩된 것은 아닙니다. 다음으로 전체 명령줄을 조회해 어떤 클라이언트나 시작 항목이 코어를 실행했는지 확인하세요.
ps -p 4321 -o pid,ppid,user,command오래된 클라이언트의 잔여 프로세스라면 먼저 해당 앱을 정상 종료하세요. 그래도 멈추지 않으면 ‘활성 상태 보기’에서 확인된 프로세스를 선택해 종료할 수 있습니다. 명령줄에서 실제 PID에 kill -TERM 4321을 보내면 프로세스가 정상적으로 정리될 기회를 줍니다. kill -9부터 실행하지 마세요.
종료 직후 새로운 PID가 나타난다면 자동 실행 설정이 있을 가능성이 큽니다. macOS 13 및 이후 버전에서는 ‘시스템 설정’ → ‘일반’ → ‘로그인 항목’(일부 버전에서는 ‘로그인 항목 및 확장 프로그램’)에서 백그라운드 항목을 확인하세요. Homebrew로 설치한 서비스라면 brew services list도 확인해야 합니다. 자식 프로세스를 계속 종료하기보다 해당 서비스 설정에서 비활성화하세요.
Ubuntu 및 Linux: ss로 systemd 서비스와 중복 코어 확인
Ubuntu에서는 ss를 사용해 TCP 리스닝 상태를 확인하세요. sudo를 붙이면 다른 사용자의 프로세스 PID와 프로그램 이름도 확인할 수 있는 경우가 많습니다. 권한 없이 실행하면 소켓만 표시되고 프로세스 정보는 보이지 않을 수 있습니다.
sudo ss -ltnp 'sport = :7890'
sudo ss -lunp 'sport = :7890'첫 번째 명령은 TCP, 두 번째 명령은 UDP를 확인합니다. TCP 출력에서 LISTEN은 리스닝 상태를 뜻하며, UDP에는 보통 UNCONN이 표시됩니다. 두 프로토콜의 상태 이름은 다릅니다. lsof가 설치된 시스템에서는 macOS와 같은 sudo lsof -nP -iTCP:7890 -sTCP:LISTEN 명령을 사용할 수도 있습니다.
데스크톱 클라이언트와 systemd가 동시에 실행되는 경우
서버 배포 때 설정한 systemd 서비스가 7890을 점유한 상태에서 데스크톱 클라이언트가 코어를 하나 더 실행하려는 경우가 흔합니다. PID가 4321이라면 명령줄과 소속 서비스를 먼저 확인한 후 어느 쪽을 사용할지 결정하세요.
ps -p 4321 -o pid,ppid,user,args
sudo systemctl status 4321systemctl status로 PID에 해당하는 유닛을 확인할 수 있습니다. 해당 프로세스가 직접 만든 mihomo.service 서비스에 속하고 데스크톱 클라이언트를 사용하려는 경우, 서비스를 중지하세요.
sudo systemctl stop mihomo.service
sudo ss -ltnp 'sport = :7890'서비스 이름은 반드시 해당 시스템에서 조회한 결과를 기준으로 하세요. 이후에도 부팅 시 자동 시작할 필요가 없다면 sudo systemctl disable mihomo.service를 실행하세요. disable만 실행해서는 현재 프로세스가 중지되지 않습니다. 사용자 단위 서비스에는 systemctl --user를 사용하세요. 자동 재시작이 설정된 서비스를 코어 프로세스만 종료하면 다시 실행될 수 있습니다.
리스너가 컨테이너 관련 프로세스로 표시된다면 컨테이너의 호스트 포트 매핑도 확인하세요. 프록시 포트 하나를 비우려고 컨테이너 실행 환경 전체를 중지하지 마세요. 해당 컨테이너의 포트 매핑을 변경하거나 로컬 프록시 포트를 바꾸면 됩니다.
mixed-port 변경: UI 설정과 실제 적용되는 설정 구분
점유 프로세스를 유지해야 한다면 Clash의 로컬 포트를 7890에서 17890으로 변경할 수 있습니다. 17890은 이 글의 예시이며 기기에서 사용 가능하다는 보장은 없습니다. 변경 전에 앞서 안내한 명령으로 새 포트의 사용 여부를 확인하세요.
그래픽 클라이언트에서는 설정 메뉴에서 변경
클라이언트마다 메뉴 이름은 다르지만, 보통 ‘설정’의 ‘포트’, ‘프록시 포트’ 또는 ‘코어 설정’에서 변경할 수 있습니다. 현재 표시되는 항목이 컨트롤러 포트가 아니라 혼합 포트인지 먼저 확인하세요. 클라이언트가 생성된 설정 파일에 값을 저장해 구독 파일의 같은 항목을 덮어쓸 수 있으므로, 다운로드한 구독 YAML만 수정하지 마세요.
mihomo를 단독 실행하는 경우 최상위 필드 수정
설정 파일을 직접 읽는 코어라면 실행 옵션 -f로 지정한 파일을 편집하세요. 작업 디렉터리를 -d로 지정했다면 해당 디렉터리에서 실제 설정 파일을 확인합니다. 아래는 포트 설정을 바꾸는 예시이며 노드와 규칙을 포함한 전체 설정 파일은 아닙니다.
mixed-port: 17890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: infomixed-port는 YAML 최상위에 작성해야 합니다. 앞에general:을 붙이거나dns:아래에 들여쓰지 마세요.- 기존 설정에
port,socks-port등의 전용 포트가 있다면 충돌하는 포트가 남아 있지 않은지 각각 확인하세요. 혼합 포트만 바꿔도 다른 포트가 자동으로 변경되지는 않습니다. - 최상위 포트를 변경한 뒤 클라이언트 안내에 따라 설정을 다시 적용하거나 코어를 재시작하세요. 프록시 노드만 전환해서는 리스너 설정이 갱신되지 않을 수 있습니다.
- 구독을 업데이트하면 직접 수정한 내용이 덮어써질 수 있습니다. 설정 오버라이드나 병합 기능을 지원하는 클라이언트에서는 유지 설정 또는 오버라이드 항목에 로컬 포트를 저장하세요.
단독 배포 환경에서는 mihomo -t -f /etc/mihomo/config.yaml로 설정 파일을 파싱할 수 있는지 확인하세요. 경로는 실제 배포 환경에 맞게 바꾸면 됩니다. 설정 테스트를 통과해도 실행 시 포트를 사용할 수 있다는 뜻은 아니므로, 시작 로그와 리스닝 상태를 최종 확인하세요.
시스템 프록시·브라우저·터미널 포트 동기화
코어 포트를 17890으로 바꿨는데도 앱이 127.0.0.1:7890에 연결하면, 증상은 보통 '코어 시작 실패'에서 '프록시 서버가 연결을 거부함'으로 바뀝니다. 클라이언트 화면뿐 아니라 이전 포트를 직접 입력한 모든 설정도 함께 변경해야 합니다.
| 사용 방식 | 확인할 설정 위치 |
|---|---|
| Windows 시스템 프록시 | ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’ → ‘수동 프록시 설정’ |
| macOS 시스템 프록시 | ‘시스템 설정’ → ‘네트워크’ → 현재 연결 → ‘세부사항’ → ‘프록시’ |
| Ubuntu GNOME | ‘설정’ → ‘네트워크’ → ‘네트워크 프록시’에서 수동 프록시 포트 확인 |
| Firefox 자체 프록시 설정 | ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’ |
| 브라우저 프록시 확장 프로그램 | 현재 프로필에 설정된 HTTP / SOCKS5 서버 주소와 포트 |
| 터미널 및 개발 도구 | 프록시 환경 변수, Git 설정, IDE 및 패키지 관리자의 개별 프록시 설정 |
클라이언트가 시스템 프록시를 관리한다면 새 포트의 리스닝이 확인된 후 ‘시스템 프록시’를 껐다가 다시 켜서 주소를 갱신하세요. Firefox에서 ‘시스템 프록시 설정 사용’을 선택하면 보통 포트를 따로 입력할 필요가 없습니다. 수동 프록시를 선택했다면 직접 변경해야 합니다.
Linux 또는 macOS의 현재 셸에서는 필요에 따라 환경 변수를 변경할 수 있습니다. https_proxy에 http://를 사용하는 것은 문제가 아닙니다. 앱이 HTTP 프록시를 통해 HTTPS 터널을 만든다는 뜻이지, 대상 사이트의 연결을 HTTP로 낮춘다는 뜻은 아닙니다.
export http_proxy=http://127.0.0.1:17890
export https_proxy=http://127.0.0.1:17890
export all_proxy=socks5h://127.0.0.1:17890이 명령은 현재 셸과 이후 실행되는 하위 프로세스에만 적용되며, 이미 실행 중인 앱에는 자동 반영되지 않습니다. 셸 시작 파일에 이전 값이 남아 있는지도 확인하세요. Git 설정은 먼저 git config --show-origin --get-regexp '.*proxy.*'로 출처를 확인한 뒤 실제 적용 범위에 맞게 수정하세요. 전역 설정만 바꾸고 저장소별 설정을 놓치지 않도록 주의해야 합니다.
TUN 모드는 가상 네트워크 인터페이스로 트래픽을 처리하며, 명시적으로 사용하는 HTTP/SOCKS 포트와는 작동 방식이 다릅니다. TUN을 켜도 이미 점유된 포트가 비워지지는 않습니다. 설정에서 여전히 7890 수신을 요구한다면 해당 리스너에서 오류가 발생할 수 있습니다. TUN 모드에서 일부 앱이 작동하더라도 이전 시스템 프록시 설정을 그대로 두지 마세요.
복구 확인: 리스너·요청·재시작 후 설정 유지
- 리스닝 프로세스 확인. 운영체제에 맞는 명령으로 17890을 조회해 의도한 코어가 리스닝 중인지, 루프백 주소 또는 와일드카드 주소에 바인딩되어 있는지 확인하세요.
- 프록시 요청을 직접 전송. 아래 명령으로 앱이 시스템 프록시 설정을 따르는지에 대한 변수를 배제하고 HTTP와 SOCKS5 포트를 각각 테스트하세요.
- 클라이언트 연결 로그 확인. 테스트 요청이 코어에 도달하는지 확인한 다음, 적용된 규칙과 트래픽 출구를 확인하세요. 로컬 포트에 연결된다고 해서 원격 노드까지 정상이라는 뜻은 아닙니다.
- 평소 사용하는 앱 확인. 브라우저나 터미널을 다시 열어 아직도 7890을 참조하는지 확인하세요.
- 재시작 및 구독 업데이트 확인. 클라이언트를 재시작한 뒤 포트를 다시 확인하고, 구독을 업데이트한 후 유지 설정이 덮어써지지 않았는지 살펴보세요.
curl --noproxy "" --proxy http://127.0.0.1:17890 --connect-timeout 5 --max-time 20 -I https://example.com/
curl --noproxy "" --proxy socks5h://127.0.0.1:17890 --connect-timeout 5 --max-time 20 -I https://example.com/Windows PowerShell에서는 위의 curl을 curl.exe로 명시하는 것이 좋습니다. 이전 PowerShell 버전에서는 같은 이름의 별칭 때문에 매개변수 동작이 달라질 수 있습니다. --noproxy ""는 프록시 우회 설정의 영향을 배제하기 위한 옵션입니다. 5초와 20초는 각각 연결 제한 시간과 전체 요청 제한 시간이며 속도 측정 결과가 아닙니다.
연결 거부가 반환되면 로컬 리스너와 포트를 계속 확인하세요. 프록시에는 연결됐지만 이후 요청이 시간 초과된다면 규칙, 노드, DNS, 대상 사이트 연결 상태를 점검해야 합니다. 오류에 표시된 포트가 컨트롤 API의 9090이라면 컨트롤러 주소와 클라이언트 연결 매개변수를 함께 수정해야 하며, mixed-port만 반복해서 바꿔서는 안 됩니다. '로그 확인 → 프로세스 조회 → 중복 서비스 처리 또는 포트 변경 → 앱 설정 동기화 → 검증' 순서로 진행하면 로컬 바인딩 문제와 이후 네트워크 문제를 구분할 수 있습니다.