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

먼저 로그에서 수신 주소와 포트를 확인하세요

Clash에서 포트 사용 중 오류가 발생하는 것은 일반적으로 지정된 주소에서 커널이 수신 대기할 수 없다는 뜻입니다. 프록시 클라이언트 두 개를 동시에 실행했거나, 이전 커널이 완전히 종료되지 않았거나, 백그라운드 서비스가 같은 포트를 사용 중일 때 주로 발생합니다. 이 경우 구독을 업데이트하거나 노드를 바꾸고 라우팅 규칙을 수정해도 로컬 수신 충돌은 해결되지 않습니다.

먼저 클라이언트의 '로그' 페이지를 열고 bind, listen 또는 address already in use가 포함된 전체 기록을 찾으세요. Windows에서는 Only one usage of each socket address라고 표시될 수도 있습니다. 아래는 오류 유형을 확인하기 위한 예시이며, 실제 기기에서 수집한 출력은 아닙니다:

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

첫 번째 줄은 로컬 프록시 포트, 두 번째 줄은 컨트롤 인터페이스와 관련된 오류입니다. 실제 오류에 표시된 포트를 기준으로 확인해야 합니다. Clash 실행 오류가 떴다고 무조건 7890만 확인하지 마세요. 로그에 permission denied 또는 소켓 액세스 거부가 표시되면 권한, 시스템 예약 포트 범위 또는 보안 정책 문제일 수도 있으므로 다른 프로세스가 점유했다고 단정해서는 안 됩니다.

설정 항목	용도 및 예시	변경 후 영향
`mixed-port`	HTTP와 SOCKS가 함께 사용하는 포트(예: 7890)	시스템 프록시와 프록시를 수동으로 지정한 앱의 설정도 업데이트해야 합니다
`port` / `socks-port`	HTTP와 SOCKS 포트를 각각 제공하며, 값은 설정에 따라 다릅니다	해당 프로토콜을 사용하는 앱의 설정도 업데이트해야 합니다
`external-controller`	컨트롤 인터페이스(예: `127.0.0.1:9090`)	패널이나 클라이언트에서 커널에 연결하는 설정도 업데이트해야 할 수 있습니다

Windows: netstat로 PID를 확인한 뒤 프로그램 경로 확인

PowerShell에서 수신 프로세스 찾기

'시작' 버튼을 마우스 오른쪽 버튼으로 클릭하고 '터미널'을 선택한 다음 PowerShell 탭에서 아래 명령을 실행하세요. 조회에는 일반적으로 관리자 권한이 필요하지 않습니다. 프로세스 정보를 볼 수 없을 때만 관리자 권한으로 터미널을 여세요.

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

로컬 주소가 :7890으로 끝나는지, 상태가 LISTENING인지 확인하세요. 원격 주소에 7890이 포함되어 있거나 연결 상태가 TIME_WAIT인 것만으로는 프로그램이 로컬 7890 포트에서 수신 중이라고 볼 수 없습니다. 각 행의 맨 오른쪽 숫자가 PID입니다.

대상 포트의 수신 항목만 보려면 PowerShell에서 다음 명령을 실행하세요:

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

PID가 1234라고 가정하고 프로세스 이름과 경로를 확인합니다. 1234는 예시이므로 실행할 때는 방금 확인한 PID로 바꾸세요:

tasklist /FI "PID eq 1234"
Get-Process -Id 1234 | Select-Object Id, ProcessName, Path

출처를 확인한 뒤 프로그램 종료

다른 프록시 클라이언트가 점유 중이라면 해당 클라이언트의 트레이 메뉴에서 '종료'를 선택하세요. 창만 닫아서는 안 됩니다.
현재 클라이언트의 이전 커널이 점유 중이라면 먼저 클라이언트를 정상 종료한 뒤 PID를 다시 조회해 백그라운드 프로세스가 남아 있는지 확인하세요.
다른 업무용 프로그램이 점유 중이라면 해당 프로그램은 계속 실행하고, 사용 가능한 프록시 포트를 선택하세요.
PID가 서비스 또는 시스템 프로세스에 해당하면 '작업 관리자' → '세부 정보'와 '서비스'를 먼저 확인하세요. 강제 종료하지 마세요.

프로세스 이름에 mihomo나 clash가 있다고 해서 반드시 남은 프로세스인 것은 아닙니다. 서비스 모드로 실행 중인 클라이언트는 커널을 백그라운드에서 계속 실행할 수 있습니다. 트레이 프로그램이나 서비스를 정리하지 않고 프로세스만 종료하면 커널이 곧바로 다시 실행될 수 있습니다.

