Clash 시스템 프록시가 작동하지 않을 때 해결 방법: 브라우저와 터미널을 나눠 점검

먼저 문제가 발생한 계층을 확인하세요

“시스템 프록시가 활성화됨”은 클라이언트가 HTTP 및 HTTPS 프록시 주소를 운영체제 설정에 기록하려 한다는 뜻일 뿐, 모든 프로그램이 이 설정을 읽는다는 의미는 아닙니다. Chrome과 Edge 같은 브라우저는 대체로 시스템 프록시를 따릅니다. Firefox는 시스템 설정을 사용할 수도 있고 별도의 프록시 설정을 유지할 수도 있습니다. 터미널의 Git, curl, npm, Python 및 컨테이너 도구는 시스템 프록시를 우회하고 환경 변수나 자체 구성 파일을 읽는 경우가 많습니다.

문제 해결을 시작할 때 노드를 먼저 바꾸거나 클라이언트를 재설치하거나 구독을 반복해서 가져오지 마세요. 먼저 연결 경로를 네 단계로 나누세요. Clash 코어가 실행 중인지, 수신 포트가 존재하는지, 대상 프로그램이 해당 포트로 연결을 전달하는지, 연결이 Clash에 들어온 뒤 어떤 규칙과 일치하는지 확인합니다. 계층별로 점검하면 문제가 클라이언트, 운영체제, 애플리케이션 또는 규칙 설정 중 어디에 있는지 판단할 수 있습니다.

관찰 결과	우선 확인할 항목	일반적인 원인
브라우저와 터미널 모두 프록시를 사용할 수 없음	코어, 포트, 설정 상태	코어가 시작되지 않음, 포트 충돌, 설정 로드 실패
브라우저는 정상인데 터미널은 직접 연결됨	터미널 환경 변수 및 도구 설정	명령줄 프로그램이 시스템 프록시를 읽지 않음
터미널에서 프록시를 명시하면 정상이고 브라우저는 직접 연결됨	시스템 프록시 및 브라우저 설정	시스템 프록시가 기록되지 않음, 확장 프로그램이 덮어씀, 브라우저가 독립 설정을 사용함
요청은 로그에 나타나지만 웹사이트가 열리지 않음	규칙, 노드, DNS 및 인증서 오류	REJECT에 일치함, 노드를 사용할 수 없음, 도메인 해석 이상
일반 프로그램은 정상인데 게임이나 UWP 앱에서 문제가 발생함	TUN, 루프백 제한, UDP 지원	프로그램이 HTTP 프록시를 사용하지 않거나 UDP 전달이 필요함

실제 포트를 기록하고 7890을 그대로 사용하지 마세요

많은 설정에서 7890을 mixed-port로 사용하지만 필수값은 아닙니다. 클라이언트에 따라 HTTP, SOCKS5 및 혼합 포트가 다르게 표시될 수 있고, 설정 파일이 포트를 덮어쓸 수도 있습니다. 클라이언트의 「설정」→「포트 설정」 또는 「설정」→「Clash 설정」을 열어 현재 수신 중인 주소와 포트를 기록하세요. 화면에 혼합 포트가 7890으로 표시될 때만 이후 명령에서 해당 값을 사용합니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-port는 HTTP와 SOCKS5 연결을 모두 허용합니다. 설정에서 port: 7890과 socks-port: 7891을 각각 사용하는 경우 테스트 명령도 프로토콜에 맞춰야 합니다. HTTP만 허용하는 포트로 SOCKS5 요청을 보내면 “포트 유형 오류”라는 명확한 메시지 대신 연결 재설정이나 프록시 핸드셰이크 실패가 발생하는 경우가 많습니다.

브라우저 경로: 시스템 프록시와 확장 프로그램 덮어쓰기 확인

1단계: 운영체제의 프록시 주소 확인

Windows 11에서는 「설정」→「네트워크 및 인터넷」→「프록시」로 이동해 “프록시 서버 사용”이 켜져 있는지 확인하세요. 주소는 보통 127.0.0.1이며, 포트는 Clash의 현재 HTTP 또는 혼합 포트와 일치해야 합니다. 클라이언트에는 시스템 프록시가 켜져 있다고 표시되는데 Windows 페이지에는 이전 포트가 남아 있다면, 먼저 클라이언트의 시스템 프록시를 끈 다음 다시 켜세요.

