Clash 포트 사용 중 오류 해결: 충돌 프로세스 확인부터 수신 포트 변경까지

먼저 충돌한 수신 포트가 무엇인지 확인하기

Clash, Clash Meta(mihomo) 또는 그래픽 클라이언트가 시작되지 않을 때 로그에는 bind: address already in use, listen tcp 127.0.0.1:7890 또는 Only one usage of each socket address is normally permitted 같은 핵심 메시지가 자주 나타납니다. 모두 같은 유형의 문제를 가리킵니다. 커널이 로컬 포트를 수신하려 하지만 해당 주소와 포트 조합을 다른 프로세스가 이미 사용 중인 상태입니다.

7890이라는 숫자만 보고 곧바로 설정을 바꾸지 마세요. 먼저 전체 로그를 읽고 HTTP, SOCKS, 혼합 프록시, 컨트롤러 또는 DNS 중 어떤 수신이 실패했는지 확인해야 합니다. 포트마다 역할이 다르므로 변경 후 함께 수정해야 하는 클라이언트 설정도 달라집니다.

로그에 표시된 주소도 함께 확인하기

• 127.0.0.1:7890: IPv4 로컬 루프백 주소에서만 수신하므로 같은 네트워크의 기기에서 직접 접근할 수 없습니다.
• 0.0.0.0:7890: 모든 IPv4 네트워크 인터페이스에서 수신하며, 일반적으로 클라이언트의 ‘LAN 허용’ 설정과 관련됩니다.
• [::]:7890: 모든 IPv6 인터페이스에서 수신합니다. 일부 시스템에서는 같은 포트의 IPv4 수신에도 영향을 줄 수 있습니다.
• 127.0.0.1:9090: 일반적으로 외부 컨트롤러용 포트이며 브라우저에 입력하는 프록시 포트가 아닙니다.

포트 번호가 같아도 수신 주소가 다르면 반드시 충돌하는 것은 아닙니다. 동시에 사용할 수 있는지는 운영체제, IPv6 듀얼 스택 동작과 프로그램 설정에 따라 달라집니다. 문제를 확인할 때는 숫자 하나만 기록하지 말고 프로토콜, 수신 주소, 포트와 프로세스 ID를 함께 적어야 합니다.

Windows에서 netstat로 포트 점유 프로세스 찾기

Windows 10과 Windows 11에서는 시스템에 기본 포함된 netstat을 바로 사용할 수 있습니다. 먼저 Clash 클라이언트를 완전히 종료한 다음 일반 권한으로 PowerShell 또는 명령 프롬프트를 열고 7890을 아직 수신 중인 프로세스가 있는지 확인합니다.

1단계: 7890 수신 기록 찾기

netstat -ano | findstr :7890

출력 결과는 여러 줄일 수 있습니다. 상태가 LISTENING인 TCP 기록을 찾는 것이 중요하며, 마지막 열이 PID입니다. 예를 들어 아래의 PID는 14672입니다:

TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    14672

findstr :7890은 원격 7890 포트에 연결 중인 기록도 찾아낼 수 있으므로 포트 숫자만 보고 판단해서는 안 됩니다. 7890이 ‘로컬 주소’ 열에 있고 상태가 LISTENING인지 반드시 확인하세요.

2단계: PID를 프로그램에 연결하기

tasklist /FI "PID eq 14672"

mihomo.exe, clash.exe 또는 다른 프록시 클라이언트의 커널 파일이 반환된다면 기존 인스턴스가 종료되지 않은 경우가 많습니다. 개발 서버, 컨테이너 포트 전달 도구 또는 다른 로컬 네트워크 프로그램이 반환되면 어떤 프로그램의 포트를 바꾸는 것이 적절한지 판단해야 합니다.

‘작업 관리자’ → ‘세부 정보’를 열고 PID 열을 클릭해 정렬한 뒤 14672를 찾을 수도 있습니다. 작업 관리자에 PID가 기본적으로 표시되지 않으면 표 머리글을 마우스 오른쪽 버튼으로 클릭하고 ‘열 선택’ → ‘PID(프로세스 식별자)’를 선택하세요.

3단계: PowerShell로 TCP와 UDP를 각각 확인하기

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

Get-Process -Id 14672

DNS, TProxy 또는 일부 전달 진입점은 UDP를 사용할 수도 있습니다. UDP 엔드포인트를 확인하려면 다음을 실행합니다:

