시스템 프록시가 작동하지 않을 때: 브라우저는 프록시를 쓰는데 터미널은 왜 연결되지 않을까

시스템 프록시, 앱 프록시, TUN의 차이부터 확인하기

Clash Nyanpasu에서 「시스템 프록시」를 켜면 클라이언트가 로컬 프록시 주소를 운영체제 설정에 기록합니다. 일반적인 설정에서는 프록시 서버가 127.0.0.1, 혼합 포트가 7890입니다. 브라우저가 이 설정을 읽으면 HTTP 요청과 CONNECT로 수립한 HTTPS 연결을 Clash에 전달하고, Clash는 현재 설정의 규칙·정책 그룹·노드에 따라 트래픽을 처리합니다.

핵심은 시스템 프록시가 앱이 읽는 설정일 뿐, 운영체제가 모든 네트워크 패킷을 강제로 전달하는 기능은 아니라는 점입니다. Chrome, Edge, Safari 같은 데스크톱 브라우저는 대체로 시스템 프록시를 따르지만, 많은 명령줄 프로그램·게임 런처·개발 도구와 자체 네트워크 스택을 사용하는 앱은 직접 읽을지 결정합니다. 따라서 “브라우저는 접속되는데 터미널은 직접 연결된다”는 상황은 모순이 아닙니다. 대개 프록시 코어와 노드는 정상적으로 작동하고 있으며, 문제는 터미널 프로그램이 프록시 매개변수를 가져오는 방식에 있습니다.

트래픽을 가로채는 방식	적용 범위	일반적인 설정 위치	적합한 상황
시스템 프록시	운영체제 프록시 설정을 읽는 앱	Clash Nyanpasu 「설정」→「시스템 프록시」	브라우저 및 일반 데스크톱 앱
앱 내 프록시	지정한 앱 자체	앱 네트워크 설정 또는 실행 매개변수	Git, 브라우저 확장 프로그램, 개발 도구
환경 변수	현재 터미널 또는 해당 터미널에서 실행한 프로세스	HTTP_PROXY、HTTPS_PROXY、ALL_PROXY	curl, 패키지 관리자, 명령줄 도구
TUN 모드	가상 네트워크 인터페이스를 거치는 더 많은 트래픽	Clash Nyanpasu 「설정」→「TUN 모드」	프록시 설정을 읽지 않는 앱 및 UDP 트래픽

1단계: Clash 코어와 로컬 포트가 정상인지 확인하기

처음부터 시스템 네트워크 설정을 수정하지 마세요. 먼저 Clash Nyanpasu에서 설정이 활성화되어 있고 프록시 코어가 실행 중인지 확인한 뒤, 현재 모드가 「규칙」, 「전역」 또는 「직접 연결」 중 무엇인지 점검합니다. 규칙 모드에서 일부 대상이 규칙에 따라 직접 연결되는 것은 정상입니다. 테스트 도메인이 DIRECT에 일치하면 요청이 Clash로 들어갔더라도 프록시 노드의 외부 IP는 표시되지 않습니다.

혼합 포트와 수신 주소 확인하기

「설정」→「Clash 설정」 또는 현재 버전에 해당하는 포트 설정 페이지에서 mixed-port를 확인합니다. 흔히 7890을 사용하지만 설정을 가져왔거나 포트 충돌이 발생했거나 수동으로 변경했다면 실제 값이 7891, 7897 등이 될 수 있습니다. 이후 명령에 사용할 포트는 반드시 화면에 표시된 값과 일치해야 합니다.

기본 수신 주소는 보통 루프백 주소 127.0.0.1입니다. 명령을 로컬에서 실행한다면 LAN 접근을 활성화할 필요가 없으며, 프록시 주소를 이 기기의 Wi-Fi IP로 입력해서도 안 됩니다. 컨테이너·가상 머신 또는 같은 로컬 네트워크의 다른 기기에서 접근해야 할 때만 allow-lan, 방화벽, 수신 주소를 함께 설정하세요.

curl로 로컬 프록시 직접 테스트하기

먼저 시스템 프록시 설정을 우회하고 Clash의 HTTP 프록시를 명시해 요청을 한 번 보냅니다.

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