macOS에서는 「시스템 설정」→「네트워크」→현재 네트워크 인터페이스→「세부사항」→「프록시」로 이동합니다. 일반적인 설정에서는 “웹 프록시(HTTP)”와 “보안 웹 프록시(HTTPS)”를 모두 선택하고, 서버에 127.0.0.1, 포트에 클라이언트에 표시된 HTTP 또는 mixed 포트를 입력합니다. SOCKS 프록시만 설정할 경우 애플리케이션이 이를 사용할지는 애플리케이션의 구현에 따라 달라집니다.

시스템 프록시에 노드 서버 주소를 입력해서는 안 됩니다. 시스템 설정의 대상은 127.0.0.1:7890과 같은 로컬 Clash 수신 주소입니다. 노드 주소, 인증 정보 및 전송 매개변수는 Clash 설정에서 처리합니다. 원격 노드의 포트를 시스템 프록시에 직접 입력하면 해당 프로토콜 핸드셰이크가 완료되지 않는 경우가 많습니다.

2단계: 브라우저 독립 프록시와 확장 프로그램 충돌 배제

Chrome과 Edge는 기본적으로 시스템 프록시를 읽지만, 프록시 전환 확장 프로그램이 이 경로를 덮어쓸 수 있습니다. 먼저 시크릿 창에서 테스트하세요. 확장 프로그램이 시크릿 모드에서 실행되도록 허용되어 있다면 확장 프로그램 관리 페이지에서 프록시 관련 확장 프로그램을 잠시 비활성화해야 합니다. SwitchyOmega 대체 확장 프로그램, 기업 정책 프록시, 패킷 캡처 도구 및 디버깅 프록시를 중점적으로 확인하세요. 여러 도구가 동시에 프록시를 제어하면 마지막으로 기록했거나 우선순위가 높은 설정이 실제 출구를 결정합니다.

Firefox는 「설정」→「일반」→「네트워크 설정」→「설정」을 별도로 확인해야 합니다. Clash가 기록한 시스템 값을 따르려면 “시스템 프록시 설정 사용”을 선택하세요. “수동 프록시 설정”을 선택한 경우 현재 로컬 포트를 입력해야 하며, “프록시 사용 안 함”을 선택하면 직접 연결합니다. Firefox의 “이 네트워크의 프록시 설정 자동 감지”도 시스템 프록시를 따른다는 뜻은 아닙니다.

3단계: 로그로 브라우저 요청이 Clash에 들어오는지 확인

클라이언트의 「로그」 페이지를 열고 로그 수준을 info로 유지하세요.
브라우저에서 자동으로 새로고침되는 페이지를 닫아 백그라운드 요청의 간섭을 줄이세요.
새 탭을 열고 이전에 방문하지 않은 HTTPS 사이트에 접속하세요.
로그에서 해당 도메인을 검색하고 연결 출처, 일치한 규칙 및 최종 정책을 확인하세요.

로그에 해당 도메인이 전혀 나타나지 않는다면 문제는 브라우저와 로컬 포트 사이에 있습니다. 시스템 프록시, 브라우저 정책 및 확장 프로그램을 계속 확인하세요. 로그에 MATCH, DOMAIN-SUFFIX 등의 규칙과 특정 프록시 그룹 또는 DIRECT가 표시된다면 브라우저가 이미 요청을 Clash에 전달한 것입니다. 다음으로 규칙 선택과 노드 상태를 확인하세요.

브라우저에 표시되는 캐시 페이지는 현재 프록시가 정상이라는 증거가 될 수 없습니다. 개발자 도구의 「네트워크」 패널에서 “캐시 사용 안 함”을 선택한 뒤 강력 새로고침을 실행하는 것이 좋습니다. Clash의 「연결」 페이지도 함께 확인하세요. 새 연결에는 대상 도메인, 네트워크 유형, 업로드·다운로드 트래픽 및 적용된 경로가 표시되어야 합니다.