Get-NetUDPEndpoint -LocalPort 1053 |
  Select-Object LocalAddress, LocalPort, OwningProcess

UDP에는 LISTENING 상태가 없으므로 TCP 필터 조건을 그대로 사용할 수 없습니다. Clash 로그에 listen udp가 명확히 표시된다면 Get-NetUDPEndpoint 또는 netstat -ano -p udp를 사용해야 합니다.

4단계: 먼저 정상 종료하고 강제 종료는 피하기

1. 점유 프로세스가 다른 프록시 클라이언트라면 트레이 메뉴에서 종료하세요.
2. 점유 프로세스가 Windows 서비스로 실행 중이라면 services.msc를 열고 해당 서비스를 찾아 중지합니다.
3. 해당 프로세스가 다운로드, 컨테이너 전달 또는 개발 작업을 더 이상 수행하지 않는지 확인한 뒤에야 프로세스 종료를 고려하세요.
4. netstat -ano | findstr :7890을 다시 실행해 수신 기록이 사라졌는지 확인합니다.

프로세스를 강제 종료하면 현재 점유만 해제됩니다. 프로그램에 시작 시 자동 실행, 서비스 자동 복구 또는 충돌 후 재시작이 설정되어 있다면 몇 초 뒤 포트가 다시 나타납니다. 이때는 시작 항목을 수정하거나 두 프로그램 중 하나에 고정된 새 포트를 할당해야 합니다.

macOS와 Linux에서 lsof·ss로 충돌 찾기

macOS에서는 시스템에 기본 포함된 lsof로 수신 프로세스를 확인할 수 있습니다. Clash 그래픽 클라이언트를 종료한 뒤 ‘터미널’을 열고 다음 명령을 실행하세요:

lsof -nP -iTCP:7890 -sTCP:LISTEN

-nP는 주소와 포트를 숫자 형식으로 유지해 호스트 이름 확인으로 인한 지연을 막습니다. 출력의 COMMAND는 프로그램 이름이고 PID는 프로세스 ID입니다. 전체 실행 인자를 확인하려면 이어서 다음을 실행할 수 있습니다:

ps -p 14672 -o pid,ppid,user,command

UDP 수신은 다음 명령으로 확인할 수 있습니다:

lsof -nP -iUDP:1053

기존 커널을 클라이언트가 실행한 경우 먼저 macOS 메뉴 막대에서 클라이언트를 종료하세요. kill 14672만 직접 실행하면 클라이언트의 데몬이 커널을 곧바로 다시 시작할 수 있어 PID만 바뀌고 7890은 계속 사용 중인 것처럼 보일 수 있습니다.

Linux에서는 ss를 우선 사용하기

최신 Linux 배포판에는 보통 ss가 기본 설치되어 있습니다. 다음 명령은 7890을 수신 중인 TCP 프로세스를 표시합니다:

sudo ss -ltnp 'sport = :7890'

DNS 수신 또는 다른 UDP 포트는 다음과 같이 확인합니다:

sudo ss -lunp 'sport = :1053'

mihomo를 systemd로 관리한다면 서비스 상태도 확인해야 합니다. 서비스 이름은 설치 방식에 따라 달라지며, 일반적인 명령은 다음과 같습니다:

systemctl --type=service | grep -Ei 'clash|mihomo'
sudo systemctl status mihomo

중복 서비스임을 확인했다면 해당 서비스 이름으로 기존 인스턴스를 중지한 뒤 자동 시작을 비활성화할지 결정하세요. 용도를 모르는 상태에서 서비스 파일을 바로 삭제하면 안 됩니다. 서비스 설정에 TUN 권한, 라우팅 초기화와 방화벽 정리 단계가 포함되어 있을 수 있습니다.

mixed-port, port와 컨트롤러 포트 변경하기

충돌한 프로그램이 기존 포트를 계속 사용해야 한다면 Clash에 사용하지 않는 포트를 할당하세요. 1024보다 크고 현재 수신 기록이 없는 포트를 선택하는 것이 좋습니다. 예를 들어 7890을 17890으로 변경할 수 있습니다. 포트 범위는 1~65535이지만 macOS와 Linux에서는 1024 미만 포트에 보통 추가 권한이 필요하므로 일반 데스크톱 클라이언트의 프록시 진입점으로 적합하지 않습니다.

mixed-port만 사용하는 설정

