Clash 포트가 사용 중일 때: 프로세스 확인과 수신 포트 변경

Clash를 시작하려면 로컬 시스템에 하나 이상의 수신 포트를 열어야 합니다. 브라우저, 운영체제 및 다른 애플리케이션은 이 포트로 프록시 요청을 보내고, Clash는 설정 파일의 규칙과 정책 그룹에 따라 트래픽을 처리합니다. 대상 포트를 다른 프로세스가 이미 사용 중이면 시스템은 두 번째 바인딩을 거부하며, 코어는 일반적으로 주소가 사용 중이거나 수신에 실패했거나 포트가 사용 중이라는 오류를 표시합니다.

일반적인 원인으로는 정상적으로 종료되지 않은 이전 Clash 프로세스, 동시에 실행된 두 클라이언트, 같은 포트를 사용하는 다른 프록시 도구, 여러 수신기에 동일한 포트를 지정한 설정, 로컬 개발 서비스와 충돌한 제어 인터페이스 또는 DNS 서비스 등이 있습니다. 해결할 때는 시작 버튼을 반복해서 누르기보다 먼저 어느 주소와 포트에서 충돌이 발생했는지 확인하고, 해당 프로세스를 찾은 뒤 점유한 프로세스를 종료할지 Clash 설정을 변경할지 결정해야 합니다.

1. 오류 문구로 포트 충돌 식별하기

클라이언트마다 코어 로그를 정리하는 방식은 다르지만, 기본 오류에는 대개 bind, listen, address already in use 또는 “포트가 사용 중”과 같은 키워드가 포함됩니다. 로그에서 가장 중요한 정보는 프로토콜, 수신 주소와 포트 번호입니다. 예를 들어 127.0.0.1:7890은 로컬 루프백 주소에서만 7890 포트를 수신한다는 뜻이고, 0.0.0.0:7890은 모든 IPv4 네트워크 인터페이스에서 해당 포트를 수신하려는 의미입니다.

listen tcp 127.0.0.1:7890: bind: address already in use
listen tcp 0.0.0.0:9090: bind: address already in use

첫 번째 줄은 보통 HTTP, SOCKS 또는 mixed 프록시 진입점에 해당하고, 두 번째 줄은 외부 제어 인터페이스일 가능성이 높습니다. 사용자가 기본값을 변경할 수 있으므로 포트 번호만으로 어떤 설정인지 단정할 수는 없습니다. 로그의 주변 내용과 현재 적용된 설정을 함께 확인해야 합니다.

로그에 바인딩 실패가 없고 TUN 장치 생성 실패, 권한 부족, 라우팅 설정 실패 또는 네트워크 인터페이스 없음이 표시된다면 프록시 포트 문제가 아닐 수 있습니다. 이 경우 7890과 같은 포트로 변경해도 문제가 해결되지 않는 경우가 많으므로 관리자 권한, 가상 네트워크 어댑터, TUN 드라이버와 시스템 라우팅을 확인해야 합니다.

2. Clash가 사용하는 수신 포트 확인하기

Clash와 mihomo 설정에는 여러 로컬 수신기가 존재할 수 있습니다. 실제 필드는 클라이언트 기능과 현재 설정에 따라 달라지지만, 가장 자주 사용하는 항목은 다음과 같습니다.

설정 항목	용도	충돌 시 영향
`mixed-port`	하나의 포트에서 HTTP와 SOCKS5 프록시 연결 수신	시스템 프록시와 수동 프록시가 동시에 작동하지 않을 수 있음
`port`	HTTP 프록시 수신 포트	HTTP 프록시를 사용하는 애플리케이션이 연결되지 않음
`socks-port`	SOCKS5 프록시 수신 포트	SOCKS5를 사용하는 애플리케이션이 연결되지 않음
`redir-port`	리디렉션 트래픽 수신, 특정 시스템 네트워크 구성에 주로 사용	투명 프록시 경로를 만들 수 없음
`tproxy-port`	TPROXY 트래픽 수신, Linux 라우팅 환경에서 자주 사용	투명 프록시 규칙이 트래픽을 코어로 전달하지 못함
`external-controller`	클라이언트 화면 또는 외부 패널에 제어 API 제공	화면에서 코어 상태를 읽거나 정책을 변경하지 못할 수 있음
`dns.listen`	로컬 DNS 서비스 제공	도메인 조회 요청이 Clash DNS 모듈로 전달되지 않음