터미널 경로: 프록시를 명시해 포트 확인

터미널 프로그램의 동작은 브라우저 결과만으로 추정할 수 없습니다. 가장 확실한 방법은 먼저 단일 명령에 프록시를 명시하는 것입니다. 명시적 프록시가 성공하면 환경 변수나 도구별 매개변수를 설정하세요. 명시적 프록시도 실패하면 로컬 포트, 코어 상태 및 방화벽을 다시 확인하세요.

curl로 HTTP 프록시 직접 테스트

Windows PowerShell 5.1에서는 curl이 Invoke-WebRequest의 별칭일 수 있으므로 curl.exe를 명시적으로 실행해야 합니다. 최신 Windows 10과 Windows 11에는 일반적으로 curl이 기본 포함되어 있습니다. mixed-port가 7890이라고 가정하고 다음을 실행하세요.

curl.exe -v -x http://127.0.0.1:7890 https://example.com/

macOS, Linux, Git Bash 또는 독립 curl이 설치된 환경에서는 다음을 실행할 수 있습니다.

curl -v -x http://127.0.0.1:7890 https://example.com/

상세 출력에 Connected to 127.0.0.1과 HTTPS 대상에 대한 CONNECT 요청이 나타나면 curl이 로컬 프록시에 연결된 것입니다. 이어서 HTTP 상태 코드가 반환되고 Clash 로그에 대상 도메인이 나타나면 프록시 경로가 정상입니다. 즉시 Connection refused가 표시되면 해당 포트가 수신 중이 아니거나 포트를 잘못 입력한 것입니다.

SOCKS5를 사용하고 도메인 해석은 Clash에 맡기기

SOCKS5 테스트에는 socks5h를 사용하는 것이 좋습니다. 끝의 h는 도메인 해석을 프록시에 맡긴다는 뜻으로, 로컬 DNS 결과가 테스트에 영향을 주는 것을 방지합니다. 포트에는 SOCKS 포트 또는 mixed-port를 입력하세요.

curl -v --proxy socks5h://127.0.0.1:7890 https://example.com/

socks5://와 socks5h://의 주요 차이는 도메인을 어디에서 해석하는지에 있습니다. 전자는 보통 로컬에서 먼저 해석한 뒤 IP를 프록시에 전달하고, 후자는 도메인을 SOCKS 요청에 포함합니다. 도메인 오염, 도메인 기반 분기 또는 불안정한 로컬 DNS를 점검할 때는 socks5h를 우선 사용하세요.

현재 터미널 세션의 환경 변수 설정

PowerShell에서는 현재 창에서만 프록시를 설정할 수 있습니다. 창을 닫으면 변수가 사라지므로 문제 해결 테스트에 적합합니다.

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
curl.exe -v https://example.com/

macOS, Linux, WSL 또는 Git Bash에서는 대문자와 소문자 변수를 모두 설정하는 것이 좋습니다. 프로그램마다 읽는 규칙이 완전히 같지 않기 때문입니다.

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
curl -v https://example.com/

NO_PROXY와 no_proxy도 확인하세요. 대상 도메인, 도메인 접미사 또는 와일드카드 범위가 제외 목록에 있으면 프로그램이 프록시를 우회합니다. 아래 설정은 로컬 주소만 직접 연결하도록 합니다.

export NO_PROXY=localhost,127.0.0.1,::1
export no_proxy=localhost,127.0.0.1,::1

Git, npm 및 Python은 각각 프록시를 저장할 수 있습니다

Git은 환경 변수를 읽을 수 있지만 전역 설정에 이전 포트가 남아 있을 수도 있습니다. 먼저 현재 설정의 출처를 확인한 뒤 수정 여부를 결정하세요.

git config --global --get http.proxy
git config --global --get https.proxy
git config --show-origin --get-regexp "http\..*proxy"

Git에 로컬 프록시를 명시적으로 설정해야 한다면 다음을 사용할 수 있습니다.

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

