Clash 포트 충돌 해결: 7890 사용 중인 프로세스 찾기와 mixed-port 변경
netstat과 lsof로 7890 등 포트를 점유한 프로세스를 찾고, mixed-port·socks-port·컨트롤 포트를 구분하세요. 포트를 바꾼 뒤 시스템 프록시도 함께 변경하면 됩니다.
먼저 로그에서 리스닝 충돌 확인
오류 포트 확인 → 리스닝 프로세스 조회 → 포트 해제 또는 변경 → 연결된 앱 설정 동기화 순서로 처리하세요. 7890은 Clash 설정에서 흔히 쓰이는 프록시 포트일 뿐, 반드시 사용해야 하는 값은 아닙니다. 사용 가능한 7893으로 바꾸면 충돌을 해결할 수 있지만, 클라이언트에 새 설정을 적용하고 브라우저·시스템 프록시·터미널도 새 포트를 사용하도록 바꿔야 합니다.
클라이언트 로그 화면에서 bind, listen, address already in use를 찾아보세요. 커널과 운영체제에 따라 오류 문구는 다를 수 있으므로, 메시지에 나온 주소·포트·프로토콜을 확인하는 것이 중요합니다. 예를 들어 다음 로그는 TCP 7890 리스닝에 실패했다는 뜻이며, 프록시 서버가 정상인지 여부까지 판단할 수는 없습니다.
listen tcp 127.0.0.1:7890: bind: address already in use127.0.0.1:7890: 로컬 루프백 주소의 7890 포트에서 리스닝합니다.0.0.0.0:7890: 모든 IPv4 인터페이스에서 리스닝을 시도합니다. 기존 루프백 리스너와 충돌할 수 있습니다.[::]:7890: IPv6 와일드카드 주소입니다. IPv4에도 영향을 주는지는 운영체제와 소켓 설정에 따라 다릅니다.connection refused: 대개 연결 대상이 리스닝하지 않거나 연결을 거부했다는 뜻이며, 포트 점유와는 다릅니다.
mixed-port와 컨트롤 포트 구분하기
Clash 클라이언트는 관리 화면이며, 실제 리스닝은 보통 커널 프로세스가 담당합니다. Clash Meta(현재 mihomo로 명칭 변경)를 사용하는 클라이언트도 마찬가지입니다. 화면의 ‘포트’는 여러 종류의 연결 지점을 가리킬 수 있으므로, 로그에 표시된 숫자를 기준으로 확인하세요. 7890이 보인다고 모든 항목을 일괄 변경하면 안 됩니다.
| 설정 항목 | 용도 | 변경 후 함께 수정할 설정 |
|---|---|---|
port | HTTP 프록시 연결 지점이며 HTTPS의 CONNECT 요청도 처리 | 시스템 HTTP 프록시 및 HTTP 프록시를 사용하는 도구 |
socks-port | SOCKS 프록시 연결 지점으로, SOCKS5 앱에서 주로 사용 | 앱 자체의 SOCKS5 설정 |
mixed-port | 하나의 연결 지점에서 HTTP와 SOCKS 프록시 요청을 모두 수신 | 해당 연결 지점을 가리키는 시스템 프록시·브라우저·터미널 |
external-controller | 커널 제어 API의 리스닝 주소 | 외부 대시보드 또는 클라이언트의 커널 연결 설정 |
예를 들어 mixed-port: 7890 하나로 HTTP와 SOCKS5 요청을 모두 처리할 수 있으므로 port와 socks-port까지 7890으로 설정할 필요는 없습니다. 여러 개의 독립 리스닝 항목에 같은 주소와 포트를 지정하면 설정 자체가 충돌할 수 있습니다. 혼합 연결 지점 하나만 필요하다면 클라이언트 지원 여부를 확인한 뒤 mixed-port만 남기고 사용하지 않는 독립 연결 지점은 제거하세요.
external-controller: 127.0.0.1:9090은 별도 서비스입니다. 시스템 프록시에 9090을 입력하면 안 됩니다. 이 값을 바꿔도 7890 프록시 리스닝 오류는 해결되지 않습니다. 컨트롤 포트는 관리 권한과 관련되므로 로컬 주소에 바인딩하고 기존 인증 설정을 유지하세요. 충돌을 확인한다는 이유로 로컬 네트워크에 함부로 공개하지 마세요.
Windows: netstat으로 프로세스 찾기
1단계: 리스닝 항목과 PID 확인
PowerShell 또는 명령 프롬프트를 열고 다음 명령을 실행하세요. 첫 번째 명령은 7890이 포함된 행을 찾고, 두 번째는 PowerShell에서 로컬 리스닝 포트를 정확히 조회합니다.
netstat -ano -p tcp | findstr ":7890"
powershell -NoProfile -Command "Get-NetTCPConnection -LocalPort 7890 -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess"netstat 결과에서 먼저 ‘로컬 주소’의 포트가 7890인지 확인한 다음 LISTENING 상태인 행을 찾으세요. 숫자가 포함된 행을 통째로 확인하면 원격 포트나 17890을 대상으로 착각할 수 있습니다. 마지막 열은 PID입니다. 예를 들어 PID가 6240이라면 다음 명령으로 프로세스 이름을 확인하세요.
tasklist /FI "PID eq 6240"6240은 명령 예시일 뿐이므로 실제 조회 결과로 바꿔야 합니다. 실행 파일 경로와 시작 인수를 확인하려면 PowerShell에서 추가로 조회할 수 있습니다. 다른 사용자의 프로세스 정보를 보려면 관리자 권한이 필요할 수 있습니다.
Get-CimInstance Win32_Process -Filter "ProcessId = 6240" |
Select-Object ProcessId, Name, ExecutablePath, CommandLine2단계: 프로세스에 따라 조치
- 다른 프록시 클라이언트: 트레이 메뉴에서 종료하고 백그라운드 커널도 완전히 종료됐는지 확인한 뒤 사용할 클라이언트를 실행하세요.
- 같은 클라이언트의 잔여 커널: 먼저 클라이언트를 정상 종료하고 포트를 다시 확인하세요. 프로세스 경로와 소속을 확인한 다음 작업 관리자에서 남은 프로세스를 종료하세요.
- 유지해야 하는 로컬 서비스: 강제로 종료하지 말고 사용 가능한 프록시 포트로 변경하세요.
- 알 수 없는 프로세스 또는 시스템 서비스: 경로와 서비스 출처를 먼저 확인하세요. PID만 보고 강제 종료 명령을 실행하지 마세요.
리스닝 항목은 없는데 ‘액세스 권한으로 허용되지 않는 방식으로 소켓에 액세스하려 했습니다’라는 오류가 난다면, 포트 예약 문제와 권한 문제를 구분해야 합니다. netsh interface ipv4 show excludedportrange protocol=tcp를 실행해 TCP 제외 포트 범위를 확인하세요. 후보 포트가 범위에 포함되면 범위 밖의 사용 가능한 포트로 바꾸는 것이 우선이며, 시스템 예약 항목을 함부로 삭제하지 마세요.
macOS·Linux: lsof와 ss로 확인
macOS: TCP 리스닝만 조회
터미널에서 다음 명령을 실행하세요. -nP는 주소와 포트를 숫자로 표시하고, -sTCP:LISTEN은 리스닝 상태만 표시해 일반 연결을 제외합니다. 다른 사용자의 프로세스를 확인해야 할 때만 sudo를 사용하세요.
lsof -nP -iTCP:7890 -sTCP:LISTEN
sudo lsof -nP -iTCP:7890 -sTCP:LISTEN출력에서 COMMAND, PID, NAME을 확인하세요. 점유 프로세스가 다른 클라이언트라면 메뉴 막대에서 먼저 종료하세요. 종료한 뒤 곧바로 다시 나타난다면 로그인 시 자동 실행, 백그라운드 서비스 또는 자동 재시작이 설정되어 있는지 확인하세요.
Linux: TCP와 UDP 구분하기
sudo ss -ltnp 'sport = :7890'
sudo ss -lunp 'sport = :7890'
# lsof가 설치되어 있다면 TCP 리스닝도 확인할 수 있습니다
sudo lsof -nP -iTCP:7890 -sTCP:LISTENss의 -t는 TCP, -u는 UDP를 조회하고 -p는 프로세스 정보를 표시합니다. TCP와 UDP는 포트 공간이 서로 다릅니다. UDP 7890이 사용 중이라고 해서 TCP 바인딩 실패의 원인이라고 단정할 수는 없습니다. 로그에 표시된 프로토콜에 맞춰 각각 확인하세요.
mihomo를 systemd로 관리한다면 데스크톱 창을 닫아도 서비스가 중지되지 않을 수 있습니다. 서비스 이름이 실제로 mihomo.service라면 systemctl status mihomo.service로 상태를 확인한 뒤, 중지해야 하는 경우 sudo systemctl stop mihomo.service를 실행하세요. 서비스 이름이 다르면 설치할 때 사용한 이름을 기준으로 확인해야 합니다. 그렇지 않으면 커널이 이미 중지됐다고 잘못 판단할 수 있습니다.
mixed-port 변경하기: 7893 예시
먼저 앞서 사용한 조회 명령에서 7890을 7893으로 바꾸고 해당 포트에 충돌이 없는지 확인하세요. 7893이 모든 컴퓨터에서 사용 가능하다는 보장은 없습니다. 여기서는 설정 예시로 사용한 값입니다. 포트를 바꿀 때는 클라이언트가 실제로 불러오는 설정을 수정해야 합니다. 적용되지 않은 YAML 파일만 편집해서는 안 됩니다.
- 클라이언트의 현재 설정이나 실행 설정에서 ‘혼합 포트’, ‘Mixed Port’ 또는
mixed-port를 찾으세요. 메뉴 이름은 클라이언트마다 다를 수 있으므로 실제 항목을 기준으로 확인하세요. - YAML로 관리한다면 최상위 항목을 수정하고 공백으로 들여쓰기하세요.
proxies나proxy-groups안에 포트를 넣으면 안 됩니다. - 클라이언트에 포트를 덮어쓰는 설정이 따로 있는지 확인하세요. 구독 설정, 오버라이드 설정, 실행 설정이 함께 최종 값을 결정할 수 있습니다.
- 설정을 저장하고 적용하세요. 클라이언트에서 커널을 다시 시작하라는 메시지가 나오면 재시작을 마친 뒤 로그와 리스닝 상태를 확인하세요.
아래 내용은포트 관련 설정 예시이며, 전체 구독 설정이 아닙니다. 별도의 SOCKS 연결 지점이 필요한 앱이 있다면 다른 포트를 사용할 수 있습니다.
# 기존 설정의 최상위 항목에 추가하고, 다른 프록시·정책 그룹·규칙은 유지하세요
mixed-port: 7893
socks-port: 7894
allow-lan: false
# 제어 API와 프록시 연결 지점을 분리하고, 기존 인증 설정은 유지하세요
external-controller: 127.0.0.1:9090혼합 포트만 사용한다면 예시를 위해 socks-port를 추가할 필요는 없습니다. 기존 설정에 port: 7890이 남아 있다면 mixed-port만 바꿔도 독립 HTTP 연결 지점에서 오류가 계속 날 수 있으므로 모든 리스닝 항목을 하나씩 확인하세요.
시스템 프록시·브라우저·터미널 설정 동기화
포트를 바꾼 뒤 흔히 발생하는 문제는 커널이 7893에서 리스닝하는데 앱은 여전히 7890으로 요청을 보내는 것입니다. 이때 구독을 다시 가져와도 해결되지 않으므로 트래픽이 유입되는 설정을 확인해야 합니다.
| 사용 위치 | 확인할 설정 | 이 예시의 목표값 |
|---|---|---|
| Windows 11 | ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’ → ‘수동 프록시 설정’ | 주소 127.0.0.1, 포트 7893 |
| macOS | ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’ | 활성화한 HTTP·HTTPS·SOCKS 항목에 맞춰 포트 동기화 |
| 브라우저의 개별 프록시 설정 | 확장 프로그램 또는 브라우저에 저장된 프록시 프로필 | 프로토콜은 그대로 두고 포트를 7893으로 변경 |
| 명령줄 도구 | 환경 변수, Git 설정, 도구 실행 인수 | 7890을 참조하는 설정을 정리 |
클라이언트가 시스템 프록시를 자동으로 관리한다면 새 포트를 적용한 뒤 클라이언트의 ‘시스템 프록시’ 스위치를 껐다가 다시 켜고 시스템 설정을 확인하세요. PAC 자동 설정을 사용하는 환경에서는 PAC가 반환하는 프록시 주소를 확인해야 합니다. 수동 프록시 입력란을 바꿔도 PAC 경로에는 반영되지 않을 수 있습니다.
터미널 환경 변수 설정 예시
macOS 또는 Linux의 현재 셸에서는 다음과 같이 HTTP 프록시를 설정할 수 있습니다. https_proxy 값에 http://를 사용하는 것은 HTTP 프록시의 CONNECT 방식으로 HTTPS 사이트에 접속한다는 뜻이며, 대상 웹사이트가 암호화되지 않는다는 의미는 아닙니다.
export http_proxy=http://127.0.0.1:7893
export https_proxy=http://127.0.0.1:7893
# SOCKS5가 필요하고 도구에서 지원하는 경우 별도로 사용하세요:
export all_proxy=socks5h://127.0.0.1:7893이 명령은 현재 셸과 이후에 실행되는 하위 프로세스에만 적용되며, 이미 실행 중인 앱 설정은 자동으로 바뀌지 않습니다. HTTP와 SOCKS 변수를 모두 설정했을 때의 우선순위는 도구마다 다릅니다. 문제를 확인할 때는 프록시를 명시적으로 지정해 여러 설정이 결과에 영향을 주지 않도록 하세요. HTTP_PROXY, HTTPS_PROXY 같은 대문자 변수와 셸 시작 파일에 남은 이전 값도 확인해야 합니다.
TUN 모드는 다른 트래픽 경로를 처리하므로 로컬 프록시 연결 지점의 바인딩 충돌을 자동으로 해결하지 않습니다. 앱이 TUN을 통해 정상적으로 인터넷에 연결되어도 7890 리스닝은 실패할 수 있습니다. 반대로 잘못된 프록시를 명시적으로 설정하면 정상적인 전달 경로에 도달하기 전에 연결이 실패할 수도 있습니다. 두 상황은 따로 확인해야 합니다.
수정 확인: 리스닝·요청·재시작
- 리스닝 확인: 7893을 다시 조회해 PID가 예상한 커널 프로세스인지 확인하고, 로그에 해당 연결 지점의 바인딩 오류가 더 이상 없는지 살펴보세요.
- 프록시 요청 확인: 시스템 프록시나 브라우저 설정에 의존하지 말고 프록시를 명시한 인수로 요청을 한 번 보내세요.
- 일반 앱 확인: 브라우저와 실제 사용하는 도구를 열어 이전 포트를 계속 참조하는지 확인하세요.
- 설정 유지 확인: 클라이언트를 재시작하고 구독도 한 번 업데이트해 포트가 덮어써지지 않는지, 다른 클라이언트가 먼저 자동 실행되지 않는지 확인하세요.
아래 명령은 새 혼합 포트를 통해 HTTP 프록시 요청을 보냅니다. Windows에서는 curl.exe를 사용해 일부 PowerShell 환경에서 같은 이름의 명령 별칭 때문에 발생하는 차이를 피할 수 있습니다.
# macOS / Linux
curl --noproxy "" --proxy http://127.0.0.1:7893 --connect-timeout 5 --max-time 15 -I https://clash03.com/
# Windows
curl.exe --noproxy "" --proxy http://127.0.0.1:7893 --connect-timeout 5 --max-time 15 -I https://clash03.com/HTTP 응답을 받았다면 해당 요청에 응답이 도착했다는 뜻이지만, 반드시 원격 프록시 노드를 거쳤다는 의미는 아닙니다. 규칙 모드에서는 대상이 직접 연결 규칙에 해당할 수 있습니다. Failed to connect가 표시되면 먼저 로컬 리스닝과 포트를 확인하세요. 로컬 프록시가 연결을 수락한 뒤 업스트림 시간 초과나 TLS 오류가 발생한다면 노드·DNS·규칙·네트워크 환경을 확인하고, 로컬 포트를 계속 바꾸지는 마세요.
남아 있는 문제 확인
- 종료 후에도 포트가 사용 중: 백그라운드 서비스, 다른 사용자 세션, 클라이언트의 잔여 커널을 확인하세요.
- 변경 직후 이전 값으로 복원: 포트 오버라이드 기능과 구독 업데이트 동작을 확인하고 현재 활성화된 설정을 수정했는지 살펴보세요.
- 포트가 비어 있는데도 시작 실패: 권한, 시스템 제외 포트, 잘못된 바인딩 주소, YAML 구문 오류를 구분하고 새 로그에 따라 확인하세요.
- 대시보드는 오프라인인데 웹은 정상: 컨트롤 API의 주소·포트·인증 설정을 별도로 확인하세요. 프록시 연결 지점을 대시보드 API로 착각하지 마세요.
문제 해결 후에는 평소 사용할 프록시 클라이언트 하나만 자동 실행되도록 설정하고 ‘혼합 포트 7893, 독립 SOCKS 포트 사용 여부, 컨트롤 포트 9090’ 등 실제 설정을 기록해 두는 것이 좋습니다. 다시 충돌이 발생하면 클라이언트를 반복해서 재설치하기보다 리스닝 프로세스부터 확인하는 편이 원인을 찾기 쉽습니다. 각 항목의 자세한 설명은 전체 설정 안내에서 확인하고, 설치와 첫 실행 방법은 빠른 시작 가이드를 참고하세요.