mixed-port는 HTTP와 SOCKS5 요청을 동시에 처리할 수 있습니다. 설정이 mixed 모드라면 일반적으로 port나 socks-port를 같은 값으로 다시 지정할 필요가 없습니다. 동일한 주소에서 같은 전송 프로토콜과 포트 조합을 두 수신기가 함께 사용할 수는 없습니다.

또한 “구독 설정”과 “클라이언트 실행 설정”을 구분해야 합니다. 일부 데스크톱 클라이언트는 실행 중 화면의 포트, 제어 인터페이스와 TUN 옵션을 구독 내용에 병합해 최종 설정을 생성합니다. 이때 구독 파일을 직접 편집하면 구독 업데이트나 클라이언트 재시작 후 변경 사항이 덮어써질 수 있습니다. 먼저 클라이언트의 일반 설정, 포트 설정 또는 오버라이드 설정에서 변경하세요. 클라이언트가 YAML을 직접 읽는 것이 확인된 경우에만 해당 필드를 편집하는 것이 좋습니다.

3. Windows, macOS, Linux에서 점유 프로세스 찾기

Windows: PID와 프로세스 이름 조회

7890 포트를 예로 들면 명령 프롬프트에서 다음을 실행합니다.

netstat -ano | findstr :7890

결과의 LISTENING은 프로세스가 포트를 수신 중이라는 뜻이며, 마지막 열이 PID입니다. 이어서 해당 PID의 프로그램을 조회합니다.

tasklist /FI "PID eq 1234"

PowerShell에서는 구조화된 명령을 사용할 수도 있습니다.

Get-NetTCPConnection -LocalPort 7890 -State Listen
Get-Process -Id 1234

명령 실행 시 권한 부족이 표시되면 관리자 터미널에서 다시 조회하세요. 작업 관리자의 “세부 정보” 탭에서도 PID로 프로세스를 찾을 수 있습니다. 다른 Clash 클라이언트나 이전 코어를 발견했다면 먼저 해당 화면에서 정상 종료하고, 트레이 영역의 프로세스가 사라졌는지 확인한 뒤에만 프로세스 종료를 고려하세요.

macOS: lsof로 수신 프로그램 확인

sudo lsof -nP -iTCP:7890 -sTCP:LISTEN

출력에는 프로세스 이름, PID, 사용자와 수신 주소가 표시됩니다. DNS 서비스를 확인할 때는 UDP도 조회해야 합니다. 로컬 DNS 수신은 UDP와 TCP를 모두 사용할 수 있기 때문입니다.

sudo lsof -nP -iUDP:1053
sudo lsof -nP -iTCP:1053 -sTCP:LISTEN

Linux: ss 또는 lsof 사용

sudo ss -lntp 'sport = :7890'
sudo lsof -nP -iTCP:7890 -sTCP:LISTEN

ss의 -l은 수신 소켓만 표시하고, -n은 포트를 서비스 이름으로 변환하지 않으며, -t는 TCP를 조회하고, -p는 프로세스를 표시합니다. UDP 수신을 확인할 때는 다음을 사용할 수 있습니다.

sudo ss -lnup 'sport = :1053'

4. 점유 프로세스를 종료할까, Clash 포트를 변경할까

점유 프로세스를 찾은 뒤의 처리 방법은 해당 프로세스의 용도에 따라 달라집니다. 이전에 남은 Clash 코어라면 기존 클라이언트를 정상 종료하는 것이 가장 적절합니다. 두 클라이언트를 모두 사용해야 한다면 프록시 포트, 제어 포트와 DNS 수신 포트를 서로 다르게 지정해야 합니다. mixed-port만 변경하고 같은 external-controller를 유지하면 두 번째 코어가 여전히 시작되지 않을 수 있습니다.

포트를 장시간 실행되는 개발 서버, 컨테이너 매핑 또는 로컬 네트워크 서비스가 사용 중이라면 Clash 포트를 변경하는 편이 안정적입니다. 새 포트를 선택하기 전에 시스템 명령으로 해당 포트를 수신 중인 프로세스가 없는지 확인하세요. 포트 범위는 1부터 65535까지이며, HTTP, SOCKS, 제어 인터페이스와 DNS 서비스를 같은 주소와 포트에 중복 지정하지 않아야 합니다.

