Clash 시스템 프록시를 켰는데 작동하지 않을 때: 브라우저와 터미널별 점검

명시적 프록시 요청으로 문제 발생 구간 확인하기

‘시스템 프록시’를 켜면 클라이언트가 운영체제 설정에 프록시 주소를 기록하려고 합니다. 그렇다고 모든 앱이 해당 설정을 사용하는 것은 아닙니다. mihomo 커널이 실행 중인지, 앱이 로컬 포트에 연결하는지, 규칙이 프록시 노드를 선택하는지는 각각 별도로 확인해야 합니다. 먼저 브라우저 설정을 거치지 않는 명시적 프록시 테스트를 한 뒤 브라우저와 터미널을 따로 점검하세요.

아래 예시에서는 로컬 혼합 포트 7890을 사용합니다. 먼저 클라이언트의 포트 설정이나 현재 적용 중인 구성에서 실제 포트 번호를 확인하세요. 이 예시 포트가 모든 Clash 클라이언트의 기본값은 아닙니다. Windows PowerShell에서는 curl이 다른 명령으로 해석되는 구버전 문제를 피하려면 curl.exe를 사용하세요.

# macOS / Linux
curl --noproxy "" -x http://127.0.0.1:7890 -I --connect-timeout 10 --max-time 20 https://example.com

# Windows PowerShell
curl.exe --noproxy "" -x http://127.0.0.1:7890 -I --connect-timeout 10 --max-time 20 https://example.com

• 연결이 거부됨: 먼저 커널 실행 여부, 수신 대기 포트, 포트를 사용하는 프로세스를 확인하세요. DNS부터 바꿀 필요는 없습니다.
• 로컬 프록시에 연결되지만 이후 요청이 시간 초과됨: 클라이언트 연결 기록, 일치한 규칙, 정책 그룹과 노드를 확인하세요.
• 사이트에서 HTTP 응답을 받음: 해당 대상으로 명시적 프록시 요청이 완료된 것입니다. 규칙에서 DIRECT가 선택된 것이 아니라 실제 프록시를 통해 나갔는지도 확인하세요.

포트, 커널, 프로세스 점유 상태 확인

구독을 가져오는 데 성공한 것과 로컬 프록시가 포트에서 대기하는 것은 별개입니다. 클라이언트 화면은 정상적으로 열려도 구성 오류로 커널이 종료될 수 있으며, 다른 프록시 프로그램이 먼저 포트를 점유했을 수도 있습니다. 현재 구성이 활성화되어 있는지 확인한 다음 커널 시작 로그에서 수신 대기 정보를 살펴보세요.

구성 항목 확인

# 로컬 수신 대기 예시이며, 연결 가능한 전체 구성은 아닙니다
mixed-port: 7890
allow-lan: false
mode: rule

mixed-port는 하나의 포트에서 HTTP와 SOCKS 프록시 요청을 모두 받습니다. 포트를 분리해 사용한다면 port는 HTTP 프록시, socks-port는 SOCKS 프록시용입니다. 두 항목을 혼동하지 마세요. 위 예시에는 노드, 정책 그룹, 규칙이 없어 구독을 대신할 수 없습니다. GUI 클라이언트는 재정의를 적용해 실행 구성을 생성할 수도 있으므로 최종 적용값을 기준으로 확인하세요.

7890 포트를 수신 대기 중인 프로세스 확인

# Windows PowerShell: 수신 대기 PID 확인
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOS: 프로세스 이름 및 PID 확인
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux: 수신 주소와 프로세스 정보 확인. 일부 정보는 권한이 필요합니다
ss -lntp 'sport = :7890'

Windows에서는 조회한 PID를 Get-Process -Id 1234에 입력해 확인할 수 있습니다. 여기서 1234는 예시입니다. 해당 프로세스가 이전 클라이언트라면 기존 프로그램을 정상적으로 종료한 뒤 현재 커널을 실행하세요. 용도를 확인하지 못한 시스템 프로세스를 강제 종료하지 마세요. 수신 대기 결과가 없다면 로그에서 구성 파싱 오류, 포트 바인딩 실패, 커널 종료 원인을 확인하세요.

