프록시를 켜면 브라우저는 되는데 터미널은 안 된다면? 시스템 프록시가 적용되지 않을 때 상황별 점검

먼저 문제가 발생한 계층부터 구분하기

Clash, Clash Meta（mihomo） 및 이러한 코어를 기반으로 제작된 데스크톱 클라이언트는 보통 로컬에서 HTTP, SOCKS5 또는 mixed 프록시 포트를 수신 대기합니다. 클라이언트의 “시스템 프록시” 스위치는 운영체제의 프록시 주소를 127.0.0.1:7890과 같은 로컬 수신 주소로 바꾸는 역할만 합니다. 애플리케이션이 이 설정을 읽는지, 요청이 코어로 들어오는지, 규칙이 최종적으로 어떤 정책을 선택하는지는 서로 독립된 세 가지 단계입니다.

따라서 “시스템 프록시가 켜져 있다”는 사실만으로 모든 프로그램이 자동으로 Clash를 거치는 것은 아닙니다. Chrome, Edge 같은 브라우저는 보통 시스템 프록시를 따르지만, Firefox는 자체 프록시 설정을 사용할 수 있습니다. curl, Git, npm, Python 패키지 관리자와 원격 터미널은 환경 변수나 각자의 설정 파일을 읽는 경우가 많습니다. 게임, UDP 프로그램 및 일부 스토어 앱은 기존 HTTP 시스템 프록시를 우회할 수 있어 TUN 모드로 트래픽을 가로채야 할 수도 있습니다.

네 가지 결과로 문제 범위 빠르게 좁히기

테스트 결과	가능성이 높은 원인	우선 확인할 항목
브라우저는 되지만 터미널은 안 됨	터미널이 시스템 프록시를 읽지 않음	환경 변수, Git/npm 개별 설정
브라우저와 터미널 모두 안 됨	포트, 코어, 설정 또는 노드 이상	수신 대기 포트, 실행 로그, 정책 그룹
프록시를 직접 지정하면 되지만 시스템 프록시는 안 됨	시스템 프록시 기록 실패 또는 덮어쓰기	운영체제 설정, 브라우저 정책, 확장 프로그램
웹페이지는 되지만 게임이나 UDP는 안 됨	시스템 프록시의 적용 범위 부족	TUN, DNS, 라우팅 및 방화벽

1단계: Clash가 실제로 수신 대기 중인 포트 확인

클라이언트마다 기본 포트가 완전히 같지는 않습니다. 흔히 HTTP 또는 mixed 포트는 7890, SOCKS5 포트는 7891, 외부 컨트롤 포트는 9090을 사용합니다. 이 중 9090은 패널에서 API를 호출하기 위한 제어 포트이지 웹 프록시 포트가 아닙니다. 시스템 프록시를 이 포트로 지정하면 바로 실패합니다. 최종적으로는 클라이언트의 현재 설정과 설정 파일을 기준으로 확인해야 하며, 흔한 숫자만 보고 추측해서는 안 됩니다.

GUI 클라이언트에서는 먼저 「설정」→「매개변수 설정」 또는 「설정」→「네트워크 설정」으로 이동해 HTTP, SOCKS, Mixed Port를 확인하세요. 설정에 mixed-port: 7890만 있다면 HTTP와 SOCKS5 모두 7890으로 연결할 수 있습니다. port와 socks-port를 따로 지정했다면 호출할 때 프로토콜에 맞는 포트를 사용해야 합니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

로컬 HTTP 프록시 직접 테스트

터미널에서 프록시를 직접 지정하면 시스템 프록시 설정을 우회해 Clash 포트가 작동하는지 따로 확인할 수 있습니다. 다음 명령은 표준 테스트 페이지에 접속하며, 정상이라면 HTTP 응답 헤더가 반환됩니다. -v를 추가하면 127.0.0.1:7890에 연결했는지도 확인할 수 있습니다.

curl -I -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204

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

