Clash 포트 사용 중 오류 해결: 프로세스 확인 및 포트 변경

먼저 오류가 포트 충돌인지 확인하기

Clash가 코어를 시작하려면 로컬 주소에 하나 이상의 수신 포트를 열어야 합니다. 브라우저, 시스템 프록시 또는 다른 앱이 이 포트로 요청을 보내면 코어가 프록시 그룹과 규칙에 따라 트래픽을 처리합니다. 같은 네트워크 프로토콜, 수신 주소, 포트를 다른 프로세스가 이미 사용 중이면 새 수신 소켓을 열지 못하는 경우가 많습니다.

일반적인 증상은 다음과 같습니다. 클라이언트 화면은 열리지만 코어가 즉시 종료되고, 시스템 프록시 버튼은 전환되지만 웹페이지에 접속할 수 없으며, 로그에 address already in use, bind, listen tcp 또는 “포트가 이미 사용 중입니다”와 같은 메시지가 나타납니다. 일부 GUI 클라이언트는 코어 시작을 반복 시도하므로 로그에 같은 오류가 연속해서 기록될 수 있습니다.

“인터넷에 연결할 수 없음”만으로 포트를 바로 바꾸지는 마세요. 설정 파싱 오류, 만료된 구독 내용, 사용할 수 없는 프록시 노드, 비활성화된 시스템 프록시, 방화벽 제한도 비슷한 증상을 일으킬 수 있습니다. 포트 충돌을 판단할 때는 먼저 로그에 표시된 구체적인 주소를 확인하세요. 예를 들어 127.0.0.1:7890, 0.0.0.0:7890 또는 :9090처럼 표시됩니다. 콜론 뒤 숫자가 확인해야 할 포트입니다.

포트 충돌과 권한 오류 구분하기

“주소가 이미 사용 중입니다”는 일반적으로 이미 수신 중인 프로세스가 있다는 뜻입니다. 반면 “권한이 거부되었습니다” 또는 permission denied는 반드시 포트 사용을 의미하지 않습니다. 낮은 번호의 포트, 시스템 예약 포트, 보안 프로그램 정책, 운영체제의 포트 제외 범위 때문에 바인딩이 차단될 수도 있습니다. 일반적인 설정에서는 사용 중이지 않은 높은 번호의 포트를 선택하고, 흔히 쓰이는 서비스 포트는 임의로 사용하지 않는 것이 좋습니다.

mixed-port, port, socks-port 구분하기

충돌을 처리하기 전에 오류가 어느 설정 항목과 관련된 것인지 먼저 확인해야 합니다. 항목마다 대상 프로토콜이 다르고, 변경 후 함께 수정해야 하는 앱도 달라집니다. Clash와 mihomo에서 자주 사용하는 수신 항목은 다음과 같습니다.

데스크톱 클라이언트에서 가장 흔한 충돌은 mixed-port입니다. 예를 들어 클라이언트 A가 백그라운드에서 7890을 계속 사용 중인데 클라이언트 B도 7890을 사용하려 하면, 나중에 시작한 코어가 수신 소켓을 열지 못합니다. 놓치기 쉬운 또 다른 경우는 프록시 포트는 정상인데 external-controller에 사용되는 9090이 점유된 상황입니다. 이때 GUI가 코어에 연결되지 않거나 실행 상태를 읽지 못할 수 있습니다.

용도가 겹치고 포트 번호까지 같은 항목을 동시에 유지하지 마세요. 예를 들어 mixed-port와 port를 모두 7890으로 설정하면 같은 코어 내부에서 바인딩 경쟁이 발생합니다. 일반적인 데스크톱 시스템 프록시를 주로 사용한다면 mixed-port 하나만 유지하는 편이 관리하기 쉽습니다. HTTP와 SOCKS5 진입점을 명확히 분리해야 할 때만 port와 socks-port를 각각 설정하세요.

Windows, macOS, Linux에서 수신 프로세스 찾기

로그에서 포트를 확인했다면 다음 단계는 어떤 프로세스가 수신 중인지 찾는 것입니다. 확인하기 전에 현재 Clash 클라이언트를 완전히 종료하고 몇 초간 기다린 뒤 명령을 실행하세요. 그래도 포트가 수신 상태라면 다른 프록시 클라이언트, 남아 있는 코어 프로세스, 개발 서버, 컨테이너 매핑 또는 시스템 서비스가 점유하고 있을 수 있습니다.

Windows: 포트에서 PID 찾기

명령 프롬프트에서 TCP 포트 7890을 확인합니다.

netstat -ano | findstr :7890

