로그에서 먼저 확인할 항목: 어떤 주소의 리슨에 실패했는지
Clash 클라이언트에서 ‘포트가 사용 중’이라는 오류가 표시되면, 보통 커널이 지정된 주소에서 리슨을 시작하지 못했다는 뜻입니다. 가장 흔한 원인은 다른 프록시 클라이언트가 백그라운드에서 실행 중이거나, 같은 클라이언트의 서비스 프로세스와 수동으로 실행한 커널이 중복 실행되는 경우입니다. 재설치하거나 이름에 Clash가 들어간 프로세스를 모두 종료하지 마세요. 실패한 포트와 해당 포트를 점유한 프로세스를 찾으면 조치 범위를 좁힐 수 있습니다.
클라이언트 로그에서 bind, listen, address already in use 등의 키워드를 찾아보세요. Windows에서는 “일반적으로 각 소켓 주소는 한 번만 사용할 수 있습니다”라는 메시지가 표시되기도 합니다. 아래는 문제를 파악하기 위한 로그 예시이며, 구체적인 접두사는 커널 버전에 따라 다를 수 있습니다.
listen tcp 127.0.0.1:7890: bind: address already in use이 메시지는 원격 노드 서버의 포트가 아니라 로컬 루프백 주소의 TCP 7890을 가리킵니다. 구독에 포함된 노드 포트를 바꿔도 로컬 리슨 충돌은 해결되지 않습니다. 로그에 permission denied 또는 “액세스 권한이 허용되지 않습니다”라고 표시되면 시스템 예약 포트, 권한, 보안 정책도 확인해야 합니다. 프로세스가 포트를 점유했다고 단정할 수는 없습니다.
| 설정 항목 | 용도 | 확인할 사항 |
|---|---|---|
mixed-port | 하나의 진입점에서 HTTP 및 SOCKS 프록시 요청을 모두 수신 | 일반적인 예시는 7890이며, 실제 설정을 기준으로 확인 |
port / socks-port | HTTP와 SOCKS 프록시 진입점을 각각 제공 | 혼합 진입점과 같은 주소 및 포트를 중복 지정했는지 확인 |
external-controller | 클라이언트 UI나 패널에서 사용하는 제어 API 제공 | 일반적인 예시는 127.0.0.1:9090이며, 인터넷 연결용 프록시 포트가 아님 |
dns.listen | DNS 쿼리 수신 | 53번 포트 또는 사용자 지정 DNS 포트에서 충돌하면 DNS 서비스를 별도로 확인 |
포트 충돌 여부는 리슨 주소와 전송 프로토콜에도 영향을 받습니다. 0.0.0.0:7890은 모든 IPv4 인터페이스에서 리슨한다는 뜻이므로 127.0.0.1:7890과 충돌할 수 있습니다. IPv6 와일드카드 주소가 IPv4까지 함께 처리하는지는 운영체제와 소켓 설정에 따라 달라집니다. TCP와 UDP는 포트 번호가 같아도 서로 다른 리슨 리소스이므로 로그에 표시된 프로토콜에 맞춰 확인하세요.
Windows: PID로 7890 포트를 점유한 프로그램 찾기
먼저 리슨 항목을 찾고, 다음으로 프로세스 이름 확인
PowerShell에서 아래 명령을 실행하세요. 첫 번째 명령은 TCP 7890 리슨 항목만 필터링하고, 두 번째 명령은 프로그램 경로를 추가로 확인합니다. 조회 결과 예시의 PID가 6248이라면 두 번째 명령에 해당 숫자를 입력하세요. 실제로는 현재 PC에서 조회된 PID를 사용해야 합니다.
Get-NetTCPConnection -LocalPort 7890 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-Process -Id 6248 | Select-Object Id, ProcessName, Path명령 프롬프트를 주로 사용한다면 Windows 기본 도구인 netstat과 tasklist를 이용해도 됩니다.
netstat -ano -p tcp | findstr ":7890"
tasklist /FI "PID eq 6248"findstr는 텍스트를 필터링하므로 원격 포트나 78900 같은 숫자까지 검색 결과에 포함될 수 있습니다. “로컬 주소” 열이 실제로 :7890으로 끝나는지, 상태가 LISTENING인지 다시 확인하세요. TIME_WAIT만 표시된 항목은 프로그램이 계속 리슨 중이라는 증거가 아닙니다. 연결 기록을 모두 충돌 원인으로 보지 마세요.
- 다른 프록시 클라이언트가 포트를 점유 중이라면 트레이 메뉴에서 정상적으로 종료한 뒤 포트를 다시 조회하세요.
- 현재 클라이언트의 커널이 점유 중이라면 서비스 모드가 켜져 있는지, 커널을 수동으로 한 번 더 실행했는지 확인하세요.
- 프로세스를 종료한 직후 새 PID로 다시 나타난다면 “작업 관리자” → “서비스”를 열거나
services.msc를 실행해 해당 프로세스를 재시작하는 백그라운드 서비스가 있는지 확인하세요.
리슨 항목이 없는데도 바인딩 실패 오류가 표시되는 경우
오류가 7890이 아니라 9090이나 다른 주소를 가리키는 것은 아닌지 먼저 확인하세요. Windows 로그에서 액세스 권한 문제가 확인되면 TCP 제외 포트 범위를 조회할 수 있습니다.
netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcpHyper-V, 컨테이너 및 관련 네트워크 구성 요소에서 포트를 예약할 수 있습니다. 대상 포트가 제외 범위에 포함된다면 출처가 불분명한 시스템 예약을 삭제하기보다 사용 가능한 포트로 바꾸는 편이 안전합니다. 클라이언트를 관리자 권한으로 실행해도 이런 제한이 반드시 해제되는 것은 아닙니다.
macOS와 Linux: 데스크톱 클라이언트와 백그라운드 서비스 구분하기
macOS에서 lsof 사용
“응용 프로그램” → “유틸리티” → “터미널”을 열고 TCP 7890의 리슨 프로세스를 조회하세요. -nP 옵션은 주소와 포트를 숫자로 표시해 이름 조회로 인한 혼란을 줄입니다. 권한이 부족해 결과가 일부만 보이면 sudo를 붙여 다시 조회하세요.
lsof -nP -iTCP:7890 -sTCP:LISTEN
ps -p 6248 -o pid,ppid,command출력에서 COMMAND와 PID를 확인한 다음 두 번째 명령으로 전체 실행 명령을 살펴보세요. 일부 클라이언트는 창을 닫아도 메뉴 막대에서 계속 실행되므로 메뉴 막대에서 종료해야 합니다. 로그인할 때 자동으로 실행되는 프로그램이라면 “시스템 설정” → “일반” → “로그인 항목 및 확장 프로그램”에서 확인하세요. macOS 버전에 따라 마지막 메뉴 이름은 조금 다를 수 있습니다.
Linux에서 ss 사용
Linux에서는 ss로 리슨 주소와 프로세스 정보를 함께 확인할 수 있습니다. 아래 명령은 TCP와 UDP를 각각 조회합니다. 로그나 사용 중인 기능에서 UDP가 확인된 경우에만 두 번째 명령을 실행하세요.
sudo ss -ltnp 'sport = :7890'
sudo ss -lunp 'sport = :7890'
ps -p 6248 -o pid,ppid,args프로세스가 systemd에서 관리된다면 프로세스만 종료해도 자동으로 다시 시작될 수 있습니다. 먼저 systemctl status 6248을 실행해 PID로 연결된 시스템 서비스를 찾아보세요. 사용자 서비스라면 systemctl --user도 확인하세요. 실제 유닛 이름을 확인한 뒤 해당 서비스에 맞는 stop 명령으로 중지하세요. 설치 방식에 따라 서비스 이름이 같다고 가정하면 안 됩니다.
Docker나 기타 컨테이너 환경에서는 호스트 포트 매핑도 확인해야 합니다. 컨테이너 내부의 7890 리슨 설정과 호스트에 공개된 7890 포트는 별개입니다. 호스트에서 충돌이 발생했다면 컨테이너 내부 설정만 바꿔도 호스트의 포트 점유 상태는 달라지지 않을 수 있습니다.
mixed-port 변경: 구독 파일이 아닌 실제 실행 설정 수정
포트를 점유한 프로그램을 계속 사용해야 한다면 Clash의 프록시 진입 포트를 바꿀 수 있습니다. 여기서는 7890을 7893으로 바꾸는 예를 듭니다. 7893은 예시일 뿐이며 PC에서 사용 가능하다고 보장되지 않으므로, 변경 전에 같은 명령으로 포트 사용 여부를 확인하세요.
클라이언트가 실제로 사용하는 설정 파일부터 확인
그래픽 클라이언트는 보통 구독 원문, 오버라이드 설정, 클라이언트 포트 설정을 조합해 실행 설정을 만듭니다. 다운로드한 YAML만 수정하면 구독 업데이트 시 덮어써지거나 커널에 반영되지 않을 수 있습니다. 클라이언트마다 메뉴 이름이 다르므로 “포트”, “혼합 포트” 또는 “Mixed Port”를 찾아보세요. 클라이언트가 지원하는 영구 설정이나 오버라이드 기능을 우선 사용하는 것이 좋습니다.
- 그래픽 클라이언트: 현재 포트 값을 기록하고 설정에서 혼합 포트를 변경하세요. 적용한 뒤 커널을 재시작하고, 시작 로그에서 최종 리슨 주소를 확인하세요.
- 커널 직접 실행: 실행 명령의
-f설정 파일 인수와-d작업 디렉터리를 확인한 다음 실제로 불러오는 파일을 수정하세요. - 서비스 또는 컨테이너: 서비스 시작 인수, 마운트 경로, 포트 매핑을 확인해 이름만 같은 다른 설정 파일을 잘못 수정하지 않도록 하세요.
아래는 mihomo에 사용할 수 있는 최상위 설정 예시이며, 완전한 구독 설정 파일이 아닙니다. 기존 설정에 병합하고 파일 전체를 대체하지 마세요. 같은 이름의 키가 이미 있다면 값을 수정하고 중복 키를 추가하지 마세요.
mixed-port: 7893
allow-lan: false
bind-address: 127.0.0.1mixed-port는 HTTP와 SOCKS 요청을 함께 받지만, 같은 주소에 독립된 port 또는 socks-port를 중복 바인딩할 수 있다는 뜻은 아닙니다. 기존에 별도 진입점이 있다면 함께 확인하고 해당 포트도 7893으로 설정하지 않도록 주의하세요. 리슨 주소는 클라이언트의 설정 생성 방식에 따라 달라질 수 있으므로 최종 상태는 시스템에서 조회한 결과를 기준으로 판단하세요.
mihomo 설정을 직접 관리한다면 먼저 문법과 설정을 검사할 수 있습니다. 아래 명령은 현재 터미널 디렉터리에 실제 config.yaml 파일이 있다고 가정합니다.
mihomo -t -f ./config.yaml검사를 통과해도 포트를 반드시 바인딩할 수 있는 것은 아닙니다. 설정 검사와 실행 중 리슨 시작은 별개의 과정입니다. 설정을 적용한 뒤에도 로그와 포트 상태를 확인하세요. 그래픽 클라이언트는 리슨 포트 변경을 완전히 적용하려면 “커널 재시작”이 필요할 수 있습니다. 입력란에 값이 저장됐는지만 확인해서는 안 됩니다.
컨트롤 포트 9090 충돌: 프록시 포트와 혼동하지 마세요
external-controller는 컨트롤 API가 리슨하는 주소로, 클라이언트 UI에서 연결 정보를 읽거나 정책을 전환하고 실행 상태를 변경할 때 사용합니다. HTTP 웹 프록시가 아닙니다. 127.0.0.1:9090에서 충돌이 발생했다면 mixed-port만 바꿔서는 해결되지 않습니다. 반대로 브라우저 프록시를 9090으로 설정해도 웹 요청이 정상적으로 전달되지 않습니다.
직접 설정과 컨트롤 패널을 관리하는 경우에는 사용 가능한지 확인한 후 컨트롤 주소를 아래 예시처럼 변경할 수 있습니다.
external-controller: 127.0.0.1:9093변경 후에는 외부 패널의 컨트롤 주소도 업데이트하고 기존 secret 인증 설정을 유지하세요. 컨트롤 포트를 그래픽 클라이언트가 관리한다면 클라이언트 설정에서 변경하는 것이 우선입니다. 커널 설정만 오버라이드하고 UI 연결 매개변수를 그대로 두면 “커널은 트래픽을 전달하지만 UI에는 연결되지 않은 것으로 표시되는” 문제가 생길 수 있습니다.
프록시 포트를 바꾼 뒤 함께 수정해야 하는 설정
포트를 7890에서 7893으로 바꾸면 여전히 이전 주소를 사용하는 앱의 연결이 실패합니다. 클라이언트에 “커널 실행 중”이라고 표시되어도 커널이 시작됐다는 뜻일 뿐, 브라우저와 터미널, 기타 도구가 새 주소를 사용한다는 보장은 없습니다.
| 사용 위치 | 함께 수정할 항목 |
|---|---|
| 시스템 프록시 | 클라이언트의 시스템 프록시를 다시 적용하고 주소가 127.0.0.1:7893으로 바뀌었는지 확인 |
| 브라우저 프록시 확장 프로그램 | 수동 설정된 HTTP 또는 SOCKS 포트를 7893으로 변경하고, 시스템 설정을 따르는 모드도 별도로 확인 |
| 터미널 환경 변수 | HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 및 실제로 사용하는 소문자 변수도 업데이트 |
| 개발 도구 | Git, 패키지 관리자, IDE에 각각 저장된 프록시 주소 확인 |
| 로컬 네트워크 기기 | 기존에 로컬 네트워크 연결을 허용했다면 포트도 변경하고 방화벽을 확인하세요. 127.0.0.1은 다른 기기에서 접속할 주소가 아닙니다. |
Windows 11에서는 “설정” → “네트워크 및 인터넷” → “프록시”에서 수동 프록시를 확인할 수 있습니다. macOS에서는 “시스템 설정” → “네트워크” → 현재 네트워크 연결의 “세부사항” → “프록시”에서 확인하세요. 클라이언트에서 시스템 프록시를 다시 설정한 뒤에도 시스템 설정 화면에서 실제 값을 확인하는 것이 좋습니다. 다른 도구가 값을 다시 덮어쓸 수 있습니다.
현재 터미널 세션에만 적용하는 예시
# macOS / Linux: 현재 셸
export http_proxy=http://127.0.0.1:7893
export https_proxy=http://127.0.0.1:7893
# PowerShell: 현재 세션
$env:HTTP_PROXY = "http://127.0.0.1:7893"
$env:HTTPS_PROXY = "http://127.0.0.1:7893"HTTPS 프록시 변수에도 http://를 사용하는 것은 로컬 HTTP 프록시의 CONNECT 기능으로 HTTPS 사이트에 접속한다는 뜻입니다. 대상 사이트가 HTTP로 전환되는 것은 아닙니다. 기존에 SOCKS를 사용했다면 이를 지원하는 앱을 socks5h://127.0.0.1:7893으로 설정할 수 있습니다. 앱이 해당 환경 변수를 읽는지는 각각 확인해야 합니다.
TUN 모드는 가상 네트워크 인터페이스로 트래픽을 처리하므로 앱이 혼합 포트에 직접 연결하는 방식과 경로가 다릅니다. 따라서 TUN 모드에서 앱이 인터넷에 접속된다고 해서 기존 7890 프록시 설정이 해결된 것은 아닙니다. 프록시를 수동 설정한 도구는 여전히 이전 포트로 접속할 수 있습니다.
3단계로 확인: 리슨 상태, 프록시 요청, 앱의 실제 연결
- 리슨 프로세스 확인: 7893을 다시 조회해 예상한 커널의 리슨 항목이 있는지, 새로운 바인딩 실패 로그가 없는지 확인하세요.
- 프록시 프로토콜 확인: 시스템 프록시 설정의 업데이트 여부에 의존하지 말고 새 포트를 명시해 요청을 한 번 보내세요.
- 주요 앱 확인: 브라우저나 개발 도구를 열고 클라이언트의 연결 목록에서 해당 요청과 규칙 적용 여부를 확인하세요.
# macOS / Linux
curl -I --connect-timeout 5 --max-time 15 --noproxy "" --proxy http://127.0.0.1:7893 https://example.com
# Windows PowerShell: curl.exe 직접 실행
curl.exe -I --connect-timeout 5 --max-time 15 --noproxy "" --proxy http://127.0.0.1:7893 https://example.com위 테스트는 연결 시간 제한을 5초, 전체 제한 시간을 15초로 설정하고 해당 요청의 프록시 우회 목록을 비웁니다. 127.0.0.1:7893에 연결할 수 없다는 메시지가 나오면 리슨이 정상적으로 시작됐는지 먼저 확인하세요. 프록시 연결은 성공했지만 이후 TLS 오류, 업스트림 시간 초과, 정책 오류가 발생한다면 로컬 포트를 계속 바꾸기보다 노드, DNS, 규칙을 살펴봐야 합니다.
대상 서버에서 HTTP 응답을 받으면 요청 경로가 작동하는지 확인하는 데 도움이 됩니다. 하지만 노드 대역폭이나 모든 웹사이트와 앱이 정상이라는 뜻은 아닙니다. 일부 사이트는 HEAD 요청을 거부할 수 있으므로 응답 내용을 함께 확인하세요. 테스트할 때는 한 번에 변수 하나만 바꾸고 변경 전 포트를 기록해 두면 규칙, DNS, TUN을 한꺼번에 조정하는 것보다 원인을 찾기 쉽습니다.
자주 묻는 질문: 재부팅, 클라이언트 중복 실행, 반복되는 포트 충돌
PC를 재부팅한 뒤 해결됐는데도 추가로 확인해야 하나요?
한 번만 발생했다면 우선 지켜볼 수 있습니다. 로그인할 때마다 다시 발생한다면 자동 시작 클라이언트와 백그라운드 서비스를 확인하세요. 재부팅으로 시작 순서만 일시적으로 바뀌었을 뿐, 두 프로그램이 같은 포트를 놓고 경쟁하는 원인은 남아 있을 수 있습니다. 계속 재부팅하기보다 충돌 당시의 PID, 프로그램 경로, 로그를 기록해 두는 편이 도움이 됩니다.
Clash 클라이언트 두 개를 동시에 실행해도 되나요?
프록시 포트와 컨트롤 포트는 각각 다르게 지정할 수 있지만 시스템 프록시, TUN 라우팅, DNS 처리는 서로 영향을 줄 수 있습니다. 일반적으로 트래픽을 처리하는 클라이언트 하나만 유지하는 편이 관리하기 쉽습니다. 7890만 바꿔서는 두 클라이언트의 모든 시스템 설정이 자동으로 분리되지 않습니다.
포트를 바꿨는데 구독을 업데이트하자 7890으로 돌아왔어요. 어떻게 해야 하나요?
대개 다시 생성되는 설정 계층에서 값을 바꾼 경우입니다. 클라이언트의 포트 설정이나 영구 오버라이드 기능을 확인하고, 구독 업데이트 후 최종 실행 설정과 리슨 기록을 살펴보세요. 구독 편집기에 표시되는 값만으로 커널의 현재 설정을 판단하지 마세요.
이 문제는 일정한 순서로 해결하면 됩니다. 먼저 로그에서 주소와 프로토콜을 확인하고, 리슨 프로세스를 찾은 다음 중복 인스턴스를 종료할지 포트를 바꿀지 결정하세요. 마지막으로 앱 설정을 동기화하고 연결을 테스트합니다. 클라이언트 기본 설정 가져오기와 트래픽 처리 방법은 Clash 사용 가이드에서, 설정 항목은 프로토콜 및 설정 참고서에서 확인할 수 있습니다.