HTTP/2 200, HTTP/1.1 200 OK 또는 대상 사이트의 정상적인 리디렉션 상태가 반환되면 로컬 포트에 연결할 수 있고 HTTPS 터널도 수립된 것입니다. Failed to connect 또는 Connection refused가 표시되면 포트, 코어 실행 상태, 로컬 방화벽을 우선 확인하세요. 연결 수립 후 시간 초과가 발생하면 Clash 로그에서 규칙 일치 결과, 노드 오류, DNS 결과를 확인합니다.

SOCKS5 진입점을 지정해 테스트할 수도 있습니다. 혼합 포트는 보통 HTTP와 SOCKS5를 모두 지원하지만, 현재 설정을 기준으로 확인하세요.

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

socks5h의 h는 대상 도메인 이름을 프록시 측에서 해석한다는 뜻입니다. 로컬 DNS 문제와 프록시 경로 문제를 구분할 때 유용합니다. HTTP 프록시 테스트는 성공하지만 직접 요청이 실패한다면 점검 범위를 시스템 설정이나 앱 설정으로 좁힐 수 있습니다.

브라우저는 되는데 터미널이 안 될 때: 확장 프로그램과 프록시 재정의 확인하기

브라우저가 정상적으로 접속된다는 사실은 “브라우저가 현재 사용하는 특정 프록시 경로가 작동한다”는 것만 의미하며, 시스템 프록시 설정이 올바르다는 증거는 아닙니다. Chrome과 Edge는 대체로 시스템 프록시를 읽지만, 프록시 확장 프로그램·기업 정책·실행 매개변수·브라우저 내장 보안 DNS가 실제 동작을 바꿀 수 있습니다. Firefox에는 별도의 연결 설정도 있어 시스템 프록시, 수동 프록시, 직접 연결 중에서 선택할 수 있습니다.

브라우저 프록시 확장 프로그램의 독립 설정 배제하기

프록시 전환을 담당하는 브라우저 확장 프로그램을 잠시 비활성화합니다.
브라우저를 완전히 종료한 뒤 다시 시작해 백그라운드 프로세스가 이전 연결을 계속 사용하는 일을 막습니다.
Clash Nyanpasu의 시스템 프록시만 켠 상태에서 테스트 페이지를 다시 엽니다.
Clash의 연결 기록에 해당 도메인이 나타나는지 확인하고 규칙 일치 결과를 살펴봅니다.

확장 프로그램을 끈 직후 연결이 끊긴다면, 이전에는 시스템 프록시가 아니라 확장 프로그램이 127.0.0.1:7890에 직접 연결한 것입니다. 운영체제의 프록시 주소가 여전히 이전 포트를 가리키는지, 또는 다른 프록시 프로그램이 시스템 프록시 스위치를 덮어쓰고 있는지 확인하세요.

Firefox 연결 설정 확인하기

Firefox에서 「설정」→「일반」→「네트워크 설정」→「설정」으로 이동합니다. 「시스템 프록시 설정 사용」을 선택해야 운영체제 설정을 따릅니다. 「수동 프록시 설정」을 선택하면 HTTP 프록시와 HTTPS 프록시에 127.0.0.1 및 실제 혼합 포트를 입력해야 합니다. SOCKS를 사용한다면 SOCKS v5를 선택하고 필요에 따라 SOCKS 프록시를 통한 DNS 사용을 활성화하세요.

보안 DNS로 인한 차이 확인하기

브라우저의 DNS over HTTPS 때문에 도메인 해석 경로가 터미널과 달라질 수 있습니다. 터미널은 보통 시스템 DNS를 먼저 호출하지만, 브라우저는 자체 암호화 DNS 서비스에 질의할 수 있습니다. 브라우저는 접속되는데 터미널에 “호스트를 해석할 수 없음”이 표시된다면 먼저 nslookup 또는 dig로 시스템 해석을 확인한 다음, 앞서 설명한 socks5h 요청으로 프록시 측 해석을 테스트하세요. 이 경우 문제는 프록시 포트가 아니라 시스템 DNS, VPN 잔여 설정 또는 네트워크 인터페이스 우선순위에 있을 수 있습니다.

터미널은 왜 시스템 프록시를 자동으로 따르지 않을까

명령줄 도구는 여러 플랫폼에서 실행될 때 데스크톱 운영체제의 프록시 인터페이스에 의존하지 않는 경우가 많습니다. curl, Git, Python, Node.js와 각종 패키지 관리자의 프록시 변수 지원 방식도 서로 완전히 같지 않습니다. 가장 안정적인 방법은 현재 터미널 세션에 환경 변수를 설정한 뒤 대상 명령을 실행하는 것입니다. 테스트가 끝나면 변수를 삭제해 나중에 포트를 바꿨을 때 이전 주소로 계속 연결되지 않도록 하세요.