결과의 마지막 열이 PID입니다. 상태가 LISTENING인 항목을 우선 확인한 다음 PID로 프로그램 이름을 조회하세요.

tasklist /FI "PID eq 1234"

PowerShell에서도 해당 수신 포트를 소유한 프로세스를 바로 나열할 수 있습니다.

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 1234

명령 프롬프트에서 권한 부족 메시지가 표시되면 필요한 권한이 있는 터미널에서 다시 시도하세요. 여러 항목이 표시되면 로컬 주소를 비교해야 합니다. 일부 프로그램은 IPv4와 IPv6에서 각각 수신하므로 작업 관리자에는 프로세스 하나만 보이더라도 명령 결과에는 수신 항목 두 개가 표시될 수 있습니다.

macOS: lsof로 수신 프로세스 확인하기

lsof -nP -iTCP:7890 -sTCP:LISTEN

출력에서 COMMAND는 프로세스 이름이고 PID는 프로세스 번호입니다. 일반 권한으로 전체 정보가 표시되지 않으면 명령 내용을 확인한 뒤 다음과 같이 실행할 수 있습니다.

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

macOS에서는 창을 닫는 것이 클라이언트 종료와 같지 않을 수 있습니다. 메뉴 막대의 상태 항목을 확인하고 클라이언트의 종료 명령으로 주 프로그램을 끝내세요. 주 프로그램을 종료한 뒤에도 코어 프로세스가 남아 있다면 PID와 프로그램 경로를 기준으로 어느 클라이언트에 속하는지 판단해야 합니다.

Linux: TCP와 UDP를 함께 확인하기

sudo ss -ltnp | grep ':7890 '
sudo ss -lunp | grep ':7890 '

첫 번째 명령은 TCP를, 두 번째 명령은 UDP를 확인합니다. 일반적인 HTTP, SOCKS5 및 제어 인터페이스는 주로 TCP를 확인하면 되지만 DNS 수신과 일부 투명 프록시 환경에서는 UDP도 확인해야 합니다. 시스템에 lsof가 설치되어 있다면 macOS와 비슷한 명령을 사용할 수도 있습니다.

기존 프로세스를 종료할지 Clash 포트를 변경할지 결정하기

점유 프로세스를 확인한 뒤에는 두 가지 처리 방법이 있습니다. “어느 쪽이 더 빠른가”가 아니라 장기적으로 누가 해당 포트를 사용해야 하는지를 기준으로 선택하세요.

기존 프로세스를 종료하기에 적합한 경우

• 더 이상 사용하지 않는 다른 Clash 또는 프록시 클라이언트가 포트를 점유한 경우
• 같은 클라이언트가 비정상 종료된 뒤 독립적으로 실행되는 이전 코어가 남은 경우
• 클라이언트가 시작 시 자동 실행되도록 설정되어 있지만 이제 다른 클라이언트를 사용하려는 경우
• 테스트 프로그램이 프록시 포트를 임시로 사용 중이며 종료해도 다른 작업에 영향을 주지 않는 경우

먼저 앱 자체의 종료 기능이나 서비스 중지 명령을 사용해 상태 저장과 네트워크 설정 복원을 진행하게 하세요. GUI로 제어할 수 없는 잔류 프로세스라고 확인된 경우에만 PID로 종료하는 방법을 고려하세요. 종료한 뒤 포트 확인 명령을 다시 실행해 수신 항목이 사라졌는지 확인하고 Clash를 시작하세요.

Clash 포트를 변경하기에 적합한 경우

• 기존 포트가 계속 실행되어야 하는 서비스에 속한 경우
• 두 프록시 코어를 동시에 실행하면서 서로 다른 테스트 작업을 수행해야 하는 경우
• 조직 또는 장치 정책에서 특정 포트 범위를 고정적으로 예약한 경우
• 클라이언트를 시작할 때마다 컨테이너 매핑, 개발 도구 또는 가상 머신 서비스와 충돌하는 경우

새 포트는 세 가지 조건을 충족해야 합니다. 현재 수신 중인 프로세스가 없어야 하고, 설정의 다른 항목과 중복되지 않아야 하며, 사용하는 앱에서도 함께 변경할 수 있어야 합니다. 먼저 7891, 17890과 같은 높은 번호의 포트를 선택한 뒤 시스템 명령으로 비어 있는지 확인하세요. 포트의 최대값은 65535이며 음수, 문자 또는 범위를 벗어난 값은 입력할 수 없습니다.

YAML 설정 변경 및 구독 업데이트로 인한 덮어쓰기 방지