점유 프로세스를 종료했는데도 포트 조회에 수신 상태가 계속 표시된다면 다음과 같은 경우일 수 있습니다.

클라이언트 화면을 닫은 뒤에도 시스템 트레이에 남아 코어 프로세스가 종료되지 않음.
서비스 관리자, 시스템 서비스 또는 컨테이너 재시작 정책이 프로세스를 자동으로 다시 실행함.
여러 클라이언트가 설치되어 있고 그중 하나가 시작 시 자동 실행되도록 설정됨.
다른 네트워크 프로토콜을 조회함. 예를 들어 TCP만 확인했지만 충돌은 UDP DNS 수신에서 발생함.
IPv4와 IPv6 주소에서 동시에 수신하도록 설정되어 로그의 구체적인 주소를 함께 확인해야 함.

프로세스 강제 종료는 신원을 확인한 뒤 사용하는 방법이어야 합니다. Windows에서는 작업 관리자에서 작업을 종료할 수 있고, macOS와 Linux에서는 프로그램이 상태를 저장할 기회를 갖도록 먼저 일반 종료 신호를 보내는 것이 좋습니다. 프로세스가 계속 자동으로 나타난다면 PID를 반복해서 종료하기보다 시작 프로그램, 백그라운드 서비스 또는 컨테이너 재시작 설정을 해제하세요.

5. mixed-port, HTTP 및 SOCKS 수신 설정 변경

하나의 통합 프록시 진입점만 필요하다면 mixed-port를 유지하고 중복된 HTTP 및 SOCKS 독립 수신 항목을 제거할 수 있습니다. 다음 예시는 통합 진입점을 7893으로, 제어 인터페이스를 9091로 변경합니다.

mixed-port: 7893
external-controller: 127.0.0.1:9091
allow-lan: false
mode: rule

애플리케이션마다 HTTP와 SOCKS5를 나누어 사용해야 한다면 서로 다른 두 포트를 지정할 수 있습니다.

port: 7893
socks-port: 7894
external-controller: 127.0.0.1:9091
allow-lan: false
mode: rule

mixed-port: 7893, port: 7893, socks-port: 7893처럼 설정하지 마세요. 일부 클라이언트가 설정을 생성할 때 일부 필드를 무시하더라도 이러한 불명확한 동작에 의존해서는 안 됩니다. 실제로 활성화된 각 독립 수신기는 중복되지 않는 명확한 포트를 사용해야 합니다.

YAML을 수정할 때는 들여쓰기와 데이터 유형도 올바르게 유지해야 합니다. 포트는 일반적으로 정수로 작성합니다. 저장한 뒤 클라이언트에서 설정을 다시 불러오거나 코어를 재시작하고, 로그에서 새 포트가 수신 상태인지 확인하세요. 클라이언트에 “혼합 포트”, “HTTP 포트”, “SOCKS 포트”와 같은 화면 옵션이 있다면 화면에서 직접 수정하는 것이 좋습니다. 실행 설정과 화면 표시가 서로 달라지는 일을 피할 수 있습니다.

포트 변경 후 시스템 프록시 동기화

코어가 새 포트에서 정상적으로 수신한다고 해서 애플리케이션이 자동으로 새 포트를 사용하는 것은 아닙니다. 시스템 프록시가 여전히 이전 127.0.0.1:7890을 가리킬 수 있습니다. 클라이언트에서 시스템 프록시를 끈 다음 다시 활성화하면 현재 포트가 다시 적용되는 경우가 많습니다. 브라우저, 명령줄 도구, 다운로드 도구 또는 개발 환경에서 수동 프록시를 사용한다면 각 항목도 업데이트해야 합니다.

예를 들어 애플리케이션이 기존에 HTTP 프록시 127.0.0.1:7890을 사용했고 새 mixed-port가 7893이라면 127.0.0.1:7893으로 변경해야 합니다. SOCKS5를 사용하는 애플리케이션도 mixed-port에 연결할 수 있지만, 애플리케이션에서는 프록시 유형을 SOCKS5로 선택해야 합니다. 포트만 변경하고 프록시 프로토콜을 잘못 선택하면 연결 실패나 인증 형식 오류가 발생할 수 있습니다.