로컬 요청에 localhost를 사용한다면 IPv6 루프백 주소인 ::1로 해석될 수 있다는 점도 확인하세요. 커널은 IPv4에서만 수신 대기 중일 수 있습니다. 문제를 진단할 때는 먼저 127.0.0.1로 고정해 주소와 수신 대기 상태를 일치시키세요.

브라우저 점검: 시스템 설정, 확장 프로그램, PAC

명시적 프록시는 작동하지만 브라우저에서 연결되지 않는다면 브라우저가 어떤 프록시 설정을 사용하는지 확인해야 합니다. 브라우저와 데스크톱 환경, 기업 정책에 따라 동작이 다를 수 있으므로 클라이언트 스위치 색상만 보고 판단하지 마세요.

1. Windows 11: ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’로 이동하세요. ‘프록시 서버 사용’의 주소와 포트를 확인하고 ‘설정 스크립트 사용’이 켜져 있는지도 기록하세요.
2. macOS: ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’로 이동하세요. 웹 프록시, 보안 웹 프록시, 자동 프록시 구성을 확인하세요.
3. Chrome: 주소창에 chrome://settings/system을 입력해 컴퓨터의 프록시 설정을 여세요. 그런 다음 chrome://extensions에서 프록시를 제어할 수 있는 확장 프로그램을 확인하세요.
4. Firefox: ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’으로 이동하세요. ‘시스템 프록시 설정 사용’을 선택하거나 커널과 일치하는 HTTP 및 HTTPS 프록시 주소를 직접 입력하세요.

중복 제어를 먼저 제거하고 PAC 확인하기

프록시 전환 확장 프로그램이 시스템 설정을 덮어쓸 수 있습니다. 관련 확장 프로그램을 잠시 사용 중지하고 브라우저를 완전히 종료한 뒤 다시 열어 클라이언트 연결 목록을 확인하세요. 확장 프로그램이 시크릿 창에서도 실행되도록 허용된 경우에는 시크릿 창을 사용해도 영향을 배제할 수 없습니다.

PAC는 요청 URL에 따라 프록시 또는 직접 연결을 선택하는 스크립트이지, ‘모든 트래픽을 프록시로 보내는’ 스위치가 아닙니다. 예를 들어 스크립트가 DIRECT를 반환하면 브라우저는 로컬 프록시에 연결하지 않습니다. 문제를 진단할 때는 기존 설정을 기록하고 제어 방식 하나만 임시로 남겨 자동 스크립트, 수동 프록시, 확장 프로그램 규칙이 겹치지 않게 하세요. 조직 정책으로 관리되는 기기라면 관리자가 배포한 설정을 삭제하지 말고 먼저 관리자에게 문의하세요.

Windows에서는 PowerShell에서 다음 명령을 실행해 현재 사용자에게 적용된 일부 프록시 설정을 확인할 수 있습니다. 이 결과는 설정 출처를 파악하는 데 참고할 수 있지만, 모든 브라우저가 최종적으로 이 설정을 사용한다는 뜻은 아닙니다.

Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
  Select-Object ProxyEnable, ProxyServer, AutoConfigURL

netsh winhttp show proxy는 WinHTTP 프록시 구성을 표시합니다. 이 결과만으로 Chrome이 사용하는 시스템 프록시가 켜져 있거나 꺼져 있다고 단정할 수는 없습니다. 두 설정을 혼동하면 ‘명령에서는 직접 연결로 나오는데 브라우저는 프록시를 사용한다’는 상황을 잘못 판단하기 쉽습니다.

터미널 점검: 프록시 환경 변수 직접 설정

대부분의 명령줄 도구는 데스크톱 시스템 프록시를 자동으로 사용하지 않습니다. 브라우저에서 사이트에 접속되더라도 터미널의 curl, Git, 패키지 관리자가 실패할 수 있습니다. 전역 설정을 바로 바꾸지 말고 먼저 임시 환경 변수로 테스트하세요. 정상 작동을 확인한 뒤 셸 시작 파일에 저장할지 결정하면 됩니다.

macOS 및 Linux: 현재 셸 세션

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1

curl -I --connect-timeout 10 --max-time 20 https://example.com

# 기존 설정이 남아 있는지 확인
env | grep -iE '^(http|https|all|no)_proxy='