프록시를 직접 지정했을 때는 성공하지만 -x 없는 명령이 실패한다면 코어, 노드, 포트는 대체로 정상이고 문제는 시스템 프록시 또는 터미널 설정에 집중됩니다. 직접 지정한 프록시도 Connection refused가 발생한다면 포트 오입력, 코어 미실행 또는 로컬 보안 프로그램의 수신 차단이 원인일 수 있습니다. 로컬 포트에는 연결되지만 이후 timeout이 표시된다면 노드, 규칙, DNS를 계속 확인하세요.

포트가 수신 대기 중인지 확인

# Windows
netstat -ano | findstr :7890

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp | grep 7890

출력에 로컬 수신 주소가 나타나야 합니다. 로컬에서만 사용할 경우 127.0.0.1:7890으로 수신 대기하는 것이 정상입니다. 같은 네트워크의 다른 기기가 연결해야 할 때만 allow-lan을 활성화하고 방화벽을 확인하세요. 로컬 브라우저 문제를 해결하려고 LAN 수신을 함부로 개방하지 마세요.

브라우저가 프록시를 사용하지 않을 때: 덮어쓰기 설정과 프록시 출처 확인

Windows와 macOS의 Chrome, Edge는 보통 시스템 프록시를 읽지만 확장 프로그램, 기업 정책, 시작 옵션, 보안 프로그램이 이를 덮어쓸 수 있습니다. Firefox에는 별도의 네트워크 설정이 있어 “프록시 사용 안 함”, “시스템 프록시 설정 사용”, “수동 프록시 설정” 중에서 선택할 수 있습니다. 브라우저마다 결과가 다른 것은 대개 설정을 가져오는 출처가 다르기 때문입니다.

Chrome과 Edge 점검 순서

브라우저를 완전히 종료한 뒤 다시 열어 기존 연결 풀이 직접 연결을 재사용하지 않도록 하세요.
브라우저에서 「설정」→「시스템 및 성능」→「컴퓨터의 프록시 설정 열기」로 이동해 주소가 127.0.0.1이고 포트가 Clash와 일치하는지 확인하세요.
프록시를 관리하는 확장 프로그램을 일시적으로 비활성화하세요. 특히 PAC, 고정 프록시 또는 프로필을 전환하는 확장 프로그램을 우선 확인합니다.
바로 가기나 시작 스크립트에 --proxy-server, --no-proxy-server 등의 옵션이 있는지 확인하세요.
Clash의 연결 목록이나 실시간 로그를 열어 둔 뒤 웹페이지를 새로 고침하고 대상 도메인이 나타나는지 확인하세요.

브라우저 로그에 새 연결이 전혀 없다면 요청이 아직 Clash에 들어오지 않은 것이므로 시스템 프록시 또는 브라우저 덮어쓰기 설정을 계속 확인해야 합니다. 연결은 보이지만 정책이 DIRECT라면 시스템 프록시는 적용된 상태이며 현재 규칙이 해당 도메인을 직접 연결하도록 선택한 것입니다. 이때는 시스템 프록시를 반복해서 켰다 끄기보다 규칙 매칭 결과를 확인해야 합니다.

Firefox는 자체 프록시 설정을 사용합니다

Firefox에서 「설정」→「일반」→「네트워크 설정」→「설정」으로 이동할 수 있습니다. Clash의 시스템 프록시를 따르려면 “시스템 프록시 설정 사용”을 선택하세요. “수동 프록시 설정”을 선택했다면 HTTP 프록시를 127.0.0.1, 포트를 7890으로 설정하고 실제 포트에 맞춰 SOCKS 호스트를 입력할 수 있습니다. SOCKS5를 사용할 때 도메인도 프록시 측에서 해석하려면 “SOCKS v5 사용 시 DNS 조회도 프록시” 옵션을 함께 확인하세요.

터미널이 프록시를 사용하지 않을 때: 시스템 프록시가 아니라 환경 변수 설정