macOS 및 Linux: lsof, ss로 수신 프로세스 확인

macOS: 앱 창과 메뉴 막대 프로세스 구분

'응용 프로그램' → '유틸리티' → '터미널'을 열고 TCP 7890 포트의 수신 프로세스를 조회하세요:

lsof -nP -iTCP:7890 -sTCP:LISTEN

-nP는 주소와 포트를 숫자로 표시해 이름 해석으로 인한 혼란을 방지합니다. 출력의 COMMAND, PID, NAME은 각각 프로세스, 프로세스 번호, 수신 주소를 확인하는 데 사용됩니다. 일반 조회 결과가 없는데도 오류가 계속되면 sudo lsof -nP -iTCP:7890 -sTCP:LISTEN을 실행해 다른 사용자가 소유한 프로세스도 확인하세요.

점유 프로세스를 확인한 뒤 메뉴 막대 아이콘에서 해당 클라이언트를 종료하세요. macOS에서는 창을 닫아도 앱이 종료되지 않는 경우가 많습니다. 특정 PID의 실행 명령을 확인하려면 다음 명령을 실행하세요:

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

Linux: 데스크톱 클라이언트와 서비스 모두 확인

대부분의 Linux 배포판에서는 ss로 조회할 수 있습니다. 전체 프로세스 정보를 표시하려면 보통 권한 상승이 필요합니다:

sudo ss -ltnp 'sport = :7890'

확인된 커널이 systemd 서비스에서 실행 중이라면 데스크톱 창을 닫아도 서비스는 중지되지 않습니다. 출력에 표시된 프로세스 경로로 소속을 확인한 다음, 해당 서비스 관리 화면에서 중복 인스턴스를 중지하세요. 서비스 이름은 설치 방식에 따라 다르므로 인터넷에서 찾은 서비스 이름을 그대로 사용하지 마세요.

127.0.0.1:7890은 IPv4 로컬 루프백 주소에서 수신 중임을 뜻합니다.
0.0.0.0:7890은 모든 IPv4 인터페이스에서 수신 중임을 뜻하며, 루프백 주소에만 바인딩된 인스턴스와 충돌할 수 있습니다.
[::]:7890은 IPv6 와일드카드 주소입니다. IPv4 연결도 함께 허용하는지는 시스템 및 소켓 설정에 따라 다릅니다.

따라서 문제를 확인할 때 127.0.0.1:7890과 정확히 일치하는 행만 찾아서는 안 됩니다. 와일드카드 주소, IPv6 수신 항목, 다른 사용자가 실행하는 서비스도 확인해야 합니다.

mixed-port 변경: 실제 적용된 설정 기준으로 확인

점유 프로세스를 확인한 뒤에는 두 가지 방법으로 처리할 수 있습니다. 불필요한 중복 인스턴스를 종료하고 7890을 계속 사용하거나, 기존 프로그램을 유지하고 현재 클라이언트의 포트를 사용 가능한 값으로 바꾸세요. 먼저 앞에서 안내한 명령으로 17890의 사용 여부를 확인한 뒤 변경하세요. 아래 설정은 해당 필드를 지원하는 Clash 커널 및 Clash Meta(mihomo)용이며, 완전한 구독 파일이 아닙니다.

먼저 클라이언트에서 관리하는 포트 설정 변경

현재 혼합 포트, HTTP 포트, SOCKS 포트, 컨트롤 인터페이스 주소를 기록하고 설정 사본을 저장하세요.
클라이언트의 '설정'을 열고 '포트' 또는 '혼합 포트' 항목을 찾으세요. 클라이언트에 따라 'Clash 설정'이나 '커널 설정' 아래에 있을 수 있으며 메뉴 이름은 다를 수 있습니다.
혼합 포트를 17890으로 변경하고 저장한 다음, 클라이언트에서 제공하는 커널 재시작 기능을 실행하세요.
로그를 다시 열어 새 포트에서 수신이 시작됐는지 확인한 다음 시스템 명령으로 17890의 점유 프로세스가 예상한 커널인지 확인하세요.

클라이언트가 YAML로 이 값을 관리한다면 실제로 적용되는 로컬 설정 또는 오버라이드 설정을 수정하세요:

# 기존 설정에 병합하세요. 이 조각으로 전체 설정을 덮어쓰지 마세요.
mixed-port: 17890
allow-lan: false