https_proxy라는 변수 이름은 대상 URL의 프로토콜을 나타낼 뿐, 변수 값이 https://로 시작해야 한다는 뜻은 아닙니다. 로컬 HTTP 프록시에 연결할 때는 http://127.0.0.1:7890을 사용합니다. HTTPS 요청은 CONNECT로 터널을 만듭니다. 프로토콜을 HTTPS로 바꾸면 오히려 로컬 포트에서 지원하지 않는 TLS 프록시 서비스를 요구할 수 있습니다.

보안상의 이유로 curl은 대문자 HTTP_PROXY를 HTTP 프록시 변수로 사용하지 않습니다. 소문자 표기를 사용하는 편이 안전합니다. 다른 프로그램은 대소문자 처리 방식이 다를 수 있습니다. 대문자 변수나 all_proxy가 이미 설정되어 있다면 이전 포트가 계속 사용되지 않도록 함께 확인하세요.

Windows PowerShell: 현재 프로세스와 자식 프로세스

$env:http_proxy = "http://127.0.0.1:7890"
$env:https_proxy = "http://127.0.0.1:7890"
$env:no_proxy = "localhost,127.0.0.1,::1"

curl.exe -I --connect-timeout 10 --max-time 20 https://example.com
Get-ChildItem Env: | Where-Object Name -Match 'proxy'

이 설정은 현재 PowerShell과 이후 실행되는 자식 프로세스에만 적용되며, 이미 실행 중인 편집기나 다른 터미널이 자동으로 변경되지는 않습니다. Windows Terminal에서 먼저 열어 둔 다른 탭에도 설정이 동기화된다고 볼 수 없습니다. WSL, 컨테이너, 원격 SSH 세션은 각각 별도의 환경이므로 그 안의 127.0.0.1이 호스트 컴퓨터의 프록시를 가리키지 않을 수 있습니다. 이 문제를 해결하겠다며 프록시를 모든 네트워크 인터페이스에 개방하지 마세요.

임시 환경 설정 되돌리기

# macOS / Linux
unset http_proxy https_proxy all_proxy no_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

# Windows PowerShell
Remove-Item Env:http_proxy, Env:https_proxy, Env:all_proxy, Env:no_proxy -ErrorAction SilentlyContinue

기존에 회사 프록시를 사용했다면 기록해 둔 원래 값을 복원하세요. 무조건 비우면 안 됩니다. 현재 셸을 닫아도 이번에 임시로 변경한 설정은 사라집니다. ~/.zshrc, ~/.bashrc 또는 PowerShell 프로필 파일에 기록한 내용은 별도로 수정해야 합니다.

특정 도구만 실패할 때: 앱별 설정 확인

환경 변수가 적용된 뒤에도 특정 도구만 실패한다면 해당 도구 자체의 프록시 설정을 확인하세요. 앱별 옵션이 환경 변수를 덮어쓸 수 있으며, 백그라운드 서비스는 현재 셸의 환경을 아예 상속하지 않을 수도 있습니다. Git을 예로 들어 설정 출처를 먼저 확인한 뒤 변경 여부를 결정하세요.

git config --show-origin --get-regexp '.*proxy.*'

# 이 명령에만 프록시를 지정하고 전역 설정에는 저장하지 않습니다
git -c http.proxy=http://127.0.0.1:7890 ls-remote https://github.com/git/git.git HEAD

명령에는 공개 저장소를 사용합니다. 비공개 저장소를 테스트할 때 인증 오류가 발생했다고 해서 곧바로 프록시 문제로 판단하면 안 됩니다. Git의 HTTPS 전송은 HTTP 프록시를 사용할 수 있지만, git@으로 시작하는 SSH 원격 주소는 별도의 전송 경로를 사용합니다. 따라서 http.proxy를 설정해도 같은 프록시를 통해 자동으로 연결되지는 않습니다.

마찬가지로 npm, Python 패키지 관리자, Java 앱, 컨테이너 빌드 도구는 각각 설정 파일, 명령줄 인수, 서비스 환경을 참조할 수 있습니다. 먼저 curl로 기준 연결을 확인한 뒤 각 도구를 점검하세요. 네트워크 문제를 진단하려고 TLS 인증서 검증을 끄지 마세요. 인증서 오류가 발생하면 시스템 시간, 신뢰 체인, 조직 네트워크의 인증서 설정을 확인하세요.