mixed-port는 하나의 포트에서 HTTP 프록시와 SOCKS5 프록시를 모두 받을 수 있습니다. 로컬 진입점 하나만 필요한 데스크톱 환경에서는 다음처럼 간단히 설정할 수 있습니다:

mixed-port: 17890
allow-lan: false
bind-address: 127.0.0.1
external-controller: 127.0.0.1:19090

변경 후 시스템 프록시의 HTTP와 HTTPS 주소를 모두 127.0.0.1:17890으로 지정해야 합니다. SOCKS5를 사용하는 앱도 127.0.0.1:17890을 입력하되 프로토콜 유형은 SOCKS5로 선택하세요.

HTTP와 SOCKS5를 별도 수신하기

port: 17890
socks-port: 17891
allow-lan: false
external-controller: 127.0.0.1:19090

프로토콜을 명확히 구분해야 하는 환경에 적합한 방식입니다. 브라우저 수동 프록시 또는 시스템 HTTP 프록시는 17890을 사용하고, SOCKS5를 지원하는 터미널 도구는 17891을 사용합니다. mixed-port와 port를 같은 포트로 설정하면 안 됩니다. 중복 바인딩으로 커널이 여전히 시작되지 않습니다.

DNS 수신 포트 변경 방법

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

DNS를 1053에서 11053으로 변경했다면 해당 수신 주소를 사용하는 전달기도 함께 수정해야 합니다. 예를 들어 로컬 dnsmasq, 라우팅 규칙 또는 클라이언트의 DNS 가로채기 설정이 여전히 1053을 가리키면 도메인 요청이 새 포트로 자동 전환되지 않습니다.

그래픽 클라이언트에서 변경할 때 설정 출처 확인하기

클라이언트마다 메뉴 이름은 다를 수 있습니다. 일반적인 경로는 ‘설정’ → ‘환경 설정’ → ‘포트 설정’ 또는 ‘설정’ → ‘Clash 설정’ → ‘혼합 포트’입니다. 저장한 뒤에는 설정 창만 닫지 말고 ‘커널 재시작’을 한 번 실행해야 합니다.

포트가 구독 설정에서 가져온 값이라면 현재 YAML을 직접 편집해도 구독 업데이트 후 덮어쓰일 수 있습니다. 더 안정적인 방법은 클라이언트가 제공하는 오버라이드 기능을 사용하는 것입니다. 예를 들어 ‘프로필’ → ‘오버라이드’ → ‘포트’에서 로컬 포트 값을 영구 설정으로 저장합니다. 오버라이드 기능이 없다면 변경 항목을 기록해 두고 구독 업데이트 후 포트가 원래 값으로 돌아갔는지 확인하세요.

변경 후 포트·시스템 프록시·실제 연결 확인하기

설정 저장에 성공했다고 문제가 끝난 것은 아닙니다. 전체 확인은 네 단계로 진행해야 합니다. 기존 포트가 해제되었는지 확인하고, 새 포트가 수신을 시작했는지 확인한 다음, 시스템 프록시를 동기화하고 마지막으로 실제 프록시 요청을 한 번 보냅니다.

1. 새 포트가 수신 중인지 확인

Windows에서 실행:

netstat -ano | findstr :17890
Test-NetConnection 127.0.0.1 -Port 17890

Test-NetConnection 결과에서 TcpTestSucceeded가 True여야 합니다. macOS 또는 Linux에서는 다음을 실행할 수 있습니다:

lsof -nP -iTCP:17890 -sTCP:LISTEN

7890도 다시 확인하세요. 기존 포트가 다른 프로그램에서 계속 사용 중이어도 반드시 Clash에 영향을 주는 것은 아니지만, 최초 충돌 원인이 여전히 존재하며 현재는 기존 프로그램과 새 프로그램이 서로 다른 포트에서 함께 실행 중임을 알 수 있습니다.

2. 시스템 프록시가 여전히 기존 포트를 가리키는지 확인

• Windows 11: ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’로 이동해 수동 프록시 서버의 포트를 확인합니다.
• macOS: ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 → ‘세부사항’ → ‘프록시’로 이동해 웹 프록시와 보안 웹 프록시를 확인합니다.
• 브라우저 확장 프로그램: 프록시 프로필에서 HTTP, HTTPS 또는 SOCKS5 포트를 확인합니다.
• 터미널 환경 변수: HTTP_PROXY, HTTPS_PROXY와 ALL_PROXY에 여전히 7890이 포함되어 있는지 확인합니다.