allow-lan: false는 LAN 연결을 제한하는 설정이지 포트 점유를 해제하는 옵션이 아닙니다. 로컬에서만 사용할 경우 문제 해결을 위해 수신 주소를 0.0.0.0으로 바꾸거나 LAN 액세스를 함부로 활성화하지 마세요.

기존 포트와 오버라이드 출처 확인

설정에 port, socks-port, mixed-port가 함께 정의되어 있을 수 있습니다. 혼합 포트를 바꿔도 다른 포트가 자동으로 제거되지는 않습니다. 다른 수신 항목에서 오류가 발생했다면 각각 따로 처리해야 합니다. 하나의 YAML 맵에 mixed-port 키를 여러 번 추가하지 마세요.

클라이언트의 전역 설정, 병합 설정 또는 오버라이드 규칙이 구독 파일의 값을 덮어쓸 수도 있습니다. 다운로드한 구독 파일을 직접 수정하면 다음 업데이트 때 원래 값으로 돌아갈 수 있습니다. 클라이언트가 지원하는 지속 설정을 사용하고, 시작 로그와 시스템의 수신 상태를 기준으로 최종 적용값을 확인하세요. 편집기에 저장된 값만 확인해서는 안 됩니다.

9090 충돌: 외부 컨트롤 포트를 별도로 처리

로그에 9090이 명확히 표시되면 혼합 포트를 계속 바꾸지 말고 9090을 점유한 프로세스를 확인하세요. 컨트롤 인터페이스는 클라이언트나 패널에서 커널을 관리하는 용도이며, 브라우저에서 웹 페이지를 열기 위한 HTTP 프록시 포트가 아닙니다.

# 클라이언트에서 컨트롤 인터페이스 사용자 지정을 지원하는 경우에만 이 항목을 병합하세요.
external-controller: 127.0.0.1:19090

일부 데스크톱 클라이언트는 컨트롤 주소와 인증 정보를 자동으로 관리합니다. 우선 클라이언트에서 제공하는 설정 메뉴를 이용하세요. 생성된 설정을 강제로 변경하면 메인 화면에서 커널에 연결할 수 없게 될 수 있습니다. 외부 패널을 수동으로 연결하는 경우 컨트롤 주소를 127.0.0.1:19090으로 변경하고 인증 키도 일치시켜야 합니다.

시스템 프록시, 터미널 변수, 앱 내부 프록시 업데이트

새 포트에서 수신이 시작된 뒤에도 앱이 이전 포트에 연결하는 것이 가장 흔한 후속 문제입니다. 이 경우 로그에 바인딩 오류는 더 이상 표시되지 않지만 브라우저에서 프록시 연결 실패가 나타나거나 터미널에서 connection refused 오류가 발생할 수 있습니다. 프록시를 사용하는 항목을 하나씩 확인하세요.

시스템 프록시: 17890으로 설정됐는지 확인

Windows 11: '설정' → '네트워크 및 인터넷' → '프록시' → '수동 프록시 설정' → '편집'을 열고 주소와 포트를 확인하세요. 클라이언트가 설정을 관리한다면 클라이언트의 '시스템 프록시'를 껐다가 다시 켜서 설정을 새로 적용하는 방법이 일반적입니다.
macOS: '시스템 설정' → '네트워크' → 현재 네트워크 서비스 → '세부사항' → '프록시'를 열고 웹 프록시, 보안 웹 프록시, SOCKS 프록시 중 실제로 활성화된 항목을 확인하세요.
앱 내부 프록시: 브라우저 프록시 확장 프로그램, 개발 도구, 다운로드 도구는 별도의 설정을 사용할 수 있습니다. 수동으로 입력한 127.0.0.1:7890을 127.0.0.1:17890으로 바꾸세요.

자동 프록시 구성 스크립트(PAC)를 사용하면 프록시 대상이 수동 프록시 입력란이 아닌 스크립트에서 지정될 수 있습니다. 현재 프록시가 어디에서 설정되는지 확인하고, 확장 프로그램의 프록시 제어와 시스템 수동 프록시를 동시에 켠 상태에서 한쪽만 수정하지 않도록 주의하세요.

터미널: 환경 변수는 클라이언트 설정에 맞춰 자동으로 바뀌지 않습니다

PowerShell에서는 다음 명령으로 현재 창의 HTTP 및 HTTPS 프록시를 임시로 변경할 수 있습니다. HTTPS 변수에도 http://를 사용하는 이유는 로컬 HTTP 프록시 주소를 지정해 CONNECT 방식으로 HTTPS 요청을 전달하기 때문입니다.

