Clash 포트 사용 중으로 시작 실패: 점유 프로세스 확인 및 혼합 포트 변경

먼저 포트 충돌인지 확인하기

Clash와 Clash Meta（mihomo）커널은 시작할 때 로컬 컴퓨터에서 하나 이상의 포트를 열어야 합니다. 일반적인 설정에서는 mixed-port를 7890으로 지정해 하나의 포트에서 HTTP와 SOCKS5 프록시 연결을 모두 받습니다. 해당 포트를 이미 다른 프로세스가 사용 중이면 새로 시작한 커널이 포트를 다시 바인딩할 수 없습니다. 클라이언트가 “시작 중” 화면에서 멈추거나 커널 시작 실패를 바로 표시할 수 있습니다.

로그에 다음과 같은 메시지가 나타나면 우선 포트 상태를 확인해 보세요. 커널 버전과 운영체제에 따라 표현은 조금 다르지만, 대개 bind、address already in use、Only one usage 또는 구체적인 포트 번호가 포함됩니다.

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

listen tcp 0.0.0.0:7890:
bind: Only one usage of each socket address is normally permitted

7890만 확인해서는 안 됩니다. 설정에는 별도의 HTTP 포트, SOCKS 포트, 투명 프록시 포트와 외부 제어 포트가 있을 수 있습니다. 예를 들어 어떤 설정은 port: 7890、socks-port: 7891、external-controller: 127.0.0.1:9090를 동시에 사용할 수 있습니다. 로그에서 바인딩에 실패한 주소가 표시되면 해당 포트를 확인하세요.

포트 충돌과 연결 실패는 다릅니다

포트 충돌: 커널이 시작되지 않으며 로그에 수신 대기 또는 바인딩 실패가 표시됩니다.
노드 연결 실패: 커널은 이미 시작되었지만 프록시 노드가 시간 초과되며, 로그는 대개 원격 주소를 가리킵니다.
시스템 프록시가 갱신되지 않음: 커널은 정상적으로 포트를 열었지만 브라우저가 이전 포트에 계속 연결해 웹페이지가 열리지 않습니다.
제어 포트 충돌: 프록시 포트는 사용할 수 있지만 그래픽 인터페이스가 커널에 연결되지 않습니다. 일반적으로 external-controller의 9090 또는 다른 사용자 지정 포트가 관련됩니다.

먼저 클라이언트 로그에서 전체 오류 메시지를 찾은 뒤 해당 포트를 확인하면 노드 장애를 로컬 포트 문제로 잘못 판단하는 일을 피할 수 있습니다. 로그에 YAML 들여쓰기 오류나 필드 형식 오류 같은 구성 분석 오류가 표시된다면 7890을 변경해도 시작 실패는 해결되지 않습니다.

Windows: netstat로 점유 프로세스 찾기

Windows 10과 Windows 11에는 netstat가 기본으로 포함되어 있습니다. Clash Nyanpasu를 완전히 종료한 다음 일반 권한으로 “터미널” 또는 “명령 프롬프트”를 열고 다음 명령을 실행하세요:

netstat -ano | findstr :7890

포트가 사용 중이라면 다음과 비슷한 결과가 표시됩니다. 마지막 열의 18432는 포트 번호가 아니라 프로세스 PID입니다.

TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    18432
TCP    [::1]:7890        [::]:0       LISTENING    18432

그런 다음 확인한 PID를 tasklist에 전달해 프로세스 이름을 확인하세요:

tasklist /FI "PID eq 18432"

다른 프록시 클라이언트, 이전 버전의 Clash 커널 또는 백그라운드에서 실행 중인 데스크톱 클라이언트가 반환되면 해당 프로그램의 종료 메뉴를 사용해 정상적으로 닫는 것이 우선입니다. 비정상적으로 남은 프로세스라면 이름과 PID를 확인한 후 종료할 수 있습니다:

taskkill /PID 18432 /F

PowerShell로 더 명확하게 확인하기

