Clash 7890 포트가 사용 중일 때: 점유 프로세스 확인 및 mixed-port 변경

오류 메시지부터 확인: 프록시 포트인지 제어 포트인지 구분하기

Clash 또는 mihomo를 시작할 때 bind: address already in use가 표시되면, 커널이 수신하려는 로컬 주소와 포트를 현재 방식으로 바인딩할 수 없다는 뜻입니다. 같은 주소와 포트를 이미 다른 프로세스가 사용 중인 경우가 흔합니다. 먼저 로컬에서 어떤 프로세스가 수신 중인지 확인하세요. 구독을 다시 구매하거나 프록시 노드를 바꿀 필요는 없습니다. 구독의 원격 서버 포트와 PC의 7890 포트는 서로 다른 위치에 있습니다.

클라이언트 로그를 열고 listen, bind, 포트 번호가 포함된 줄 전체를 복사하세요. 아래는 항목을 알아보기 위한 예시이며, 클라이언트마다 출력 형식은 다를 수 있습니다.

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

표의 포트는 설정 예시이며 모든 클라이언트의 기본값은 아닙니다. 로그와 실제 적용된 설정을 기준으로 확인하세요. 로그에 9090이 표시된다면 먼저 제어 인터페이스를 확인해야 합니다. mixed-port만 7890에서 다른 값으로 바꿔도 제어 인터페이스의 충돌은 해결되지 않습니다.

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

1. 7890 포트의 수신 PID 확인

「시작」을 열고 「터미널」 또는 「PowerShell」을 검색하세요. 먼저 조회 명령을 실행합니다. 다른 사용자의 프로세스를 조회하거나 서비스를 중지할 때 권한 오류가 발생하면 관리자 권한으로 실행하세요. 아래 명령은 상태만 조회하며 프로세스를 종료하지 않습니다.

netstat -ano -p tcp | findstr ":7890"

로컬 주소가 127.0.0.1:7890, 0.0.0.0:7890 또는 [::]:7890이고 상태가 LISTENING인 줄을 확인하세요. 마지막 열이 PID입니다. :7890이 포함된 결과 중에는 원격 연결도 있을 수 있으므로 모든 줄을 수신 포트 점유로 보면 안 됩니다. 로컬 수신 항목만 정확히 필터링하려면 다음 명령을 사용하세요.

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

2. 프로세스 경로를 확인해 트레이 앱과 백그라운드 서비스를 구분

조회 결과가 PID 1234라고 가정합니다. 아래 숫자는 실제 PID로 바꿔 입력하세요. 먼저 프로세스 이름을 확인한 다음 실행 파일 경로와 시작 매개변수를 조회합니다.

tasklist /FI "PID eq 1234"

Get-CimInstance Win32_Process -Filter "ProcessId = 1234" |
  Select-Object ProcessId, ExecutablePath, CommandLine

오래된 클라이언트가 트레이에서 계속 실행 중인데 새 클라이언트가 커널을 다시 시작한 경우가 흔합니다. 서비스 모드의 mihomo가 이미 수신 중인 상태에서 그래픽 인터페이스가 두 번째 인스턴스를 실행했을 수도 있습니다. 먼저 해당 클라이언트 메뉴에서 「종료」를 선택하거나 「작업 관리자」→「세부 정보」에서 PID를 확인하세요. 백그라운드 서비스임을 확인했다면 「서비스」 관리 도구에서 서비스 이름과 실행 파일 경로를 확인한 뒤 중지할 서비스를 결정하세요.

정상적으로 종료해도 프로세스가 남아 있다면 확인된 PID에 Stop-Process -Id 1234를 실행할 수 있습니다. 종료하기 전에 설정을 저장하고 다른 사용자가 이용 중인 서비스가 아닌지 확인하세요. 이름을 기준으로 모든 프록시 프로세스를 일괄 종료하는 명령은 사용하지 마세요.

3. 수신 항목이 없는데도 바인딩되지 않는 경우

최신 로그를 다시 확인해 address already in use와 access permissions를 구분하세요. 후자는 시스템 예약 포트나 보안 정책과 관련될 수 있으므로 일반적인 포트 점유 문제로 처리하면 안 됩니다. Windows에서는 TCP 제외 범위를 추가로 조회할 수 있습니다.

netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp

대상 포트가 조회된 범위에 포함되면 범위 밖의 사용 가능한 포트를 선택하세요. 7890을 고정으로 쓰려고 시스템 제외 범위를 임의로 삭제하지 마세요. 가상화, 컨테이너, 네트워크 공유 기능이 이 설정에 의존할 수 있습니다.