macOS와 Linux의 터미널 프로그램은 데스크톱 시스템 프록시를 일괄적으로 상속하지 않는 경우가 많습니다. Windows에서도 PowerShell 명령, curl.exe, WSL, 각종 개발 도구를 구분해야 합니다. 가장 안정적인 확인 방법은 현재 터미널 세션에 프록시 환경 변수를 먼저 설정한 뒤 요청 명령을 실행하는 것입니다.

macOS 및 Linux 현재 세션

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

curl -I https://example.com/

https_proxy 값을 http://로 작성해도 모순이 아닙니다. 로컬 HTTP 프록시를 통해 CONNECT 터널을 사용하여 HTTPS 사이트에 접속한다는 뜻입니다. socks5h의 h는 도메인 해석을 SOCKS 프록시 측에 맡긴다는 의미로, 로컬 DNS와 프록시 출구의 불일치 문제를 줄일 수 있습니다.

한 명령에만 적용하려면 변수를 명령 앞에 작성하면 됩니다. 결과를 확인한 뒤 ~/.zshrc, ~/.bashrc 또는 프로젝트 스크립트에 추가할지 결정하세요. 시작 파일에 장기간 기록하면 Clash가 실행되지 않을 때도 터미널이 로컬 포트에 연결을 시도하므로 삭제 명령도 함께 준비하는 것이 좋습니다.

https_proxy=http://127.0.0.1:7890 curl -I https://example.com/

unset http_proxy
unset https_proxy
unset all_proxy

Windows PowerShell 현재 세션

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5h://127.0.0.1:7890"

curl.exe -I https://example.com/

구버전 Windows PowerShell에서는 curl이 Invoke-WebRequest의 별칭일 수 있어 표준 curl과 매개변수 동작이 다릅니다. 점검할 때는 curl.exe를 명시적으로 실행하고 curl.exe --version으로 실제 프로그램을 확인하세요. 현재 PowerShell 창을 닫으면 위 환경 변수는 사라집니다.

WSL에서는 연결 가능한 Windows 호스트 주소를 사용해야 합니다

WSL2는 독립된 가상 네트워크에서 실행되므로 WSL 내부의 127.0.0.1이 Windows의 Clash 수신 주소를 가리킨다고 보장할 수 없습니다. 먼저 클라이언트에서 LAN 연결을 허용하는지 확인한 뒤 WSL에서 기본 게이트웨이를 조회하고 해당 주소를 프록시 호스트로 사용하세요. WSL 네트워크 모드에 따라 동작이 다를 수 있으므로 특정 사설 IP를 그대로 외워서 사용하면 안 됩니다.

ip route | awk '/default/ {print $3}'

export https_proxy=http://Windows 호스트 주소:7890
curl -I https://example.com/

WSL에서 Windows 호스트에는 연결되지만 포트가 거부된다면 Clash가 127.0.0.1에서만 수신 대기하는지, LAN 액세스가 활성화되어 있는지, Windows 방화벽이 해당 개인 네트워크를 허용하는지 확인하세요. 테스트가 끝나면 로컬 전용 수신으로 되돌려 불필요한 LAN 노출을 줄일 수 있습니다.

Git, npm 및 개발 도구는 별도로 확인해야 합니다

환경 변수가 적용된 뒤에도 일부 도구는 자체 설정을 우선적으로 읽을 수 있습니다. 반대의 경우도 있습니다. 시스템 프록시는 꺼졌지만 Git이나 npm에 저장된 이전 프록시가 여전히 7890을 가리키면 Clash가 종료된 뒤 모든 요청이 오류가 납니다. 점검할 때는 “설정 누락”뿐 아니라 “남은 설정”도 확인해야 합니다.

Git 프록시 확인, 설정 및 삭제

git config --global --get http.proxy
git config --global --get https.proxy

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

git config --global --unset http.proxy
git config --global --unset https.proxy