6. TUN 모드, DNS 수신과 로컬 네트워크 주소의 특수 사례

TUN 모드는 가상 네트워크 인터페이스를 통해 트래픽을 가로채므로 애플리케이션이 mixed-port에 직접 연결하지 않을 수 있습니다. 그러나 설정에서 mixed, HTTP, SOCKS 또는 제어 인터페이스를 활성화했다면 코어는 시작할 때 해당 수신기를 계속 생성하려고 합니다. 따라서 TUN이 켜져 있다고 해서 일반 프록시 포트 충돌을 무시할 수 있는 것은 아닙니다.

TUN을 점검할 때는 먼저 오류가 어느 단계에서 발생했는지 확인하세요. 로그가 127.0.0.1:7890 또는 0.0.0.0:9090의 바인딩 실패를 명확히 가리킨다면 포트 충돌로 처리합니다. 로그가 가상 네트워크 어댑터, 라우팅 테이블, 권한 또는 방화벽을 가리킨다면 TUN 환경을 확인해야 합니다. 두 문제가 동시에 발생할 수도 있으므로 로그에 따라 하나씩 해결해야 합니다.

DNS 모듈도 자주 놓치는 충돌 원인입니다. 예시 설정에는 다음과 같은 내용이 포함될 수 있습니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip

1053이 로컬 DNS 전달자가 이미 사용 중이면 Clash DNS 서비스가 시작되지 않습니다. TCP와 UDP 점유 상태를 모두 조회한 뒤 Clash의 dns.listen을 변경할지 다른 서비스의 설정을 변경할지 결정해야 합니다. DNS 수신 포트를 변경한 뒤에는 시스템, 라우팅 스크립트 또는 다른 전달 프로그램이 여전히 이전 포트로 요청을 보내고 있지 않은지도 확인하세요.

로컬 네트워크 접근을 활성화하면 수신 범위가 루프백 주소에서 네트워크 인터페이스로 확장될 수 있습니다. 한 프로그램이 127.0.0.1:7890만 수신하고 다른 프로그램이 0.0.0.0:7890에서 수신하려 하면 후자가 모든 IPv4 인터페이스를 사용하려 하기 때문에 충돌이 발생할 수 있습니다. 판단할 때는 포트 번호만 비교하지 말고 주소도 함께 확인해야 합니다.

7. 포트 수정이 완전히 적용되었는지 확인하기

수정이 끝난 뒤에는 시스템 프록시 잔여 설정, 설정 미전환 또는 노드 오류를 포트 문제로 오해하지 않도록 일정한 순서로 확인하는 것이 좋습니다.

코어를 다시 시작하고 로그에 bind 또는 address already in use가 더 이상 나타나지 않는지 확인합니다.
netstat, Get-NetTCPConnection, lsof 또는 ss로 새 포트를 확인하고, 수신 프로세스가 현재 Clash 코어인지 확인합니다.
클라이언트에서 현재 Profile이 선택되어 있는지, 규칙 모드, 전역 모드 또는 직접 연결 모드가 테스트 목적에 맞는지 확인합니다.
시스템 프록시를 다시 활성화하고 프록시 주소와 변경한 포트가 일치하는지 확인합니다.
제어 화면에서 노드, 정책 그룹과 연결 정보를 읽을 수 있는지 확인하여 제어 포트 충돌을 배제합니다.
브라우저 또는 지정 프록시를 사용하는 명령줄 요청으로 테스트하고, 연결 로그에 해당 요청이 표시되는지 확인합니다.
TUN을 사용한다면 가상 네트워크 어댑터, DNS 조회와 라우팅도 추가로 확인합니다.

포트는 수신 중인데 웹 페이지에 접속할 수 없다면 문제는 대개 “수신 충돌”에서 다른 계층으로 넘어간 상태입니다. 설정이 정상적으로 적용되었는지, 노드를 사용할 수 있는지, 규칙이 대상을 올바른 정책 그룹으로 전달하는지, DNS가 유효한 결과를 반환하는지, 애플리케이션이 실제로 새 프록시 주소를 사용하는지 확인해야 합니다. 포트 수신 성공은 로컬 진입점이 만들어졌다는 뜻일 뿐 상위 프록시 경로가 반드시 작동한다는 의미는 아닙니다.