PowerShell은 해당 수신 대기 포트를 소유한 프로세스 ID를 바로 반환할 수 있습니다. Windows 11의 “터미널”은 기본적으로 PowerShell인 경우가 많습니다:

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

OwningProcess를 확인한 뒤 프로세스를 계속 조회하세요:

Get-Process -Id 18432

Clash 설정에서 UDP 수신도 활성화했다면 TCP 조회 결과가 비어 있어도 충돌을 완전히 배제할 수 없습니다. UDP도 추가로 확인하세요:

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

수신 대기 주소로 영향 범위 판단하기

수신 대기 결과	의미	확인할 사항
`127.0.0.1:7890`	로컬 IPv4 루프백 주소만 사용	로컬 프록시 프로그램과 이전 커널 확인
`[::1]:7890`	로컬 IPv6 루프백 주소만 사용	동일한 프로세스가 IPv4와 IPv6를 동시에 사용할 수 있음
`0.0.0.0:7890`	모든 IPv4 네트워크 인터페이스에서 수신 대기	LAN 접속을 허용한 프록시 또는 개발 도구 확인
`[::]:7890`	모든 IPv6 네트워크 인터페이스에서 수신 대기	듀얼 스택 수신 대기와 포트 재사용 여부 확인

하나의 PID가 두 줄에 동시에 표시되는 것은 보통 충돌하는 프로그램이 두 개라는 뜻이 아니라, 해당 프로그램이 IPv4와 IPv6를 각각 수신 대기한다는 의미입니다. 실제로 확인해야 할 것은 포트를 소유한 프로세스가 지금 시작하려는 커널인지, 그리고 시스템에 다른 인스턴스가 남아 있는지입니다.

macOS 및 Linux: lsof와 ss로 포트 확인

macOS에서는 “응용 프로그램”→“유틸리티”→“터미널”에서 lsof를 실행할 수 있습니다. 다음 명령은 TCP 7890만 조회하고 수신 대기 상태로 필터링합니다:

lsof -nP -iTCP:7890 -sTCP:LISTEN

출력에서 COMMAND는 프로세스 이름이고 PID는 프로세스 번호입니다. 예시는 다음과 같습니다:

COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
mihomo   4217 user   11u  IPv4  0x01      0t0  TCP 127.0.0.1:7890 (LISTEN)

먼저 메뉴 막대로 돌아가 실행 중인 Clash 클라이언트가 남아 있는지 확인하세요. 이미 인터페이스로 제어할 수 없는 잔여 프로세스라면 먼저 정상 종료 신호를 보낼 수 있습니다:

kill 4217

2초 후 lsof를 다시 실행하세요. 프로세스가 종료되지 않았고 대상이 확실히 확인된 경우에만 강제 종료를 고려하세요:

kill -9 4217

Linux에서는 ss를 우선 사용

대부분의 최신 Linux 배포판에는 ss가 기본으로 설치되어 있습니다. TCP 7890의 수신 대기 프로세스를 확인하려면 다음을 실행하세요:

sudo ss -lptn 'sport = :7890'

UDP를 확인할 때는 다음 명령을 사용하세요:

sudo ss -lpun 'sport = :7890'

시스템에 lsof가 설치되어 있다면 다음과 같은 이식 가능한 명령도 사용할 수 있습니다:

sudo lsof -nP -i :7890

Linux에서는 systemd 서비스도 확인해야 합니다. 수동으로 실행한 그래픽 클라이언트를 종료한 뒤에도 시스템 수준의 mihomo 서비스가 백그라운드에서 포트를 사용하고 있을 수 있습니다. 먼저 서비스 상태를 조회한 다음 중지 여부를 결정하세요:

systemctl status mihomo
sudo systemctl stop mihomo