클라이언트 설정 화면에서 포트를 변경할 수 있다면 해당 기능을 우선 사용하세요. 클라이언트가 이를 바탕으로 실행 설정을 동기화해 생성할 수 있기 때문입니다. YAML을 직접 편집하기 전에는 현재 파일이 실제 실행 설정인지, 구독 원본 설정인지, 클라이언트가 생성한 임시 사본인지 먼저 확인해야 합니다.

하나의 혼합 포트를 사용할 때는 다음과 같이 설정할 수 있습니다.

mixed-port: 7891
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9091

HTTP와 SOCKS5 진입점을 분리해야 한다면 두 항목에 서로 다른 포트를 할당하세요.

port: 7891
socks-port: 7892
external-controller: 127.0.0.1:9091

변경 후에는 먼저 설정을 검증한 다음 코어를 다시 시작하세요. YAML은 공백으로 계층을 표현하므로 Tab, 잘못된 들여쓰기 또는 중복 항목 때문에 새로운 파싱 오류가 발생할 수 있습니다. 포트 값은 정수로 작성해야 합니다. 같은 항목이 병합 설정, 오버라이드 스크립트, 구독 내용에 여러 번 나타난다면 최종 적용 값은 클라이언트의 설정 병합 과정에 따라 달라집니다. 특정 파일 하나만 확인해서는 안 됩니다.

두 코어를 동시에 실행할 때는 프록시 포트뿐 아니라 제어 포트, DNS 수신 포트, 투명 프록시 포트도 하나씩 확인해야 합니다. 두 인스턴스가 각각 mixed-port: 7890과 mixed-port: 7891을 사용하더라도 충분하지 않습니다. 둘 다 external-controller: 127.0.0.1:9090에 바인딩하면 두 번째 인스턴스가 여전히 시작되지 않을 수 있습니다.

포트 변경 후 시스템 프록시와 앱 설정 동기화

포트 충돌을 해결한 뒤에도 인터넷에 연결되지 않는 가장 흔한 이유는 “수신 포트는 바뀌었지만 요청은 여전히 이전 포트로 전송되는” 상황입니다. 예를 들어 Clash를 mixed-port: 7891로 변경했는데 Windows나 macOS의 시스템 프록시가 여전히 127.0.0.1:7890을 가리키면 브라우저는 새 수신 진입점에 연결할 수 없습니다.

시스템 프록시

Clash 클라이언트가 시스템 프록시를 자동으로 관리한다면 먼저 시스템 프록시를 끈 다음 다시 켜서 새 주소를 기록하게 하세요. 이후 운영체제 네트워크 설정에서 HTTP 및 HTTPS 프록시가 127.0.0.1과 새 포트를 가리키는지 확인합니다. mixed-port를 사용할 때는 HTTP 프록시에 해당 포트를 그대로 입력할 수 있습니다.

브라우저 및 독립 앱

일부 브라우저 확장 프로그램, 다운로드 도구, 코드 편집기, 채팅 프로그램, 원격 연결 도구는 시스템 프록시를 따르지 않고 자체 프록시 주소를 저장합니다. 각 앱의 HTTP 또는 SOCKS5 포트를 하나씩 확인하세요. 앱이 SOCKS5로 설정되어 있는데 현재 port만 유지되고 있다면 프로토콜이 맞지 않습니다. mixed-port로 바꾸거나 앱에 별도의 socks-port를 지정하세요.

터미널 환경 변수

명령줄 도구는 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY를 읽을 수 있습니다. 기존 세션의 환경 변수는 Clash 설정이 바뀌어도 자동으로 업데이트되지 않습니다. 임시 환경 변수를 예로 들면 포트는 실제 수신 값과 일치해야 합니다.

HTTP_PROXY=http://127.0.0.1:7891
HTTPS_PROXY=http://127.0.0.1:7891
ALL_PROXY=socks5://127.0.0.1:7891

터미널마다 변수 설정 문법이 다르므로 위 내용은 주소 구조를 설명하기 위한 예시입니다. 시작 스크립트나 시스템 환경 변수를 변경하기 전에는 다른 도구가 기존 포트에 의존하지 않는지 확인하세요.

LAN 장치

휴대폰이나 다른 장치가 컴퓨터의 Clash 프록시를 사용한다면 allow-lan: true를 설정하는 것 외에도 컴퓨터가 LAN에서 사용하는 실제 주소와 새 포트를 입력해야 합니다. 이때 수신 주소, 방화벽 인바운드 규칙, 네트워크 격리 설정이 모두 연결에 영향을 줍니다. 휴대폰에 127.0.0.1을 입력하지 마세요. 휴대폰에서는 이 주소가 휴대폰 자체를 가리킵니다.