다음 명령도 실행해 설정 출처를 확인하세요: git config --show-origin --get-regexp proxy. 프로젝트 수준의 .git/config, 사용자 수준 설정, 시스템 수준 설정이 동시에 존재할 수 있으며 우선순위가 높은 프로젝트 설정이 전역 설정을 덮어씁니다. SSH 형식의 원격 주소는 Git의 HTTP 프록시를 읽지 않으므로 SSH의 ProxyCommand를 설정하거나 HTTPS 주소로 바꿔 테스트해야 합니다.

npm 및 기타 패키지 관리자

npm config get proxy
npm config get https-proxy

npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890

npm config delete proxy
npm config delete https-proxy

pnpm, Yarn, pip, Maven, Docker는 환경 변수를 읽을 수도 있고 각자의 설정을 유지할 수도 있습니다. 브라우저는 정상인데 의존성 설치가 시간 초과된다면 먼저 도구의 상세 로그를 확인해 대상 도메인, 미러 주소, 이전 프록시 포트 중 어디에 연결하는지 확인하세요. 컨테이너 안의 127.0.0.1은 컨테이너 자체를 가리키므로 호스트의 Clash를 직접 의미하지 않습니다.

요청이 Clash에 들어온 뒤에도 실패할 때: 규칙, DNS, 노드 확인

실시간 로그에 대상 도메인이 이미 나타났다면 시스템 프록시 단계는 실제로 완료된 것입니다. 이후 실패는 로그를 기준으로 다시 나눠야 합니다. 규칙이 예상한 정책 그룹과 일치하는지, 정책 그룹이 사용 가능한 노드를 선택했는지, DNS가 올바른 주소를 반환했는지, 원격 연결이 시간 초과되었는지를 확인하세요. 모든 실패를 “프록시가 적용되지 않음”으로 묶으면 잘못된 지점에서 같은 작업을 반복하게 됩니다.

로그 필드로 원인 방향 판단

DIRECT: 요청이 코어에 들어온 뒤 규칙에 따라 직접 연결로 판정된 것입니다. 규칙 순서, 규칙 세트 업데이트, 현재 모드를 확인하세요.
REJECT: 요청이 거부 규칙에 매칭된 것입니다. 도메인이 광고 차단 또는 개인정보 보호 규칙 세트에 의해 차단되었는지 확인하세요.
dial tcp timeout: 로컬 포트가 요청을 받았지만 대상 또는 노드 연결이 시간 초과된 것입니다. 노드 지연 시간, 출구 네트워크, 방화벽을 확인하세요.
connection refused: 대상 주소가 연결을 적극적으로 거부한 것입니다. 노드 서비스 포트, 대상 서비스 또는 로컬 포트가 올바르지 않을 수 있습니다.
dns resolve failed: 도메인 조회 단계에서 실패한 것입니다. DNS 서버, Fake IP 설정, DoH 연결 가능 여부와 규칙을 확인하세요.

점검할 때 클라이언트 모드를 일시적으로 전역 프록시로 전환하고, 검증된 노드 하나를 선택해 비교할 수 있습니다. 전역 모드에서는 되지만 규칙 모드에서는 안 된다면 규칙 매칭을 중점적으로 확인하세요. 두 모드 모두 실패한다면 노드, 구독 설정, 네트워크 연결을 우선 확인해야 합니다. 테스트가 끝나면 규칙 모드로 되돌려 전역 모드를 장기 해결책으로 사용하지 않도록 하세요.

TUN 모드로 전환해야 하는 경우

시스템 프록시는 주로 HTTP 또는 SOCKS 프록시를 직접 지원하는 애플리케이션을 대상으로 합니다. 게임 런처, 일부 데스크톱 소프트웨어, UDP 트래픽, 고정된 직접 연결 프로그램은 시스템 프록시를 전혀 읽지 않을 수 있습니다. 이 경우 브라우저가 정상이어도 해당 애플리케이션은 직접 연결됩니다. TUN 모드는 가상 네트워크 어댑터를 통해 네트워크 계층에서 트래픽을 가로채므로 적용 범위가 더 넓지만 관리자 권한이 필요하고 DNS, 라우팅, 제외 규칙 설정이 늘어납니다.