대부분의 Clash 그래픽 클라이언트는 ‘시스템 프록시’를 활성화하면 새 포트를 자동으로 기록하지만, 수동으로 설정한 브라우저·개발 도구·명령줄 환경은 자동으로 업데이트되지 않습니다. 포트를 변경한 뒤 ‘클라이언트는 실행 중인데 브라우저에서 접속할 수 없는’ 경우는 대개 호출 측이 여전히 기존 포트에 연결하고 있기 때문입니다.

3. curl로 명확한 프록시 요청 보내기

curl -I -x http://127.0.0.1:17890 https://example.com

독립 SOCKS5 포트 17891을 사용하는 경우 다음을 실행할 수 있습니다:

curl -I --socks5-hostname 127.0.0.1:17891 https://example.com

명령이 HTTP 응답 헤더를 반환한다면 로컬 포트가 연결을 수락하고, 프록시 프로토콜이 일치하며 요청이 완료된 것입니다. Connection refused가 표시되면 새 포트가 수신 중이 아닙니다. 장시간 시간 초과가 발생하면 노드, 프록시 그룹, DNS와 네트워크 연결을 계속 확인하세요. 프로토콜 오류가 반환되면 HTTP 클라이언트를 SOCKS5만 허용하는 포트에 연결했을 가능성이 있습니다.

4. 커널 로그와 연결 목록 확인

클라이언트의 ‘로그’ 페이지를 열고 수준을 info로 설정하세요. 테스트 요청을 보내면 대상 도메인, 일치한 규칙과 최종 정책이 표시되어야 합니다. 예를 들어 도메인이 DOMAIN-SUFFIX에 일치한 뒤 특정 프록시 그룹으로 전달되는 식입니다. 이어서 ‘연결’ 페이지를 열고 출발지 주소가 127.0.0.1인지 확인하며 업로드·다운로드 바이트 수가 변하는지도 살펴보세요.

포트 충돌이 반복될 때의 확인 순서

포트를 변경한 뒤 한동안 지나 다시 충돌한다면 시스템에 자동 시작 또는 설정 덮어쓰기가 존재할 가능성이 큽니다. 계속 포트를 바꾸기보다 다음 순서로 확인하는 편이 근본 원인을 찾기 쉽습니다.

1. 두 Clash 클라이언트가 동시에 자동 시작되는지 확인합니다. 예를 들어 기존 클라이언트가 로그인 항목에 남아 있고 새 클라이언트도 시작 시 자동 실행되도록 설정되어 있으면 두 프로그램 모두 7890을 수신하려고 합니다.
2. GUI와 독립 커널 서비스가 중복 실행되는지 확인합니다. 그래픽 클라이언트가 이미 mihomo를 관리하고 있다면 systemd, launchd 또는 Windows 서비스가 같은 설정으로 다른 인스턴스를 시작하게 해서는 안 됩니다.
3. 구독 업데이트 후 오버라이드 결과를 확인합니다. 업데이트 전에는 17890이었는데 업데이트 후 다시 7890이 되었다면 로컬 변경이 영구 오버라이드에 반영되지 않은 것입니다.
4. external-controller를 확인합니다. 프록시 포트는 정상인데 화면에 계속 연결 실패가 표시된다면 충돌 지점은 7890이 아니라 9090일 수 있습니다.
5. DNS의 TCP와 UDP를 확인합니다. 일부 DNS 서비스는 두 프로토콜을 동시에 수신하므로 TCP만 확인하면 UDP 1053의 점유를 놓칠 수 있습니다.
6. LAN 허용으로 수신 범위가 바뀌었는지 확인합니다. 127.0.0.1에서 0.0.0.0으로 전환하면 더 많은 인터페이스에서 수신하게 되어 기존 서비스와 충돌할 수 있습니다.

장기간 사용하기 좋은 포트 구성

포트 번호 자체는 규칙 일치, 노드 지연 시간 또는 프록시 속도에 영향을 주지 않습니다. 중요한 것은 각 수신 주소를 의도한 프로세스 하나만 사용하게 하고 시스템 프록시, 브라우저, DNS 전달기와 컨트롤 패널이 동일한 새 설정을 사용하도록 하는 것입니다. 변경을 마친 뒤 포트 기록을 보관해 두면 클라이언트 업그레이드, 커널 전환 또는 구독 업데이트 후 빠르게 대조할 수 있습니다.