macOS와 Linux: 수신 주소를 조회하고 실행 경로 확인하기

macOS: lsof 사용

「응용 프로그램」→「유틸리티」→「터미널」을 열고 다음 명령을 실행하세요. -nP는 이름 해석을 하지 않고 숫자 주소와 포트를 표시합니다. -sTCP:LISTEN은 TCP 수신 항목만 조회합니다.

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

출력에서 COMMAND, PID, NAME을 확인하세요. PID가 1234라고 가정하고 시작 명령을 추가로 확인합니다.

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

먼저 메뉴 막대에서 해당 클라이언트를 종료하세요. 직접 실행한 커널이라면 실행했던 터미널로 돌아가 Control-C를 누릅니다. 중지해도 되는 잔여 프로세스임을 확인한 뒤에만 kill -TERM 1234를 실행하세요. PID가 곧바로 바뀌며 다시 수신 상태가 되면 「시스템 설정」→「일반」→「로그인 항목 및 확장 프로그램」과 직접 설정한 launchd 서비스를 확인해 자동 재시작 원인을 처리하세요.

Linux: ss로 조회하고 systemd 서비스 확인

sudo ss -ltnp 'sport = :7890'
ps -p 1234 -o pid,ppid,user,args

ss에서 -l은 수신, -t는 TCP, -n은 숫자 표시, -p는 프로세스 표시를 뜻합니다. 출력에 systemd가 관리하는 커널이 표시되면 실제 서비스 단위 이름부터 확인하세요. 설치할 때 실제로 mihomo.service를 사용한 경우에만 다음 명령을 실행하세요.

systemctl status mihomo.service
sudo systemctl stop mihomo.service

사용자 단위 서비스는 systemctl --user로 조회하고 관리하세요. Docker로 배포했다면 docker ps에서 호스트 포트 매핑도 확인해야 합니다. 호스트의 7890 포트를 점유한 주체가 현재 데스크톱 클라이언트가 아니라 컨테이너의 포트 공개 설정일 수 있습니다.

mixed-port 변경: 사용 가능한 포트를 선택하고 실제 적용되는 설정 수정

기존 프로그램이 7890을 계속 사용해야 한다면 현재 Clash 클라이언트의 포트를 17890 등으로 바꿀 수 있습니다. 이는 예시일 뿐이며, PC에서 사용 가능한 포트라는 보장은 없습니다. 먼저 앞서 사용한 조회 명령에서 7890을 17890으로 바꿔 포트가 비어 있는지 확인하세요.

최소 로컬 수신 설정

mixed-port: 17890
allow-lan: false
bind-address: 127.0.0.1

external-controller: 127.0.0.1:19090
secret: "local-api-19090-change-before-use"

이 YAML 조각은 수신 관련 설정 항목을 설명하기 위한 예시입니다. 노드, 정책 그룹, 규칙이 포함되어 있지 않으므로 전체 구독 설정을 대체할 수 없습니다. 제어 포트를 19090으로 설정하는 예시도 포함되어 있습니다. 기존 제어 포트에 충돌이 없다면 원래 값을 유지해도 됩니다. secret 예시 값은 직접 생성한 임의 문자열로 바꾸고 관리 대시보드에도 같은 값을 설정하세요.

• 최상위 항목은 하나만 유지: 기존 mixed-port 값을 수정하고 파일 끝에 같은 키를 추가로 넣지 마세요. YAML 들여쓰기에는 공백을 사용하고 Tab은 사용하지 마세요.
• 전용 포트 확인: port 또는 socks-port도 활성화했다면 전용 수신 포트와 혼합 포트가 같은 주소와 포트를 사용하지 않도록 하세요. 혼합 포트만 필요하다면 클라이언트에서 지원하는 방식으로 불필요한 포트를 비활성화할 수 있습니다.
• 수신 범위 확인: 로컬에서만 사용할 때는 allow-lan: false를 유지하세요. 충돌을 해결하려고 모든 네트워크 인터페이스에서 수신하도록 바꾸면 프록시 포트에 접근할 수 있는 범위가 넓어질 수 있습니다.
• 제어 인터페이스는 로컬에서만 사용: external-controller는 관리 API에 사용됩니다. 127.0.0.1에 바인딩하고 비밀 키를 설정하세요. 인터넷에 직접 노출하지 마세요.