Windows PowerShell에서 임시로 설정하기

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5://127.0.0.1:7890"
$env:NO_PROXY="localhost,127.0.0.1,::1"

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

HTTPS_PROXY의 값을 http://로 작성하는 것은 흔하고 올바른 설정입니다. 클라이언트가 먼저 HTTP 프록시를 통해 CONNECT 터널을 만들고, 터널 안에서 HTTPS를 전송한다는 뜻입니다. 변수 이름에 HTTPS가 들어 있다는 이유만으로 프로토콜을 https://로 바꾸지 마세요. 로컬 프록시 포트가 TLS 프록시 서비스를 명확히 제공하는 경우에만 변경해야 합니다.

이 PowerShell 변수는 현재 창과 해당 창에서 시작한 자식 프로세스에만 영향을 줍니다. 창을 닫으면 설정이 사라집니다. 삭제 방법은 다음과 같습니다.

Remove-Item Env:HTTP_PROXY
Remove-Item Env:HTTPS_PROXY
Remove-Item Env:ALL_PROXY
Remove-Item Env:NO_PROXY

Windows CMD에서 임시로 설정하기

set HTTP_PROXY=http://127.0.0.1:7890
set HTTPS_PROXY=http://127.0.0.1:7890
set ALL_PROXY=socks5://127.0.0.1:7890
set NO_PROXY=localhost,127.0.0.1,::1

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

Windows에는 WinINET과 WinHTTP라는 두 가지 프록시 메커니즘이 있습니다. 브라우저와 많은 데스크톱 프로그램은 시스템 화면의 프록시 설정을 읽지만, 일부 시스템 서비스는 WinHTTP를 사용합니다. netsh winhttp show proxy로 WinHTTP 상태를 확인할 수 있지만, 일반 터미널 요청을 해결하려고 전역 설정을 바로 가져오지는 마세요. 먼저 대상 프로그램이 실제로 어느 설정을 읽는지 확인해야 합니다.

macOS 및 Linux의 현재 세션 설정

export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export ALL_PROXY="socks5://127.0.0.1:7890"
export NO_PROXY="localhost,127.0.0.1,::1"

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

소문자 변수도 함께 설정하면 소문자 이름만 읽는 도구와 호환할 수 있습니다.

export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export all_proxy="$ALL_PROXY"
export no_proxy="$NO_PROXY"

현재 세션의 변수를 삭제하려면 다음 명령을 실행합니다.

unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY
unset http_proxy https_proxy all_proxy no_proxy

~/.zshrc, ~/.bashrc 또는 다른 셸 설정 파일에 기록하려면 프록시 포트를 장기간 고정하기보다 프록시를 켜고 끄는 함수를 정의하는 것이 좋습니다. 그러면 Clash가 실행되지 않을 때 터미널이 존재하지 않는 로컬 프록시를 계속 기다리지 않습니다. 설정 파일을 수정한 뒤에는 터미널을 다시 열거나 해당 source 명령을 실행해야 합니다.

Git, 패키지 관리자와 개발 도구는 별도로 확인하기

환경 변수를 올바르게 설정해도 일부 도구는 자체 설정으로 값을 덮어쓸 수 있습니다. 점검할 때는 “시스템 설정, 환경 변수, 앱 설정” 세 계층을 함께 확인하고 설정 우선순위도 살펴보세요. 가장 흔한 경우는 Git에 이전 포트가 저장되어 있거나 npm 설정이 이미 중지된 프록시 주소를 가리키는 것입니다.

Git 프록시 설정

Git이 현재 읽어 오는 프록시 출처를 확인합니다.

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

현재 사용자에게 프록시를 설정하려면 다음을 실행합니다.

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

나중에 환경 변수나 TUN 모드로 전환할 때는 새 경로를 계속 덮어쓰지 않도록 이 두 항목을 삭제해야 합니다.

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

npm 및 pnpm의 프록시 기록

npm config get proxy
npm config get https-proxy
pnpm config get proxy
pnpm config get https-proxy