애플리케이션에 프록시 설정이 없거나, 프로그램이 계속 시스템 프록시를 우회하거나, UDP를 처리해야 하거나, 여러 명령줄 도구가 Clash 규칙을 함께 따르도록 하려는 경우에는 TUN을 우선 고려할 수 있습니다. 브라우저와 일부 개발 도구만 처리한다면 시스템 프록시와 환경 변수를 조합하는 편이 더 명확하고 애플리케이션별 제어도 쉽습니다.

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

현재 클라이언트가 TUN을 지원하는 mihomo 코어를 사용하고 있으며 가상 네트워크 어댑터 생성에 필요한 권한을 부여받았는지 확인하세요.
현재 DNS 설정을 기록해 두세요. 시스템 DNS, 브라우저 DoH, Clash DNS가 여러 계층으로 겹치면 원인을 찾기 어려워집니다.
LAN 주소, 프린터, 개발 서버, 로컬 서비스를 필요한 직접 연결 규칙에 추가하세요.
다른 VPN과 가상 네트워크 어댑터 도구를 끄고 단일 변수로 테스트하세요. 기본 경로와 DNS가 서로 덮어쓰는 문제를 피할 수 있습니다.

TUN을 켠 직후 모든 네트워크가 끊기면 먼저 TUN을 끄고 연결을 복구한 다음 코어 로그와 가상 네트워크 어댑터 상태를 확인하세요. 구독, DNS, 규칙, 시스템 방화벽을 동시에 수정하지 마세요. 한 번에 하나만 바꾸고 전후 결과를 남겨야 실제 장애 지점을 확인할 수 있습니다.

순서대로 전체 점검 진행

Clash 코어가 실행 중이고 현재 설정이 정상적으로 로드되었으며 정책 그룹에서 연결 가능한 노드를 선택했는지 확인하세요.
「설정」→「매개변수 설정」에서 mixed, HTTP 또는 SOCKS5 포트를 확인하고 제어 포트 9090을 프록시 포트로 잘못 사용하지 않았는지 점검하세요.
curl -x로 127.0.0.1:7890을 명시해 로컬 프록시 포트를 사용할 수 있는지 확인하세요.
운영체제의 프록시 주소와 포트를 확인한 뒤 브라우저 확장 프로그램, Firefox의 독립 프록시 설정, 시작 옵션을 점검하세요.
현재 터미널 세션에 http_proxy, https_proxy 또는 all_proxy를 설정하고 같은 요청을 다시 실행하세요.
Git, npm 등 도구에 저장된 독립 프록시 설정을 확인하고 더 이상 사용하지 않는 이전 포트를 삭제하세요.
Clash 실시간 로그를 확인하세요. 연결 기록이 없으면 애플리케이션 측을 다시 확인하고, 기록이 있으면 규칙, DNS, 노드를 계속 점검하세요.
대상 프로그램이 실제로 시스템 프록시를 우회한다는 사실을 확인한 뒤 TUN 모드 활성화를 검토하세요.

브라우저는 되는데 터미널은 안 되는 가장 흔한 원인은 Clash 코어 장애가 아니라 두 애플리케이션이 프록시를 읽는 방식이 다르기 때문입니다. 먼저 프록시를 직접 지정하는 명령으로 포트를 확인한 다음 브라우저 덮어쓰기 설정과 터미널 환경 변수를 각각 처리하면 문제 범위를 빠르게 좁힐 수 있습니다. 요청이 코어에 들어온 뒤에야 규칙, DNS, 노드, TUN을 다음 단계의 점검 대상으로 삼아야 합니다.