$env:HTTP_PROXY = "http://127.0.0.1:17890"
$env:HTTPS_PROXY = "http://127.0.0.1:17890"

macOS 또는 Linux의 sh, bash, zsh에서는 현재 터미널에서 다음을 실행하세요:

export http_proxy=http://127.0.0.1:17890
export https_proxy=http://127.0.0.1:17890

대문자 형태의 프록시 변수와 ALL_PROXY, all_proxy도 확인하세요. 도구마다 우선순위가 다를 수 있습니다. 셸 시작 파일, 시스템 환경 변수 또는 도구 자체 설정에 값이 저장되어 있다면 지속 설정도 업데이트해야 합니다. 임시 명령은 현재 프로세스와 이후에 실행되는 하위 프로세스에만 적용되며 이미 열려 있는 다른 터미널은 변경하지 않습니다.

TUN 모드는 트래픽을 가로채는 별도의 경로를 처리합니다. TUN을 켜도 7890 포트가 해제되지 않으며, 바인딩에 실패한 혼합 포트가 다시 수신을 시작하지도 않습니다. 로컬 포트를 확인할 때 TUN 전환을 해결책으로 사용하지 마세요.

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

노드 연결 문제를 포트 점유로 오인하지 않도록 세 단계로 확인하세요. 아래 명령은 확인 방법이며 응답 상태나 소요 시간을 미리 가정하지 않습니다.

수신 상태 확인. 앞에서 안내한 조회 명령에서 7890을 17890으로 바꾸고 PID와 프로세스 경로가 현재 클라이언트에 해당하는지 확인하세요.
프록시를 명시해 테스트. 시스템 프록시 자동 설정을 거치지 않고 새 로컬 포트에 직접 요청을 보내세요.
재시작 후 확인. 클라이언트를 정상 종료했다가 다시 열고 구독이나 오버라이드 설정으로 포트가 원래대로 돌아오지 않았는지 확인한 다음 브라우저와 자주 사용하는 터미널 도구를 테스트하세요.

Windows에서는 일부 PowerShell 환경의 curl 별칭으로 인한 인수 차이를 피하기 위해 curl.exe를 사용하세요:

curl.exe --noproxy "" --proxy http://127.0.0.1:17890 --connect-timeout 5 --max-time 20 -I https://clash15.com/

macOS 및 Linux에서는 다음 명령을 사용할 수 있습니다:

curl --noproxy "" --proxy http://127.0.0.1:17890 --connect-timeout 5 --max-time 20 -I https://clash15.com/

--noproxy ""는 기존 우회 목록 때문에 이번 테스트가 프록시를 거치지 않고 직접 연결되는 상황을 방지합니다. 대상 사이트에서 응답을 받으면 이번 요청이 어떤 경로로 처리됐는지 확인할 수 있지만, 모든 노드와 규칙이 정상이라는 뜻은 아닙니다. 로컬 연결 거부가 계속되면 먼저 수신 상태를 다시 확인하세요. 요청이 커널 로그에 기록된 뒤 DNS 오류나 원격 시간 초과가 발생한다면 해당 이름 확인, 규칙 또는 노드를 점검하세요.

수신 프로세스가 없는데도 포트 바인딩 오류가 발생하는 경우

먼저 오류가 발생하는 동시에 다시 조회해 백그라운드 인스턴스가 잠시 재시작한 경우를 제외하세요. Windows에서 액세스 권한 오류가 표시되면 시스템에서 제외한 TCP 포트 범위를 확인할 수 있습니다:

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

대상 포트가 제외 범위에 포함된다면 시스템 예약 항목을 직접 삭제하지 말고 범위 밖에서 사용 가능한 포트를 선택하세요. 가상화 및 네트워크 구성 요소가 해당 범위를 사용하고 있을 수 있습니다. 최종적으로 다음 네 가지를 확인해야 합니다. 예상한 인스턴스만 대상 포트에서 수신하고, 시작 로그에 바인딩 오류가 없으며, 앱이 새 포트를 사용하고, 클라이언트 재시작 후에도 설정이 유지되어야 합니다.

시스템 프록시와 모드 선택을 더 확인하려면 시스템 프록시 설정 방법을 참고하세요. 요청이 커널에 전달된 뒤 원격 연결 시간 초과가 발생하면 연결 시간 초과 문제 해결을 확인하세요. 먼저 로컬에서 포트 문제를 해결한 다음 구독과 연결 경로를 점검하세요.