출력에 이전 주소가 표시되면 현재 포트로 업데이트하거나 해당 설정을 삭제하세요. 패키지 관리자는 미러 레지스트리, 인증서 체인, DNS, 저장소 서비스 상태의 영향도 받습니다. 따라서 “다운로드 실패”를 프록시 스위치만으로 판단할 수는 없습니다. 먼저 curl로 같은 저장소 도메인에 요청한 뒤 명령의 상세 로그를 확인해 TCP 연결 실패, 도메인 해석 실패, TLS 오류, 서버 측 속도 제한을 구분하세요.

컨테이너와 가상 머신에서의 127.0.0.1

Docker 컨테이너, WSL, 가상 머신 안의 127.0.0.1은 대개 각각의 네트워크 환경을 가리키며 호스트 컴퓨터를 의미하지 않을 수 있습니다. 호스트의 Clash 주소를 그대로 입력하면 연결이 거부되는 경우가 많습니다. 이때는 해당 가상 네트워크에서 호스트가 사용하는 주소를 지정하고, 필요에 따라 Clash에서 LAN 접근을 활성화한 뒤 운영체제 방화벽도 설정해야 합니다. 접근 범위는 신뢰할 수 있는 네트워크로 제한하고 공용 네트워크에 그대로 노출하지 마세요.

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

대상 앱이 HTTP 또는 SOCKS 프록시를 지원하지 않고 환경 변수도 읽지 않는다면 시스템 프록시만으로는 적용하기 어렵습니다. 대표적인 경우는 일부 게임 런처, UDP를 사용하는 프로그램, 직접 연결을 고정한 데스크톱 앱, 여러 개발 도구를 동시에 제어해야 하는 작업 환경입니다. 이때는 TUN 모드를 고려할 수 있습니다. 트래픽이 먼저 가상 네트워크 인터페이스를 거친 뒤 mihomo 코어에서 규칙에 따라 처리됩니다.

TUN 모드는 적용 범위를 넓히는 기능입니다

TUN이 노드 품질을 자동으로 높이거나 구독에 포함된 잘못된 서버 매개변수를 수정해 주는 것은 아닙니다. 주된 변화는 트래픽이 Clash로 들어오는 방식입니다. 활성화하면 기존에 시스템 프록시를 우회하던 TCP 또는 UDP 트래픽도 하나의 경로로 가로챌 수 있으며, 규칙 모드·정책 그룹·노드 선택은 여전히 현재 설정에 따라 실행됩니다.

Clash Nyanpasu에서는 「설정」→「TUN 모드」에서 관련 기능을 켤 수 있습니다. Windows는 처음 활성화할 때 가상 네트워크 인터페이스를 만들기 위해 관리자 권한이 필요할 수 있습니다. macOS에서는 네트워크 확장 프로그램이나 시스템 권한 확인 창이 나타날 수 있고, Linux에서는 적절한 네트워크 관리 권한이 필요한 경우가 많습니다. 클라이언트 버전에 따라 메뉴 이름은 조금 다를 수 있지만, TUN 스위치·네트워크 인터페이스 상태·코어 로그를 기준으로 판단하세요.

활성화 전후 점검 순서

라우팅 테이블이 여러 프로그램에 의해 동시에 수정되지 않도록 다른 VPN, 가속기 또는 유사한 TUN 프로그램을 종료합니다.
복구할 수 있도록 현재 시스템 프록시 상태, 혼합 포트, DNS 설정을 기록합니다.
TUN을 활성화한 뒤 가상 인터페이스가 정상적으로 생성되었는지 확인하고 코어 로그에 권한 오류가 나타나는지 관찰합니다.
먼저 브라우저와 curl을 테스트한 뒤, 기존에 가로채지 못했던 앱을 테스트합니다.
LAN 주소, 프린터, 개발 서버에 계속 접근할 수 있는지 확인하고 필요하면 직접 연결 규칙을 설정합니다.

일부 클라이언트에서는 TUN과 시스템 프록시를 동시에 켤 수 있지만, 문제 해결 단계에서는 한 번에 한 가지 가로채기 방식만 검증하는 것이 좋습니다. 그렇지 않으면 같은 요청이 서로 다른 진입점을 거칠 수 있어 문제가 시스템 프록시·환경 변수·가상 인터페이스 중 어디에서 발생했는지 판단하기 어렵습니다. TUN이 정상 작동하는 것을 확인한 뒤 사용 습관에 따라 시스템 프록시를 유지할지 결정하세요.