npm은 npm config get proxy 및 npm config get https-proxy로 설정을 확인할 수 있습니다. Python의 pip는 HTTPS_PROXY를 읽을 수도 있고, 일회성 매개변수로 테스트할 수도 있습니다.

python -m pip install --proxy http://127.0.0.1:7890 패키지명

도구 설정에 남은 이전 포트는 쉽게 오판을 일으킵니다. 브라우저는 새 7890으로 전환했는데 Git은 여전히 이전 7897에 연결할 수 있습니다. 따라서 Clash의 수신 포트를 변경할 때마다 환경 변수, Git 설정, npm 설정, IDE 터미널 및 컨테이너 환경을 다시 확인해야 합니다.

코어와 포트가 실제로 수신 중인지 확인

Windows에서 수신 프로세스 확인

PowerShell 또는 명령 프롬프트에서 다음 명령을 실행해 7890이 LISTENING 상태인지 확인하세요.

netstat -ano | findstr :7890

출력 마지막에는 프로세스 PID가 표시됩니다. 이어서 프로세스 이름을 조회할 수 있습니다.

tasklist /FI "PID eq 프로세스 번호"

해당 포트를 점유한 프로세스가 현재 Clash 클라이언트가 아니라면 수신 포트를 변경하거나 충돌하는 프로세스를 종료하세요. 아무 출력도 없다면 클라이언트에서 코어 상태와 설정 오류를 확인하세요. 설정 파싱에 실패해도 그래픽 인터페이스는 열려 있을 수 있지만 프록시 포트가 예상대로 생성되지 않습니다.

macOS와 Linux에서 수신 주소 확인

lsof -nP -iTCP:7890 -sTCP:LISTEN

Linux에서는 다음 명령도 사용할 수 있습니다.

ss -lntp | grep 7890

127.0.0.1:7890에서 수신 중이면 로컬 프로그램만 접근할 수 있으며, 데스크톱에서 일반적인 설정입니다. 로컬 네트워크의 다른 기기가 해당 포트에 연결하려면 클라이언트에서 “LAN 연결 허용”을 켜고 설정의 allow-lan을 true로 지정한 뒤, 수신 주소와 시스템 방화벽이 해당 네트워크 접근을 허용하는지 확인해야 합니다. 로컬 브라우저 문제를 점검하기 위해 LAN 수신으로 변경하지 마세요.

로그에 연결이 나타난 뒤 규칙을 확인하세요

Clash의 규칙은 일반적으로 위에서 아래 순서로 매칭되며, 먼저 일치한 규칙이 적용됩니다. 도메인은 먼저 DOMAIN, DOMAIN-SUFFIX 또는 규칙 세트와 일치할 수 있으며, 앞선 규칙이 모두 일치하지 않을 때만 최종 MATCH로 넘어갑니다. 테스트 요청이 REJECT에 일치하면 연결이 거부되고, DIRECT에 일치하면 로컬 네트워크로 직접 접속합니다.

전역 모드로 전환한 뒤 정상으로 돌아온다면 일반적으로 포트, 시스템 프록시 및 노드 경로는 정상이고 문제가 규칙이나 정책 그룹에 집중되어 있다는 뜻입니다. 이때 로그의 규칙 이름과 정책 그룹을 기록하고 해당 그룹에서 사용 가능한 노드를 선택했는지 확인하세요. 규칙 문제를 가리기 위해 전역 모드를 계속 사용하지 마세요. LAN 주소, 소프트웨어 업데이트 및 로컬 서비스까지 불필요하게 프록시로 전송될 수 있습니다.

시스템 프록시로 해결되지 않는 프로그램: TUN 필요 여부 판단

시스템 프록시는 주로 HTTP 또는 SOCKS 프록시를 직접 지원하는 애플리케이션에 적용됩니다. 일부 게임, 명령줄 프로그램, 스토어 앱, 가상 머신, 컨테이너 및 자체 네트워크 스택을 사용하는 소프트웨어는 시스템 설정을 읽지 않습니다. 따라서 브라우저가 완전히 정상이어도 이러한 프로그램은 직접 연결될 수 있습니다.