mihomo에 요청이 도달한 뒤: 규칙과 노드 확인

클라이언트 연결 목록에 대상 도메인이 나타나도 요청이 커널에 도달했다는 뜻일 뿐, 예상한 노드를 사용했다는 의미는 아닙니다. 규칙 모드에서는 규칙이 순서대로 적용됩니다. 앞쪽의 DIRECT 규칙, 정책 그룹에서 현재 선택한 DIRECT, 마지막의 MATCH가 모두 트래픽의 출구를 바꿀 수 있습니다.

• 모드 확인: 현재 규칙 모드인지 확인하세요. 비교 테스트를 위해 잠시 전역 모드로 전환한다면 전역 정책에서 프록시 노드가 실제로 선택되어 있는지 확인하고, 테스트가 끝나면 원래 모드로 되돌리세요.
• 일치한 규칙 확인: 대상 도메인, 일치한 규칙, 최종 정책 경로를 기록하세요. 구독에서 참조하는 정책 그룹 이름은 실제 정의와 일치해야 합니다.
• 노드 확인: 지연 시간 테스트에 성공해도 당시 테스트 URL에 접속할 수 있었다는 뜻일 뿐, 모든 도메인과 포트, 프로토콜이 작동한다는 보장은 없습니다.
• 오류 발생 단계 확인: 로컬 연결 실패, 노드 연결 시간 초과, DNS 조회 실패, TLS 핸드셰이크 오류는 각각 따로 처리하세요. 모두 같은 ‘프록시 오류’로 뭉뚱그리지 마세요.

출구 IP를 비교하려면 같은 IP 조회 서비스에 직접 연결 요청과 프록시 요청을 각각 보내고 연결 기록과 대조하세요. 두 요청의 출구 IP가 같더라도 시스템 프록시가 작동하지 않는다고 단정할 수는 없습니다. 규칙에 따라 해당 조회 도메인에 직접 연결했거나, TUN이 직접 연결처럼 보이는 요청을 가로챘을 수 있습니다. 테스트할 때 TUN 상태와 정책을 기록하고 여러 조건을 동시에 바꾸지 마세요.

# curl의 앱 프록시는 사용하지 않습니다. TUN이 켜져 있으면 이 요청도 가로챌 수 있습니다
curl --proxy "" --noproxy "*" --max-time 20 https://api.ipify.org

# 로컬 HTTP 프록시를 명시적으로 사용합니다
curl --noproxy "" -x http://127.0.0.1:7890 --max-time 20 https://api.ipify.org

TUN을 사용할 때와 시스템 프록시를 계속 점검할 때

브라우저에서만 문제가 발생하고 명시적 프록시는 정상이라면 먼저 브라우저 설정을 수정하세요. 터미널 도구가 프록시 변수를 지원한다면 도구별 설정으로 확인하는 편이 일반적으로 더 쉽습니다. TUN은 시스템 프록시를 사용하지 않는 앱을 가로채거나 더 많은 IP 트래픽을 처리해야 할 때 유용하지만, 모든 문제 해결의 첫 단계는 아닙니다.

TUN 모드는 가상 네트워크 인터페이스와 라우팅을 사용해 트래픽을 처리하며, 대개 권한, DNS, 라우팅 설정도 필요합니다. 고장 난 노드, 잘못된 구독이나 규칙을 자동으로 고쳐 주지는 않으며 다른 VPN이나 보안 소프트웨어의 네트워크 정책을 우회한다고 보장할 수도 없습니다. 먼저 다른 트래픽 가로채기 프로그램을 종료하고 현재 라우팅과 DNS 상태를 기록한 다음 클라이언트 안내에 따라 활성화하세요.

문제를 추가로 문의하려면 운영체제 버전, 클라이언트와 mihomo 커널 버전, 실제 수신 대기 포트, 실패한 명령과 오류가 발생한 시간대를 기록하세요. 로그를 공유하기 전에 구독 URL, 액세스 토큰, 노드 인증 정보를 삭제하세요. 전체 구성 항목은 전체 문서를, 기본 가져오기 및 트래픽 처리 방법은 사용 가이드를 참고하세요.