Clash 켰는데도 브라우저는 직결?시스템 프록시 미작동 시 브라우저·터미널 분리 진단
시스템 프록시 스위치는 켜져 있는데 트래픽이 프록시를 타지 않는다면, 이는 대부분 Clash 자체의 문제가 아니라 브라우저와 터미널이 각자 독자적인 프록시 판단 로직을 갖고 있기 때문입니다. 이 글은 진단을 레지스트리/네트워크 설정, 브라우저 확장 충돌, 터미널 환경 변수 세 갈래로 나눠 항목별로 원인을 찾아내고, 마지막으로 특정 스위치 하나에 의존하지 않는 TUN 모드 대안까지 소개합니다.
시스템 프록시 스위치는 정확히 무엇을 바꾸는가
Clash 클라이언트 화면의 "시스템 프록시" 스위치는 본질적으로 운영체제 레벨에 HTTP/HTTPS 프록시 설정 한 줄을 써넣는 것입니다—Windows는 레지스트리의 ProxyServer 키 값을, macOS는 네트워크 서비스의 프록시 설정을, Linux 데스크톱 환경은 GSettings나 환경 변수를 기록합니다. 이 설정은 **시스템 프록시 설정을 따르는 프로그램**에만 적용되며, "따를지 여부"는 완전히 애플리케이션 자신의 판단에 달려 있습니다. 운영체제가 모든 아웃바운드 연결을 강제로 이 규칙에 맞추도록 가로채는 것은 아닙니다.
즉 시스템 프록시는 하나의 "권장 설정"이지 강제 리다이렉션이 아닙니다. 주요 브라우저(Chrome, Edge, Firefox 기본 모드)는 이 권장 설정을 읽어들이지만, 대다수의 커맨드라인 도구와 일부 구형 소프트웨어는 이를 완전히 무시하고 자체 네트워크 라이브러리로 직접 연결을 시도합니다. 그래서 같은 PC에서 브라우저는 이미 프록시를 타고 있는데, 터미널의 curl은 여전히 직결로 실패하거나 성공은 하지만 프록시를 거치지 않는 상황이 생기는 것입니다.
첫 번째 갈래: 시스템 레벨 레지스트리와 네트워크 설정
이는 가장 기초적인 레이어로, 이 단계가 제대로 설정되지 않으면 이후 브라우저와 터미널 문제는 논의할 필요조차 없습니다.
Windows: 인터넷 옵션과 레지스트리 확인
시스템 프록시 스위치를 켜면 Clash는 현재 사용자의 HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings에 기록을 남기며, 핵심 필드는 ProxyEnable(1이어야 함)과 ProxyServer(Clash가 리스닝하는 주소와 포트를 가리켜야 하며, 보통 127.0.0.1:7890)입니다. "설정 → 네트워크 및 인터넷 → 프록시"에서 수동 프록시 설정이 Clash의 HTTP 포트와 일치하는지 직접 확인할 수 있습니다.
- 여기 표시된 주소와 포트가 비어 있거나 다른 소프트웨어가 남긴 예전 값이라면, 시스템 프록시가 Clash에 의해 제대로 인계받지 못한 것이므로 Clash에서 시스템 프록시 스위치를 다시 한번 눌러야 합니다.
- 주소와 포트가 모두 정확한데도 여전히 직결이라면, 문제는 시스템 레벨이 아닐 가능성이 크므로 개별 프로그램을 더 깊이 확인해야 합니다.
- 회사 도메인 정책이나 일부 보안 소프트웨어는 프록시 설정을 강제로 잠가서 재부팅마다 초기화시키는 경우가 있는데, 이때는 관리자에게 해당 레지스트리 항목의 쓰기 권한을 열어달라고 요청하거나 TUN 모드를 사용해 우회하는 것이 좋습니다.
macOS: 네트워크 서비스별 프록시 설정 확인
macOS의 프록시 설정은 전역이 아니라 각 네트워크 서비스(Wi-Fi, 이더넷 등)마다 별도로 걸려 있습니다. "시스템 설정 → 네트워크 → 사용 중인 서비스 → 세부 정보 → 프록시"를 열어 "웹 프록시(HTTP)"와 "보안 웹 프록시(HTTPS)"가 모두 체크되어 있고 주소·포트가 Clash의 로컬 리스닝 포트를 가리키는지 확인하십시오. 다중 네트워크 인터페이스나 여러 네트워크 서비스를 쓰는 경우 하나를 빼먹기 쉬운데, 특히 유선 연결과 Wi-Fi를 동시에 켜둔 상태에서 한쪽 서비스만 설정을 바꾸면 아무 소용이 없습니다.
두 번째 갈래: 브라우저가 시스템 프록시를 따르지 않는 이유
브라우저가 프록시를 타지 않는 경우는 보통 다음 네 가지 상황이며, 진단 우선순위대로 나열했습니다:
- 브라우저 자체가 독립적인 프록시 모드로 설정되어 있다. Firefox는 기본적으로 시스템 프록시를 따르지 않고 자체 "네트워크 설정"의 수동 구성을 사용하므로,
about:preferences에서 "시스템 프록시 설정 사용"을 직접 선택해야 하며, 그렇지 않으면 Clash를 어떻게 켜도 브라우저와는 무관합니다. - 프록시 관리형 확장 프로그램이 설치되어 있다. SwitchyOmega 같은 확장은 브라우저의 프록시 판단을 대신 관장하며, 시스템 프록시가 이미 Clash를 가리키고 있어도 확장 내부 설정이 "직접 연결"이거나 다른 주소를 가리키고 있다면 브라우저는 실제로 확장의 설정을 사용하게 됩니다. 이는 가장 놓치기 쉬운 충돌 유형이므로, 진단 시 우선 모든 프록시 관련 확장을 일시적으로 비활성화해 프록시를 타는지 확인한 뒤 확장 내부에서 별도 설정할지 결정하는 것을 권장합니다.
- 브라우저에 내장된 VPN이나 "보안 브라우징" 류 네트워크 가속 기능이 있다. 일부 브라우저(특히 중국산 브라우저)에 기본 탑재된 네트워크 가속 스위치는 시스템 프록시를 우회해 직접 연결을 시도합니다. 뭘 해도 프록시가 적용되지 않는다면 먼저 브라우저 자체 설정에서 이런 기능을 꺼보십시오.
- PAC 스크립트 모드 설정 오류. Clash가 고정 HTTP 프록시가 아닌 자동 설정 스크립트(PAC)를 사용하는 경우, 브라우저가 이 PAC 파일을 정상적으로 불러와야 합니다. 브라우저에서 PAC 주소(보통
http://127.0.0.1:<포트>/proxy.pac)에 직접 접속해볼 수 있는데, 열리지 않으면 PAC 서비스가 시작되지 않은 것이므로 고정 HTTP 프록시 모드로 바꾸는 것이 더 안정적입니다.
진단 순서 권장: 먼저 브라우저 자체의 "네트워크 진단" 기능을 쓰거나 규칙에 걸릴 것이 확실한 도메인에 직접 접속해서 Clash 클라이언트의 연결 패널에 해당 기록이 뜨는지 확인하십시오. 기록은 뜨는데 직결로 표시된다면 규칙이나 정책 그룹 문제이고, 아예 기록이 뜨지 않는다면 브라우저가 요청을 Clash에 전달조차 하지 않은 것이므로 위 네 가지 항목을 다시 확인해야 합니다.
세 번째 갈래: 터미널이 시스템 프록시를 따르지 않는 이유
터미널 환경은 가장 오해하기 쉬운 부분입니다—많은 사람이 시스템 프록시를 켜면 커맨드라인 도구도 자동으로 따라간다고 생각하지만, Linux와 macOS의 터미널 도구 체인은 기본적으로 GUI의 프록시 설정을 읽지 않고 **환경 변수**를 봅니다.
표준 환경 변수 목록
Unix 관례를 따르는 대다수 커맨드라인 도구(curl, wget, git, 패키지 매니저 등)는 다음 환경 변수를 읽습니다:
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:7891"
export no_proxy="localhost,127.0.0.1,.local"이 몇 줄은 현재 터미널 세션에서만 적용되며 창을 닫으면 사라집니다. 계속 적용하고 싶다면 ~/.zshrc, ~/.bashrc 또는 해당 셸의 시작 스크립트에 넣고 source로 한 번 적용해야 합니다. Windows의 명령 프롬프트와 PowerShell도 마찬가지로, $env:HTTP_PROXY, $env:HTTPS_PROXY로 현재 세션에 설정하거나 시스템 환경 변수에 영구적으로 기록할 수 있습니다.
흔히 빠지는 함정
- 대소문자 불일치. 일부 프로그램은 대문자
HTTP_PROXY만 읽고, 다른 프로그램은 소문자http_proxy만 읽으므로 안전하게 대소문자 둘 다 써두는 것이 좋습니다. - SOCKS와 HTTP 포트 혼동. Clash는 보통 HTTP 포트와 SOCKS5 포트를 동시에 리스닝합니다(혼합 포트 모드에서는 같은 포트). 환경 변수에서 프로토콜 헤더와 실제 포트 종류가 맞아야 하며, 프로토콜 헤더를 잘못 쓰면 프록시를 우회하는 게 아니라 바로 연결 실패로 이어집니다.
- Docker 컨테이너, SSH 세션 내 환경 변수는 독립적이다. 호스트에 프록시를 설정해도 컨테이너 내부나 원격 SSH 세션은 기본적으로 이를 상속하지 않으므로, 컨테이너/원격 환경에서 별도로 설정하거나
-e옵션으로 명시적으로 전달해야 합니다. - 패키지 매니저는 자체 설정 파일을 갖고 있다. 예를 들어 npm은
npm config set proxy로 별도 설정해야 하고, git은git config --global http.proxy가 필요합니다. 환경 변수가 제대로 설정돼 있어도 자체 설정 파일에 다른 값이 적혀 있으면 그 값이 환경 변수를 덮어씁니다.
| 도구 | 환경 변수 읽음 여부 | 추가 설정 필요 |
|---|---|---|
| curl / wget | 예 | 없음 |
| git | 아니오(기본값) | http.proxy 설정 항목 |
| npm / yarn | 아니오(기본값) | proxy / https-proxy 설정 항목 |
| docker CLI | 예(컨테이너 내부는 별도 설정 필요) | 컨테이너 환경 변수 또는 daemon.json |
| Python requests | 예 | 없음(표준 환경 변수 준수) |
TUN 모드: 특정 스위치에 의존하지 않는 대안
위 세 갈래를 항목별로 다 짚어봤는데도 특정 프로그램이 여전히 프록시를 타지 않거나, 환경 변수와 브라우저 확장을 하나하나 설정하고 싶지 않다면 더 근본적인 방법은 TUN 모드로 전환하는 것입니다. TUN 모드는 시스템에 가상 네트워크 인터페이스를 만들어 네트워크 레벨에서 모든 아웃바운드 트래픽을 가로채므로, 애플리케이션이 시스템 프록시 설정이나 환경 변수를 읽는지 여부에 더 이상 의존하지 않고 이론적으로 백그라운드 서비스, 게임 클라이언트를 포함한 거의 모든 네트워크 요청을 커버할 수 있습니다.
TUN 모드를 켜려면 일반적으로: 클라이언트를 관리자/root 권한으로 실행하고, 설정에서 tun 필드를 활성화하며, stack(예: gvisor 또는 system)이 현재 네트워크 환경과 호환되는지 확인해야 합니다. 켠 뒤에는 시스템 프록시 스위치를 꺼둔 상태로 두어도 되는데, 트래픽이 이미 더 하위 레벨에서 인계되었기 때문입니다. 둘을 동시에 켜도 보통 충돌은 없지만 겹쳐서 쓸 필요는 없습니다.
tun:
enable: true
stack: gvisor
auto-route: true
auto-detect-interface: true진단 흐름 정리
"시스템 프록시는 켜져 있는데 작동하지 않는" 상황을 만나면 이곳저곳 무작정 시도하기보다 다음 순서대로 확인하는 것을 권장합니다:
- 먼저 Clash 클라이언트의 연결 패널에서 해당 요청이 뜨는지 확인하십시오—뜨지 않는다면 트래픽이 아예 Clash에 전달되지 않은 것이니 시스템 프록시 설정이 제대로 됐는지부터 확인하십시오.
- 브라우저 문제는 프록시 관리형 확장과 브라우저 내장 네트워크 가속 기능부터 확인하십시오. 이 두 가지가 가장 쉽게 놓치는 원인입니다.
- 터미널 문제는 먼저 현재 세션에서 환경 변수가 적용됐는지 확인하고, 그다음 해당 도구가 환경 변수를 따르는지 아니면 별도 설정 파일이 필요한지 확인하십시오.
- 항목별 진단 비용이 너무 크거나 표준 프록시 로직을 따르지 않는 프로그램이 다수 존재한다면, 하나씩 맞추려 애쓰지 말고 바로 TUN 모드로 전환해 해결하십시오.
시스템 프록시, 브라우저 확장, 환경 변수, TUN 모드는 본질적으로 서로 독립적이면서도 겹쳐 쓸 수 있는 네 가지 트래픽 인계 방식입니다. 현재 문제가 어느 레이어에서 발생했는지 파악하면 클라이언트를 무작정 재시작하는 것보다 훨씬 효율적으로 진단할 수 있습니다.