구독 파일, 오버라이드, 실행 설정의 차이

그래픽 인터페이스가 있는 클라이언트는 보통 구독과 로컬 설정을 병합해 mihomo에 전달할 최종 설정을 만듭니다. 다운로드 캐시의 YAML을 직접 수정하면 다음 구독 업데이트 때 덮어써질 수 있고, 임시 실행 파일을 편집하면 재시작 후 변경 사항이 사라질 수 있습니다. 먼저 클라이언트에서 「혼합 포트」, 「포트 설정」 또는 「오버라이드」 메뉴를 찾아보세요. 메뉴 이름은 클라이언트 버전에 따라 다를 수 있습니다.

수정한 뒤 저장하고 커널을 다시 시작하세요. 설정 창만 닫아서는 적용되지 않습니다. 시작 로그에서 수신 포트를 확인하거나 수신 조회 명령을 다시 실행하세요. mihomo 바이너리를 직접 사용하는 경우 설정 파일이 있는 디렉터리에서 mihomo -t -f config.yaml을 실행해 설정을 검사할 수 있습니다. 구문 검사를 통과해도 포트를 바인딩할 수 있다는 뜻은 아니므로 실제 시작 결과도 확인해야 합니다.

포트 변경 후 시스템 프록시와 명령줄 설정도 업데이트

커널이 17890에서 수신하도록 바꾼 뒤에도 트래픽을 7890으로 보내는 앱은 연결에 실패하거나 기존의 다른 프록시에 연결될 수 있습니다. 먼저 클라이언트의 「시스템 프록시」를 끈 다음 다시 켜고, 운영체제에 저장된 주소가 올바른지 확인하세요.

• Windows 11: 「설정」→「네트워크 및 인터넷」→「프록시」→「수동 프록시 설정」으로 이동하세요. 수동 프록시를 사용하는 경우 서버에 127.0.0.1, 포트에 17890을 입력합니다. PAC를 사용한다면 수동 프록시만 바꾸지 말고 PAC 규칙이 지정하는 대상도 확인하세요.
• macOS: 「시스템 설정」→「네트워크」→ 현재 네트워크 연결 →「세부사항」→「프록시」로 이동하세요. 활성화된 웹 프록시, 보안 웹 프록시 또는 SOCKS 프록시의 포트를 확인합니다.
• 개별 앱: 브라우저 프록시 확장 프로그램, 다운로드 도구, 편집기, Git의 사용자 지정 프록시 설정은 시스템 설정과 함께 자동으로 바뀌지 않을 수 있으므로 각각 확인하세요.

명령줄 도구는 환경 변수에 설정된 프록시를 사용할 수도 있습니다. 아래 명령으로 Windows PowerShell과 macOS·Linux 터미널의 프록시 변수를 각각 확인하세요.

# Windows PowerShell
Get-ChildItem Env: | Where-Object Name -Match 'proxy'

# macOS / Linux
env | grep -i proxy

예를 들어 HTTPS_PROXY=http://127.0.0.1:7890로 설정되어 있다면 새 포트로 함께 변경해야 합니다. 여기서 http://는 로컬 HTTP 프록시와 통신하는 방식이며 대상 웹사이트가 HTTP만 사용해야 한다는 뜻은 아닙니다. 영구 환경 변수를 변경한 뒤에는 보통 터미널을 다시 열어야 합니다. 이미 실행 중인 프로세스에는 새 값이 자동으로 적용되지 않습니다.

TUN 모드는 가상 네트워크 인터페이스로 들어오는 트래픽을 처리하는 기능으로, 혼합 포트 수신과는 별개의 단계입니다. TUN을 켜도 다른 프로세스가 점유한 7890 포트가 해제되지는 않습니다. HTTP 또는 SOCKS 프록시를 명시적으로 사용하는 앱은 해당 포트도 확인해야 합니다. 규칙 모드와 전역 모드를 전환해도 로컬 수신 포트 충돌은 해결되지 않습니다.

수정 확인: 수신 상태, 프록시 요청, 재시작 후 설정을 각각 점검

