먼저 오류 확인: 포트 충돌인가, 바인딩 권한 문제인가
Clash 화면이 열려도 프록시 엔진이 정상적으로 포트를 열었다는 뜻은 아닙니다. 로그에 listen tcp 127.0.0.1:7890: bind와 함께 “일반적으로 각 소켓 주소는 한 번만 사용할 수 있습니다” 또는 Only one usage of each socket address가 표시되면, 같은 주소와 포트를 이미 다른 프로세스가 사용 중일 가능성이 큽니다. 이때 시스템 프록시 스위치를 반복해서 눌러도 포트는 비워지지 않습니다.
7890은 흔히 사용하는 로컬 프록시 포트지만, 모든 클라이언트가 반드시 사용해야 하는 고정값은 아닙니다. 실제 포트는 현재 적용된 설정과 엔진 로그를 기준으로 확인하세요. HTTP 포트, SOCKS 포트, 혼합 포트, 컨트롤 인터페이스 포트는 용도가 다르므로 숫자가 비슷하다고 서로 바꿔 쓸 수는 없습니다.
| 로그 또는 증상 | 우선 확인할 사항 |
|---|---|
| 주소가 이미 사용 중, Only one usage | 포트를 수신 대기 중인 프로세스를 찾고 엔진이 두 개 실행 중인지 확인합니다. |
| 액세스 권한이 허용되지 않음, forbidden by its access permissions | Windows 제외 포트 범위, 시스템 정책, 보안 프로그램의 제한을 확인합니다. |
| 엔진은 정상적으로 포트를 열었지만 브라우저 연결이 거부됨 | 브라우저 또는 시스템 프록시가 이전 포트를 가리키는지 확인합니다. |
| 로그에 9090 등 다른 포트 오류가 표시됨 | 로그에 나온 실제 포트를 기준으로 확인하고 mixed-port만 변경하지 마세요. |
netstat으로 7890 포트를 사용하는 프로세스 찾기
1단계: TCP 수신 대기 항목 필터링
Windows 터미널에서 PowerShell 또는 명령 프롬프트를 열고 아래 명령을 실행하세요. 일반 권한으로도 보통 수신 대기 포트를 확인할 수 있습니다. 권한 오류가 나타나면 터미널을 관리자 권한으로 다시 여세요.
netstat -ano -p tcp | findstr LISTENING | findstr ":7890 "-a는 연결과 수신 대기 포트를 표시하고, -n은 주소를 숫자로 표시하며, -o는 PID를 표시합니다. 필터 문자열에서 7890 뒤에 공백을 둬 78900 같은 포트가 포함되지 않도록 했습니다. 아래는 출력 형식 예시이며, 마지막 열의 12480은 설명을 위한 숫자입니다.
TCP 127.0.0.1:7890 0.0.0.0:0 LISTENING 12480127.0.0.1:7890은 IPv4 루프백 주소에서만 수신 대기한다는 뜻입니다.0.0.0.0:7890은 모든 로컬 IPv4 주소에서 수신 대기한다는 뜻으로, 루프백 주소의 수신 대기와 충돌할 수 있습니다.[::]:7890은 IPv6 와일드카드 주소에서 수신 대기한다는 뜻입니다. 충돌 여부는 실제 소켓 설정을 함께 확인해야 합니다.- 같은 PID가 여러 줄에 표시되어도 반드시 여러 프로그램이 실행 중인 것은 아닙니다. 하나의 프로세스가 여러 주소에서 수신 대기할 수 있습니다.
2단계: PID로 프로그램 확인
Ctrl + Shift + Esc를 눌러 작업 관리자를 열고 ‘세부 정보’에서 PID로 해당 프로세스를 찾으세요. PID가 보이지 않으면 열 제목을 마우스 오른쪽 버튼으로 클릭해 해당 열을 표시하면 됩니다. 대상 프로세스를 마우스 오른쪽 버튼으로 클릭하고 ‘파일 위치 열기’를 선택해 어떤 클라이언트나 서비스에 속하는지 확인하세요.
tasklist /FI "PID eq 12480"명령을 실행할 때 예시 숫자를 앞서 확인한 실제 PID로 바꾸세요. 흔한 원인은 이전 클라이언트가 시스템 트레이에서 계속 실행 중이거나, 다른 클라이언트가 이미 시작되었거나, 서비스 모드의 엔진이 종료되지 않은 경우입니다. 프로세스 이름에 Clash나 mihomo가 포함되어 있다는 이유만으로 종료하지 말고 경로와 소속 클라이언트를 먼저 확인하세요.
PowerShell로 대체 확인하기
Get-NetTCPConnection -LocalPort 7890 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess출력의 OwningProcess가 PID입니다. 수신 대기 항목이 반환되지 않으면 당시 로그도 함께 확인하세요. 실행 직후 종료된 엔진은 조회 전에 포트를 이미 해제했을 수 있습니다.
충돌 해결: 중복 클라이언트 종료 또는 빈 포트 사용
포트를 점유한 프로그램이 더 이상 사용하지 않는 다른 클라이언트라면 시스템 트레이 메뉴에서 정상 종료하는 것이 우선입니다. 독립 서비스가 실행 중인 경우 창을 닫아도 화면만 숨겨지고 엔진은 계속 작동할 수 있습니다. 해당 클라이언트의 서비스 관리 메뉴에서 서비스를 중지한 뒤 포트를 다시 확인하세요.
- 기존 시스템 프록시 주소와 포트를 기록한 다음 시스템 프록시를 잠시 끄세요. 문제를 확인하는 동안 앱이 작동하지 않는 프록시 주소에 계속 접속하는 일을 막을 수 있습니다.
- 중복 클라이언트를 정상 종료하고, 필요한 경우
services.msc에서 관련 서비스를 확인하세요. - netstat을 다시 실행해 이전 수신 대기 항목이 사라졌는지 확인합니다.
- 계속 사용할 클라이언트를 실행하고 로그에서 7890 포트가 정상적으로 열렸는지 확인합니다.
포트를 점유한 프로그램을 계속 사용해야 한다면 강제로 종료할 필요는 없습니다. Clash 포트를 비어 있는 다른 포트로 바꾸는 편이 간단합니다. 이 글에서는 7897을 예로 들지만 모든 PC에서 사용할 수 있다고 보장할 수는 없으므로 변경 전에 확인하세요.
netstat -ano -p tcp | findstr LISTENING | findstr ":7897 "mixed-port 변경: 로컬 프록시 접속 포트 바꾸기
mixed-port는 하나의 로컬 수신 포트에서 HTTP와 SOCKS 프록시 연결을 모두 받습니다. 노드 서버 포트나 구독 링크 포트가 아닙니다. 설정에 있는 프록시 노드의 port는 원격 연결용 값이므로, 로컬 7890 포트의 수신 충돌을 해결하는 데 사용할 수 없습니다.
먼저 클라이언트가 실제로 사용하는 설정 파일 확인
클라이언트마다 포트 설정 메뉴와 저장 방식이 다릅니다. 설정에서 ‘포트’, ‘혼합 포트’ 또는 mixed-port를 찾아보세요. 그래픽 설정 메뉴가 있다면 우선 그곳에서 변경하는 것이 좋습니다. mihomo 엔진을 사용하는 클라이언트는 오버라이드, 설정 병합 또는 실행 중 설정 관리로 포트를 지정할 수도 있습니다. 구독 캐시 파일을 직접 편집하면 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다.
YAML을 편집해야 한다면 먼저 원본 파일을 백업하고, 적용 중인 설정에서 기존 mixed-port 값을 원하는 포트로 변경하세요. 아래는 수정할 필드만 보여 주는 예시입니다. 전체 설정 파일이 아니므로 구독 설정 전체를 덮어쓰는 데 사용하지 마세요.
mixed-port: 7897- 이 필드는 YAML 최상위에 두고
proxies,proxy-groups또는rules목록 안에는 넣지 마세요. - 최종 적용 설정에
mixed-port키가 중복으로 들어가지 않도록 하세요. port: 7890또는socks-port: 7890도 활성화되어 있다면 기존 포트 충돌이 계속될 수 있으므로 각 수신 포트를 따로 확인해야 합니다.external-controller는 클라이언트가 엔진을 관리하는 컨트롤 인터페이스입니다. 브라우저 프록시 포트로 사용하면 안 됩니다.
설정 다시 불러온 뒤 수신 상태 확인
저장한 뒤 클라이언트의 설정 다시 불러오기 또는 엔진 재시작 기능을 사용하세요. 파일만 저장하고 다시 불러오지 않으면 이전 프로세스가 기존 포트를 계속 사용할 수 있습니다. 이어서 로그를 확인하고 7897을 다시 조회하세요. 대상 엔진의 PID가 해당 포트에서 수신 대기 중이어야 합니다. 화면에는 7897이 표시되는데 로그에는 여전히 7890이 나온다면, 설정이 덮어써졌는지 또는 수정한 설정 파일이 실제로 활성화되어 있는지 먼저 확인하세요.
Windows 시스템 프록시와 앱별 프록시 동기화
포트 변경 후 모든 클라이언트에서 시스템 프록시가 자동으로 동기화되는 것은 아닙니다. 엔진은 7897에서 수신 대기하는데 Windows가 127.0.0.1:7890을 가리키면 브라우저에서 프록시 연결 오류가 발생할 수 있습니다. 새 포트가 정상적으로 열린 것을 확인한 뒤 클라이언트의 시스템 프록시 기능을 다시 켜고 Windows에 저장된 주소도 확인하세요.
- Windows 11: ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’ → ‘수동 프록시 설정’ → ‘프록시 서버 사용’ 옆의 ‘설정’을 선택합니다.
- Windows 10: ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 수동 프록시 설정을 확인합니다.
- 주소는
127.0.0.1로 설정하고 포트는 현재 혼합 포트와 일치시킵니다. 이 예시에서는7897입니다. 프록시 스크립트를 사용하는 경우 스크립트가 실제로 반환하는 프록시 주소도 확인하세요.
Firefox, 개발 도구, Git, 터미널 환경 변수에는 별도의 프록시 설정이 있을 수 있으며 Windows 설정을 따르지 않을 수 있습니다. 터미널에서 현재 세션의 프록시 변수를 먼저 확인할 수 있습니다.
Get-ChildItem Env: | Where-Object Name -Match 'proxy'결과가 여전히 7890을 가리키면 해당 앱이나 변수의 설정도 변경해야 합니다. 아래 두 줄은 현재 PowerShell 세션에만 적용됩니다. 이미 열려 있는 다른 터미널이나 모든 프로그램의 설정까지 자동으로 바꾸지는 않습니다.
$env:HTTP_PROXY = 'http://127.0.0.1:7897'
$env:HTTPS_PROXY = 'http://127.0.0.1:7897'HTTPS_PROXY에 http://를 사용하는 것은 로컬 HTTP 프록시를 통해 터널을 연결한다는 뜻이지, 대상 HTTPS 사이트를 HTTP로 낮춘다는 뜻이 아닙니다. 문제를 확인하는 동안 WinHTTP 초기화 명령을 함부로 실행하지 마세요. WinHTTP 프록시와 브라우저가 주로 사용하는 Windows 사용자 프록시 설정은 서로 다른 설정입니다.
포트를 수신하는 프로세스가 없는데도 바인딩되지 않는 경우
netstat에서 점유 프로세스를 찾을 수 없는데 로그에 “액세스 권한이 허용되지 않습니다”라고 표시된다면, 관리자 권한 터미널에서 Windows의 TCP 제외 포트 범위를 확인하세요. Hyper-V, WSL, 컨테이너 또는 다른 네트워크 구성 요소가 예약된 범위에 영향을 줄 수 있지만, 특정 기능이 설치되어 있다는 이유만으로 원인이라고 단정할 수는 없습니다.
netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp출력된 시작 포트와 끝 포트 사이에 7890 또는 사용하려는 7897이 포함되는지 확인하세요. 범위에 포함된다면 해당 범위 밖에 있고 수신 중인 프로세스도 없는 포트를 우선 선택하세요. 프록시 포트 하나를 비우려고 시스템 예약 범위를 직접 삭제하지 마세요. 가상 네트워크 서비스에 영향을 줄 수 있습니다.
로그에 표시된 프로토콜과 주소 확인
이 글에서는 주로 TCP 프록시 수신 문제를 다룹니다. 오류에 UDP가 명시되어 있다면 TCP의 LISTENING만 확인하지 말고 해당 UDP 엔드포인트를 확인하세요. UDP 출력에는 같은 수신 상태 열이 없으며, 다음과 같이 조회할 수 있습니다.
netstat -ano -p udp | findstr ":7890 "로그에 더 이상 존재하지 않는 로컬 네트워크 주소에 바인딩한다고 표시되면 bind-address도 확인해야 합니다. 로컬에서만 사용할 경우 오류를 피하려고 무작정 로컬 네트워크 접근을 허용하지 마세요. allow-lan을 활성화하면 접근 범위가 달라지며, 로컬 포트 충돌을 해결하는 것과는 별개의 설정입니다.
복구 여부 확인: 수신 포트, 프록시 입구, 외부 연결 점검
웹페이지가 다시 열린 것만으로 모든 설정이 동기화됐다고 볼 수는 없습니다. 아래 세 단계로 확인하면 포트, 프록시 규칙, 노드 연결 문제를 더 빠르게 구분할 수 있습니다.
- 수신 확인: 7897을 조회하고 PID가 대상 클라이언트의 엔진인지 확인합니다. 로그에 바인딩 실패가 더 이상 표시되지 않아야 합니다.
- 프록시 입구 확인: 프록시를 명시적으로 지정한 요청으로 시스템 프록시 설정을 우회해 로컬 접속을 테스트합니다.
- 외부 연결 확인: 클라이언트의 연결 기록에서 요청에 적용된 규칙, 정책 그룹, 실제 출구를 확인해 예상한 경로인지 점검합니다.
curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7897 https://www.microsoft.com/위 명령은 로컬 HTTP 프록시에 직접 연결합니다. 127.0.0.1:7897에 연결할 수 없다는 메시지가 바로 나타나면 수신 상태와 포트를 계속 확인하세요. 프록시 연결은 되었지만 대상 요청이 시간 초과되면 노드 상태, DNS, 규칙 또는 원격 네트워크를 점검해야 합니다. HTTP 응답을 받았다고 요청이 반드시 프록시 노드를 거친 것은 아닙니다. Rule 모드에서는 대상에 직접 연결될 수 있으므로 연결 기록을 기준으로 판단하세요.
마지막으로 브라우저와 프록시가 필요한 앱을 다시 열고 클라이언트도 한 번 재시작해 포트 설정이 유지되는지 확인하세요. 재시작하거나 구독을 업데이트할 때마다 7890으로 돌아간다면 임시 파일을 계속 수정하는 대신 클라이언트의 영구 설정이나 오버라이드 설정을 바로잡아야 합니다. TUN 모드는 포트를 해제하는 기능이 아닙니다. 일부 트래픽이 가상 네트워크 어댑터를 거치더라도 작동하지 않는 로컬 HTTP 프록시 주소는 별도로 수정해야 합니다.