DNS, 규칙, 루프백 주소에서 자주 발생하는 오해

터미널에서 도메인 해석 실패가 표시될 때

프록시에 연결하기 전에 오류가 발생해 Could not resolve host가 표시된다면 먼저 HTTP 프록시인지 SOCKS인지 확인하세요. HTTP CONNECT 요청은 일반적으로 대상 호스트 이름을 프록시에 전달해 처리합니다. socks5://는 로컬에서 먼저 해석할 수 있지만 socks5h://는 프록시 측 해석을 명시적으로 요구합니다. 두 방식을 비교 테스트하면 문제가 시스템 DNS와 프록시 경로 중 어디에 있는지 빠르게 판단할 수 있습니다.

Clash로 요청이 들어왔지만 DIRECT로 표시될 때

규칙 모드는 도메인·IP·프로세스·규칙 세트에 따라 정책을 선택합니다. 로그에 DIRECT가 표시된다면 요청은 이미 가로채졌지만 규칙이 직접 연결을 선택한 것입니다. 현재 설정의 규칙 순서, 대상 도메인이 속한 규칙 세트, 최종 기본 규칙을 확인하세요. 일시적으로 전역 모드로 전환해 비교할 수 있지만, 테스트가 끝나면 원래 모드로 되돌려 LAN과 국내 서비스를 불필요하게 프록시 노드로 보내지 않도록 해야 합니다.

localhost가 프록시를 거친 뒤 접속되지 않을 때

개발 서버는 흔히 localhost:3000, 127.0.0.1:5173 또는 다른 로컬 포트를 사용합니다. 환경 변수를 설정할 때는 NO_PROXY에 localhost, 127.0.0.1, ::1을 넣어 제외해야 합니다. 그렇지 않으면 일부 도구가 로컬 요청을 프록시로 보내려 할 수 있습니다. 인트라넷 서비스에 접근해야 한다면 도구가 지원하는 형식으로 회사 도메인이나 네트워크 대역을 추가할 수도 있지만, 와일드카드와 CIDR 지원 여부는 프로그램마다 다릅니다.

증상별로 문제 범위를 좁히는 전체 점검 목록

브라우저는 정상이고 curl 직접 연결은 실패: -x로 프록시를 명시하세요. 성공한다면 터미널에 환경 변수를 설정하거나 도구 내부 프록시를 구성합니다.
브라우저는 정상이고 curl의 프록시 지정도 실패: 브라우저가 확장 프로그램의 다른 포트를 사용하고 있을 수 있습니다. 확장 프로그램 설정과 Clash의 현재 혼합 포트를 대조하세요.
curl의 프록시 지정은 성공하지만 환경 변수 방식은 실패: 변수 이름과 대소문자, 현재 셸의 적용 범위, 해당 도구의 변수 지원 여부를 확인하세요.
연결 기록에 대상 요청이 없음: 요청이 아직 Clash에 들어오지 않은 것입니다. 앱 설정, 로컬 주소, 컨테이너 네트워크, 포트 점유 상태를 계속 확인하세요.
연결 기록은 있지만 규칙이 DIRECT: 규칙 일치 결과를 확인하고 직접 연결을 시스템 프록시 고장으로 오해하지 마세요.
연결 기록이 있고 프록시 노드 오류가 표시됨: 정책 그룹의 다른 노드를 테스트하고 구독 업데이트, 노드 상태, 네트워크 연결성을 확인하세요.
도메인만 실패하고 IP는 연결됨: 시스템 DNS, Clash DNS 설정, SOCKS의 도메인 해석 방식을 중점적으로 확인하세요.
앱이 프록시 매개변수를 전혀 지원하지 않음: TUN 모드를 검토하고 가상 인터페이스 권한, 라우팅 충돌, LAN 직접 연결 규칙을 처리하세요.

가장 효율적인 점검 순서는 로컬 포트를 확인하고, 프록시를 명시해 테스트한 다음, 시스템 프록시나 환경 변수를 확인하고, 마지막으로 TUN을 검토하는 것입니다. 브라우저가 이미 접속된다면 노드나 구독을 계속 바꿀 필요는 대개 없습니다. 터미널이 프록시를 읽는지, 포트가 일치하는지, DNS가 어디에서 해석되는지, 요청이 실제로 Clash 코어에 들어오는지에 집중하세요.