TUN 모드에서 DNS와 제어 포트도 확인하기

TUN 모드를 켜면 많은 앱이 시스템 HTTP 프록시를 직접 읽지 않으므로 사용자는 mixed-port가 문제와 전혀 관련 없다고 생각하기 쉽습니다. 실제로 코어는 혼합 프록시 포트, 제어 인터페이스, DNS 서비스를 동시에 시작할 수 있으며, 필수 수신 항목 중 하나라도 충돌하면 코어 시작이 중단되거나 일부 기능이 비정상적으로 작동할 수 있습니다.

로그가 dns.listen을 가리킨다면 다음과 같이 DNS 설정을 확인하세요.

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

1053이 다른 DNS 전달기에 의해 사용 중이라면 비어 있는 다른 포트로 변경할 수 있습니다. 단, 해당 수신 주소에 의존하는 설정도 함께 업데이트해야 합니다. DNS를 TUN이 자동으로 인계하는 구성이라면 예시만 보고 무작정 변경하지 말고 클라이언트가 생성한 실제 설정과 로그를 기준으로 판단하세요.

제어 인터페이스 충돌은 코어가 계속 실행되는 것처럼 보이지만 GUI에 “연결 실패”, “설정을 가져올 수 없음”이 표시되거나 상태가 계속 로딩되는 형태로 나타날 수 있습니다. 이때 external-controller의 포트를 확인하고 클라이언트가 코어에 연결할 때 사용하는 주소가 동일한지 확인하세요. 제어 포트를 변경한 뒤에는 외부 패널의 북마크나 클라이언트 내부 컨트롤러 주소도 함께 변경해야 합니다.

투명 프록시 환경에서는 redir-port, tproxy-port, 방화벽 규칙도 관련될 수 있습니다. YAML만 변경하고 리디렉션 대상은 업데이트하지 않으면 트래픽이 계속 이전 포트로 들어갑니다. Linux 사용자는 정책 라우팅, 방화벽 규칙, 서비스 시작 인자도 함께 확인해 별도 스크립트에 고정 포트가 지정되어 있지 않은지 살펴보세요.

순서대로 포트 충돌 재점검하기

변경을 마친 뒤에는 “클라이언트 화면이 초록색으로 바뀌었다”는 사실만으로 판단하지 마세요. 수신 상태, 프록시 진입점, 규칙 처리, 실제 접속의 네 단계로 재점검하면 포트 문제와 노드 문제를 구분하기 쉽습니다.

1. 클라이언트를 완전히 종료한 뒤 다시 시작합니다. 이전 코어가 종료되었는지 확인해 잔류 프로세스가 테스트 결과에 영향을 주지 않도록 합니다.
2. 시작 로그를 확인합니다. 기존의 bind 또는 address already in use 오류가 더 이상 나타나지 않는지 확인합니다.
3. 새 포트를 조회합니다. netstat, lsof 또는 ss로 현재 Clash 또는 mihomo 코어가 수신 중인지 확인합니다.
4. 시스템 프록시를 확인합니다. 주소는 일반적으로 127.0.0.1이고 포트는 mixed-port 또는 port와 일치해야 합니다.
5. 독립 앱 설정을 확인합니다. 특히 브라우저 확장 프로그램, 터미널 변수, 다운로드 도구 및 SOCKS5를 사용하는 프로그램을 점검합니다.
6. 로컬 연결 테스트를 실행합니다. 먼저 요청이 로컬 프록시에 도달하는지 확인한 다음 로그에 해당 연결 기록이 나타나는지 살펴봅니다.
7. 노드 장애를 구분합니다. 로그에 요청이 기록되고 규칙 매칭까지 완료되었는데 대상 연결이 시간 초과된다면 로컬 포트를 다시 변경하지 말고 프록시 노드, 정책 그룹, 네트워크 환경을 계속 확인하세요.
8. 구독 업데이트를 한 번 실행합니다. 업데이트 후 포트 값을 다시 확인해 로컬 설정이 구독 내용에 의해 덮어써지지 않았는지 확인합니다.

포트 충돌 해결 과정은 로그에서 포트를 추출하고, 실제 수신 프로세스를 조회한 뒤, 포트의 사용 주체를 판단하고, 충돌하는 항목 하나만 변경한 다음, 모든 요청 진입점을 동기화하는 순서로 정리할 수 있습니다. 클라이언트를 반복해서 재설치하거나 여러 포트를 무작위로 바꾸는 것보다 이 단계를 순서대로 수행하는 편이 관리 가능한 설정을 유지하기 쉽습니다.