서비스 이름은 실제 설치 방식에 따라 다르며 clash 또는 사용자 지정 유닛 이름일 수도 있습니다. 용도를 확인하지 않은 상태에서 바로 비활성화하지 마세요. 해당 서비스가 평소 사용하는 프록시 커널이라면 그대로 유지하고 그래픽 클라이언트가 다른 포트 그룹을 사용하도록 설정하는 편이 적절합니다.

Clash Nyanpasu에서 혼합 포트 변경하기

7890을 사용하는 프로그램을 계속 실행해야 한다면 Clash Nyanpasu에 사용하지 않는 다른 포트를 지정할 수 있습니다. 일반적인 경로는 「설정」→「Clash 설정」→「일반」→「혼합 포트（Mixed Port）」입니다. 버전에 따라 메뉴 이름은 달라질 수 있지만 커널 또는 Clash 매개변수 영역에서 mixed-port를 찾아야 합니다.

먼저 netstat、lsof 또는 ss로 새로 사용할 포트가 비어 있는지 확인하세요. 예를 들어 7893을 사용할 수 있습니다.
혼합 포트를 7890에서 7893으로 변경하세요.
설정을 저장한 다음 커널을 한 번 재시작하거나 클라이언트를 완전히 종료했다가 다시 여세요.
로그로 돌아가 127.0.0.1:7893에서 수신 대기가 시작되었다는 기록이 있는지 확인하세요.
시스템 프록시를 다시 활성화해 운영체제의 프록시 주소가 새 포트와 동기화되도록 하세요.

1024보다 크고 현재 사용되지 않는 포트를 우선 선택하는 것이 좋습니다. 포트 번호의 최댓값은 65535입니다. 충돌을 피하려고 80이나 443 같은 낮은 포트로 변경하지 마세요. 추가 권한이 필요할 수 있고 웹 서비스와 충돌하기도 쉽습니다.

포트를 변경했는데도 웹페이지가 열리지 않는 이유

포트 변경이 성공했다는 것은 커널이 해당 포트에서 수신 대기할 수 있게 되었다는 뜻일 뿐입니다. 브라우저, 터미널 및 다른 앱도 새 포트에 연결해야 합니다. 시스템 프록시에 127.0.0.1:7890이 계속 저장되어 있으면 요청은 이전 주소로 전송됩니다. 가장 간단한 방법은 “시스템 프록시”를 한 번 끈 뒤 다시 켜서 클라이언트가 127.0.0.1:7893을 기록하도록 하는 것입니다.

터미널의 환경 변수는 시스템 프록시를 변경해도 항상 자동으로 갱신되지는 않습니다. 이전에 프록시를 수동으로 설정했다면 다음 항목도 함께 변경하세요:

export HTTP_PROXY=http://127.0.0.1:7893
export HTTPS_PROXY=http://127.0.0.1:7893
export ALL_PROXY=socks5://127.0.0.1:7893

혼합 포트를 사용하면 하나의 7893 포트에서 HTTP 프록시와 SOCKS5 프록시 연결을 모두 받을 수 있으므로 위 설정에서 같은 포트를 사용할 수 있습니다. 설정이 별도의 port와 socks-port를 사용한다면 각각 해당 포트를 입력해야 하며, 모두 7893으로 바꿔서는 안 됩니다.

구성 파일에서 mixed-port 직접 변경하기

mihomo 명령줄, 컨테이너 또는 직접 관리하는 구성 파일을 사용하는 경우 YAML을 바로 편집할 수 있습니다. 가장 간단한 형식은 다음과 같습니다:

mixed-port: 7893
allow-lan: false
mode: rule
log-level: info

mixed-port는 HTTP와 SOCKS5가 함께 사용하는 인바운드 포트입니다. 이 필드를 사용하고 있다면 같은 값을 port와 socks-port에 동시에 지정할 필요가 없는 경우가 많습니다. 중복되거나 겹치는 수신 대기 설정은 다시 바인딩 실패를 일으킬 수 있고 문제 해결도 더 어렵게 만듭니다.

HTTP와 SOCKS5 포트를 반드시 분리해야 한다면 서로 다른 값을 사용하세요:

port: 7893
socks-port: 7894
allow-lan: false
mode: rule
log-level: info

외부 제어 인터페이스에도 별도의 포트를 지정해야 합니다. 예를 들면 다음과 같습니다:

mixed-port: 7893
external-controller: 127.0.0.1:9091
secret: "change-this-controller-secret"

여기서는 프록시 진입 포트를 7893으로, 제어 인터페이스를 9091로 설정했습니다. 두 포트의 용도는 다릅니다. 7893은 앱의 프록시 트래픽을 받고, 9091은 그래픽 인터페이스나 제어판이 커널 API를 호출할 때 사용합니다. 로그에 9090 사용 중이라고 명확히 표시되면 mixed-port만 변경해서는 해결되지 않습니다. external-controller를 변경하고 클라이언트의 컨트롤러 연결 설정도 함께 갱신해야 합니다.

변경 후 구성을 확인한 다음 커널 재시작하기

명령줄에서 mihomo를 실행한다면 먼저 커널이 제공하는 구성 검사 옵션을 사용할 수 있습니다. 실제 실행 파일 이름은 설치 방식에 따라 다릅니다:

mihomo -t -f config.yaml

검사가 통과된 후 기존 방식으로 시작하세요. 그래도 실패한다면 전체 로그를 확인하고 오류 메시지에 표시된 포트가 7893으로 바뀌었는지 확인하세요. 로그에 계속 7890이 표시된다면 현재 시작 중인 프로세스가 방금 편집한 구성 파일을 사용하지 않거나, 그래픽 클라이언트가 시작할 때 실행용 구성을 다시 생성하는 경우가 많습니다.

포트를 변경한 후에도 시작되지 않을 때 확인할 5가지

1. 새 포트도 사용 중인 경우

7891이나 7892를 무작정 선택하지 마세요. 이 포트들도 프록시 도구에서 자주 사용됩니다. 변경 전에 먼저 조회 명령을 실행하세요. Windows에서는 netstat -ano | findstr :7893、macOS에서는 lsof -nP -iTCP:7893 -sTCP:LISTEN을 실행할 수 있습니다. 출력이 없으면 일반적으로 TCP 수신 대기 프로세스가 없다는 뜻이지만 UDP 인바운드를 활성화했다면 UDP도 확인해야 합니다.

2. 클라이언트가 커널 두 개를 동시에 시작한 경우

자동 시작, 서비스 모드와 수동 시작이 중복 인스턴스를 만들 수 있습니다. 먼저 클라이언트를 완전히 종료하고 7890, 7893 및 제어 포트가 모두 해제되었는지 확인한 뒤 한 번만 시작하세요. 클라이언트를 종료하자마자 포트가 다시 나타난다면 시스템 시작 프로그램, 예약 작업, 로그인 항목 또는 systemd 서비스를 확인해야 합니다.

3. 구성 오버라이드가 실제로 적용되지 않은 경우

구독의 mixed-port: 7890이 클라이언트 전역 설정으로 덮어쓰일 수 있고, 반대로 시작 매개변수가 구성 파일보다 우선할 수도 있습니다. 판단 기준은 편집기의 YAML 내용이 아니라 실행 로그와 실제 수신 대기 결과여야 합니다. 시작 후 포트를 다시 조회해 커널이 실제로 어떤 주소를 사용 중인지 확인하세요.

4. 외부 제어 포트 충돌

프록시 포트가 비어 있다고 해서 모든 수신 대기가 정상적으로 설정되는 것은 아닙니다. 로그에서 127.0.0.1:9090、9091 또는 다른 제어 포트를 가리키는지 확인하세요. 제어 포트를 변경했다면 그래픽 인터페이스의 연결 주소도 함께 변경해야 합니다. 그렇지 않으면 커널은 실행 중인데 패널에는 “연결되지 않음”으로 표시될 수 있습니다.

5. 수신 대기 주소 또는 권한이 적절하지 않은 경우