TUN 모드는 가상 네트워크 인터페이스를 통해 더 많은 IP 트래픽을 가로채고, 이를 mihomo 같은 호환 코어로 전달합니다. 별도로 프록시를 설정할 수 없거나 UDP가 필요하거나 애플리케이션 연결을 일괄 처리해야 하는 경우에 적합합니다. TUN은 “시스템 프록시 강화 스위치”가 아니며, 시스템 권한, 라우팅, DNS 가로채기 방식 및 가상 네트워크 카드 상태에 따라 작동합니다.

TUN을 켜기 전에 확인할 세 가지

일반 HTTP 프록시 테스트가 성공했으며 노드와 설정 자체가 정상인지 확인합니다.
클라이언트가 TUN을 지원하는 Clash Meta 또는 mihomo 코어를 사용하고, 서비스 모드 또는 관리자 권한 설정을 완료했는지 확인합니다.
시스템에서 다른 VPN, 가상 네트워크 카드 또는 보안 소프트웨어가 기본 경로와 DNS를 동시에 변경하고 있지 않은지 확인합니다.

활성화한 뒤 클라이언트 로그에 TUN 인터페이스가 성공적으로 생성되었다는 정보가 나타나는지 확인하고, 대상 프로그램의 연결이 Clash에 들어오는지 관찰하세요. Windows에서 특정 UWP 앱만 인터넷에 연결되지 않는다면 앱 루프백 제한도 고려해야 합니다. 일부 클라이언트는 UWP Loopback 보조 기능을 제공합니다. 이 문제는 일반 데스크톱 브라우저의 시스템 프록시 설정과는 다른 계층에 있습니다.

TUN을 켠 뒤 시스템 전체에서 도메인을 해석하지 못한다면 먼저 TUN을 끄고 네트워크를 복구한 다음 DNS 설정, 가상 네트워크 카드 및 다른 VPN과의 충돌을 확인하세요. 노드, 규칙, DNS 및 라우팅을 동시에 변경하면 어떤 항목이 변화를 일으켰는지 판단하기 어렵습니다.

결과에 따라 마무리하기: 재현 가능한 문제 해결 순서

클라이언트 코어가 실행 중이고 설정 페이지에 파싱 오류가 없는지 확인합니다.
클라이언트 화면에서 실제 HTTP, SOCKS5 또는 mixed-port를 확인하고 포트 번호를 미리 가정하지 않습니다.
netstat, lsof 또는 ss를 사용해 포트가 수신 중인지 확인합니다.
일시적으로 전역 모드로 전환하고 사용 가능한 것으로 확인된 노드를 선택합니다.
브라우저 경로에서 시스템 프록시, Firefox 독립 설정 및 프록시 확장 프로그램을 확인합니다.
Clash 로그를 열고 새 도메인에 접속해 요청이 코어에 들어오는지 확인합니다.
터미널에서 curl -x로 프록시를 명시하고 환경 변수에 먼저 의존하지 않습니다.
명시적 테스트가 성공한 뒤 HTTP_PROXY, HTTPS_PROXY 또는 도구별 프록시를 설정합니다.
규칙 모드로 돌아가 로그를 기준으로 일치한 규칙, 정책 그룹 및 최종 출구를 확인합니다.
애플리케이션이 시스템 프록시를 지원하지 않을 때만 TUN, UWP 루프백 또는 컨테이너 네트워크를 검토합니다.

이 순서의 핵심은 각 단계에서 하나의 변수만 확인하는 것입니다. 브라우저는 연결되지 않지만 curl을 명시하면 성공한다면 시스템 프록시와 브라우저를 확인하세요. 브라우저는 연결되지만 터미널은 연결되지 않는다면 환경 변수와 도구 설정을 확인하세요. 둘 다 로컬 포트에 연결하지 못한다면 코어와 수신 상태를 확인하세요. 요청이 로그에 들어왔지만 결과가 이상하다면 규칙, 노드 및 DNS를 확인하세요. “시스템 프록시가 작동하지 않는다”는 문제를 이렇게 관찰 가능한 결과로 나누면 보통 클라이언트를 재설치할 필요가 없습니다.