1. 수신 프로세스 확인: 17890을 다시 조회해 PID가 예상한 Clash 또는 mihomo 인스턴스인지 확인하세요. 이어서 오류가 발생했던 포트도 확인해 다른 서비스가 계속 사용 중인지 살펴봅니다.
2. 시작 로그 확인: 새 바인딩 오류가 없는지 확인하세요. 9090, 7891 등의 오류가 남아 있다면 각각 처리해야 합니다. 한 포트에서만 시작에 성공했다고 점검을 끝내면 안 됩니다.
3. 프록시 요청 직접 테스트: 아래 curl 명령을 사용해 브라우저 캐시만으로 프록시 연결 여부를 판단하지 마세요.
4. 설정 유지 확인: 클라이언트를 재시작한 뒤 다시 점검하세요. 다음 구독 업데이트 후에도 포트를 확인해 로컬 오버라이드가 계속 적용되는지 확인합니다.

# Windows PowerShell
curl.exe --noproxy "" -I --connect-timeout 5 --max-time 15 --proxy http://127.0.0.1:17890 https://example.com/

# macOS / Linux
curl --noproxy "" -I --connect-timeout 5 --max-time 15 --proxy http://127.0.0.1:17890 https://example.com/

여기서 --noproxy ""는 이번 요청에서 프록시 우회 목록을 비우는 옵션입니다. --connect-timeout 5는 연결 단계, --max-time 15는 요청 전체의 대기 시간을 제한합니다. 이는 테스트 옵션이며 속도 측정 결과가 아닙니다.

127.0.0.1:17890에 연결할 수 없다는 메시지가 바로 표시되면 수신 상태와 주소를 다시 확인하세요. 로컬 프록시에 연결된 뒤 TLS, DNS 또는 원격 연결 시간 초과 오류가 발생한다면 노드, DNS, 규칙을 점검해야 합니다. HTTPS 테스트에서 200 Connection established만 보인다면 프록시가 CONNECT 터널 요청을 수락했다는 뜻일 뿐입니다. 대상 사이트의 응답과 클라이언트 로그도 확인하세요.

자주 묻는 질문: 재설치, 방화벽, 클라이언트 두 개 동시 실행

Clash를 다시 설치하면 7890 포트 점유가 해결되나요?

다른 커널이 계속 실행 중이라 포트를 점유한 경우 현재 클라이언트를 다시 설치해도 해당 프로세스가 중지되지는 않습니다. 반복해서 제거하기보다 PID로 점유 프로세스의 출처를 먼저 찾는 편이 빠릅니다. 설정을 삭제하면 구독과 오버라이드가 사라질 수 있으므로 점검 전에 필요한 로컬 설정을 보관하세요.

방화벽을 끄면 address already in use 오류가 해결되나요?

방화벽은 주로 연결이 통과할 수 있는지에 영향을 줍니다. 이미 점유된 수신 포트를 앱 대신 해제해 주지는 않습니다. 바인딩 실패와 LAN 기기에서 접근할 수 없는 문제는 서로 다릅니다. 로컬 포트 충돌을 해결하기 위해 방화벽부터 끄지 마세요.

Clash 클라이언트 두 개를 동시에 실행할 수 있나요?

서로 다른 수신 포트와 제어 포트를 설정하면 두 인스턴스를 실행할 수 있지만 시스템 프록시, TUN 라우팅, DNS 처리도 함께 조정해야 합니다. 일반적인 데스크톱 환경에서는 시스템 네트워크를 담당하는 커널을 하나만 유지하는 편이 관리하기 쉽습니다. 동시에 테스트해야 한다면 두 번째 인스턴스는 별도의 로컬 프록시 포트만 제공하고 시스템 프록시와 TUN은 중복으로 점유하지 않도록 하세요.

로그에 UDP 포트 점유가 표시되면 같은 명령을 사용하나요?

앞에서 소개한 명령은 주로 TCP 수신 상태를 조회합니다. 로그에 UDP라고 명시되어 있다면 프로토콜에 맞는 명령으로 확인하세요. Windows는 Get-NetUDPEndpoint -LocalPort 7890, macOS는 sudo lsof -nP -iUDP:7890, Linux는 sudo ss -lunp 'sport = :7890'을 사용합니다. TCP와 UDP는 서로 다른 포트 공간을 사용하므로 TCP 조회 결과가 없다고 UDP 포트도 비어 있는 것은 아닙니다.

수정이 완료되었다고 판단하려면 예상한 커널이 정상적으로 수신하고 새 포트를 사용한 요청이 완료되며, 재시작과 구독 업데이트 후에도 설정이 유지되어야 합니다. 이후에도 연결 문제가 남아 있다면 도움말 센터에서 DNS, 구독, 규칙 문제를 구분해 보세요. 고급 설정에서 mihomo 설정 항목의 역할을 더 확인할 수도 있습니다.