allow-lan을 활성화하면 설정이 0.0.0.0 또는 지정된 LAN 주소에서 수신 대기할 수 있습니다. 해당 주소가 더 이상 유효하지 않으면 로그에 “cannot assign requested address”가 표시될 수 있으며, 이는 일반적인 포트 사용 중 오류가 아닙니다. 수신 대기 주소를 유효한 인터페이스로 되돌리거나 127.0.0.1에서만 수신 대기하도록 변경한 뒤 다시 시도하세요. 1024 이하의 포트를 사용하면 권한 부족 문제가 발생할 수 있으므로 더 높은 포트를 사용하세요.

7890 포트 충돌을 예방하는 설정 습관

자동 시작 경로는 하나만 유지하세요: 그래픽 클라이언트, 백그라운드 서비스와 예약 작업이 동시에 커널을 시작하지 않도록 하세요.
클라이언트마다 다른 포트를 할당하세요: 예를 들어 기본 클라이언트는 7890, 테스트 인스턴스는 7893, 컨테이너 인스턴스는 7895를 사용합니다.
제어 포트를 기록해 두세요: 프록시 포트와 external-controller를 따로 기록하고, 문제를 해결할 때 로그에 나온 항목을 하나씩 확인하세요.
종료 후 트레이를 확인하세요: 창을 닫아도 프로세스가 종료되는 것은 아닙니다. 업그레이드하거나 클라이언트를 전환하기 전에 완전히 종료하세요.
클라이언트가 시스템 프록시를 관리하도록 하세요: 혼합 포트를 변경한 뒤 시스템 프록시를 껐다가 다시 켜서 이전 포트가 남는 일을 줄이세요.
로컬 포트는 영구 설정에 저장하세요: 구독은 노드와 규칙을 관리하고, 로컬 수신 포트는 클라이언트의 오버라이드 또는 전역 설정으로 관리하세요.

한 장치에서 여러 mihomo 인스턴스를 동시에 실행해야 한다면 각 인스턴스에 서로 다른 혼합 포트, 제어 포트와 실행 디렉터리를 할당해야 합니다. 7890만 변경해서는 모든 리소스를 분리할 수 없습니다. 캐시, 데이터베이스, Unix socket 또는 명명된 파이프에도 별도 경로가 필요할 수 있으며, 구체적인 내용은 실행 방식과 클라이언트 구현에 따라 달라집니다.

빠른 문제 해결 순서

클라이언트 로그를 열고 바인딩에 실패한 전체 주소와 포트를 기록하세요.
Clash Nyanpasu를 완전히 종료하고 포트가 함께 해제되는지 확인하세요.
Windows에서는 netstat 또는 PowerShell, macOS에서는 lsof, Linux에서는 ss로 PID를 조회하세요.
프로세스 이름을 확인한 뒤 중복 클라이언트를 정상 종료하거나 중복 서비스를 중지하세요.
점유 프로그램을 계속 실행해야 한다면 mixed-port를 7893처럼 사용 가능하다고 확인한 포트로 변경하세요.
external-controller도 함께 확인해 프록시 포트 충돌만 해결하는 일이 없도록 하세요.
커널을 재시작한 뒤 로그와 수신 대기 결과로 새 설정이 적용되었는지 확인하세요.
시스템 프록시를 다시 활성화하고 터미널 환경 변수와 포트를 수동으로 입력한 앱도 갱신하세요.

포트 사용 중 문제의 본질은 로컬 수신 리소스 충돌입니다. 해결의 핵심은 클라이언트를 반복해서 재설치하는 것이 아니라 로그에서 포트를 확인하고 시스템 명령으로 PID를 찾은 뒤, 점유 프로세스를 종료할지 설정을 변경할지 결정하는 데 있습니다. 변경을 마친 후에는 시스템 프록시와 터미널 환경 변수도 반드시 동기화하세요. 그렇지 않으면 커널이 다시 실행되어도 앱은 계속 이전 포트에 접속합니다.