판단하기 쉬운 테스트 상태로 모드를 잠시 변경하고 연결 로그에 요청이 표시되는지 확인할 수도 있습니다. 테스트가 끝나면 평소 사용하는 규칙 모드로 되돌리세요. 새 연결이 전혀 표시되지 않으면 시스템 프록시와 애플리케이션 프록시를 우선 확인하고, 연결은 표시되지만 실패한다면 노드, DNS, 규칙과 네트워크 연결을 점검해야 합니다.

8. 포트 사용 중 오류에 관한 자주 묻는 질문

7890이 사용 중이면 아무 숫자로 바꿔도 되나요?

1부터 65535 사이에서 사용 중이 아닌 포트를 선택할 수 있지만 시스템 서비스와 기존 애플리케이션이 사용하는 포트는 피해야 합니다. 변경하기 전에 수신 상태를 조회하고, 변경 후에는 시스템 프록시, 브라우저와 기타 수동 프록시 설정도 함께 업데이트하세요.

Clash 창을 닫았는데도 포트가 계속 사용 중인 이유는 무엇인가요?

일부 데스크톱 클라이언트는 창을 닫아도 트레이에서 계속 실행되며 코어 프로세스도 유지합니다. 트레이 메뉴에서 완전히 종료한 뒤 PID를 조회해 프로세스가 끝났는지 확인하세요. 프로세스가 자동으로 다시 실행된다면 시작 프로그램이나 백그라운드 서비스도 확인해야 합니다.

mixed-port와 socks-port에 같은 포트를 사용할 수 있나요?

그렇게 설정해서는 안 됩니다. mixed-port 자체가 HTTP와 SOCKS5 요청을 모두 수신합니다. 별도의 socks-port가 필요하다면 다른 포트를 지정하세요. 그렇지 않으면 두 수신기가 같은 주소와 포트를 두고 경쟁하게 됩니다.

포트를 변경한 뒤 Clash는 실행 중인데 시스템에서 인터넷이 되지 않으면 어떻게 하나요?

먼저 시스템 프록시가 이전 포트를 계속 가리키는지 확인하세요. 클라이언트에서 시스템 프록시를 끈 다음 다시 활성화하고 현재 Profile, 실행 모드와 연결 로그를 확인합니다. 고정 프록시 주소를 사용하는 애플리케이션도 별도로 변경해야 합니다.

9090 충돌이 프록시 트래픽에 영향을 주나요?

9090은 외부 제어 인터페이스에 자주 사용됩니다. 충돌이 발생하면 코어가 시작되지 않거나 클라이언트 화면이 코어에 연결하지 못해 정책 그룹과 연결 기록을 읽을 수 없습니다. mixed-port에 문제가 없더라도 제어 인터페이스에는 사용 가능한 별도 포트를 지정해야 합니다.

TUN 모드를 사용한 뒤에도 mixed-port를 유지해야 하나요?

사용 목적에 따라 다릅니다. TUN은 시스템 트래픽을 가로챌 수 있지만 브라우저 디버깅, 명령줄 도구 또는 다른 기기에서는 명시적인 프록시 진입점이 필요할 수 있습니다. mixed-port를 유지한다면 정상적으로 수신할 수 있어야 하며, 필요하지 않다면 클라이언트 설정에서 비활성화하세요.

포트 충돌의 핵심 판단 기준은 명확합니다. 특정 수신 주소와 포트를 프로세스가 이미 사용 중인데 Clash가 같은 조합에 바인딩을 시도하는 상황입니다. 로그를 기록하고 PID를 조회한 뒤 프로세스 용도를 확인하고, 설정을 변경한 다음 시스템 프록시를 동기화하면 문제를 구체적인 단계로 좁힐 수 있습니다. 처리가 끝난 뒤 Profile, 규칙, DNS와 TUN을 다시 확인하면 이후 네트워크 오류를 계속 포트 문제로 오해하는 일도 줄일 수 있습니다.