Clash 전역 모드인데 브라우저만 되나요? Windows·macOS 시스템 프록시와 TUN 단계별 점검

“전역 모드”인데 왜 브라우저만 되나요?

Clash 계열 클라이언트를 켜 두고 Global(전역)이나 규칙 모드의 최종 폴백을 해외 노드로 두었는데도, 크롬·엣지·사파리 같은 브라우저만 매끄럽고 스팀 같은 게임 런처, 일부 데스크톱 앱, 마이크로소프트 스토어 계열 UWP 앱은 여전히 느리거나 접속 오류·지역 메시지를 띄우는 경우가 있습니다. 사용자 입장에서는 “전역이니까 전부 같은 길로 나갈 것”이라 기대하지만, 운영체제가 트래픽을 Clash 쪽으로 보내는 방식은 한 가지가 아닙니다.

핵심은 이렇게 정리할 수 있습니다. 시스템 프록시로 붙이는 앱과, OS 설정을 무시하고 직접 TCP/UDP로 나가는 앱이 섞여 있고, 또 다른 차원에서 TUN 모드가 켜져 있어야 IP 패킷 전체가 가상 인터페이스로 모이기도 합니다. 브라우저가 “된 것처럼” 보이는 이유는 대부분 시스템 HTTP/HTTPS 프록시 경로를 잘 따르기 때문이고, 나머지 증상은 프록시 미적용·권한 부족·별도 API 쪽에서 먼저 의심하는 것이 빠릅니다.

시스템 프록시와 TUN, 무엇이 다를까요?

시스템 프록시는 Windows·macOS에 기록된 HTTP/HTTPS(SOCKS가 함께 설정된 경우 포함) 프록시 서버 정보입니다. 이 값을 읽도록 만들어진 앱만 영향을 받고, 프록시 API를 쓰지 않는 실행 파일은 그대로 로컬 회선으로 직결을 시도합니다. 게임 anti-cheat·자체 네트워크 스택·백그라운드 업데이터 등이 여기에 해당하는 경우가 많습니다.

TUN 모드(Mihomo·Clash Meta 계열)는 가상 네트워크 인터페이스를 만들어 라우팅 테이블 상에서 잡히는 IP 트래픽을 Clash 커널로 끌어올립니다. 그래서 “전역에 가깝게” 모든 앱을 같은 규칙 엔진에 태우려면 TUN이 유력한 선택지가 됩니다. 다만 관리자 권한(Windows)·시스템 확장 승인(macOS) 등 OS 수준 요구가 늘고, DNS·tun.stack·다른 VPN과의 충돌은 별도로 다뤄야 합니다. 원리와 활성화 절차는 Clash TUN 모드 완전 가이드에서 깊게 다루고 있으니, 본문에서는 “브라우저만 될 때 TUN을 언제 의심할지” 위주로 이어갑니다.

전역 모드와 실제 트래픽 경로

UI에서 Global을 고른 것은 Clash 내부 규칙 해석의 문제이고, 동시에 OS에 “모든 패킷을 여기로 보내라”는 뜻은 아닙니다. 실제로는 (1) 시스템 프록시만 켜졌는지, (2) TUN까지 켜졌는지, (3) 구독 규칙에 DIRECT·국내 IP 예외가 과하게 많지 않은지가 동시에 맞아야 체감이 “진짜 전역”에 가깝습니다.

브라우저가 잘 되는데 특정 프로그램만 느리거나 지역 제한 메시지가 뜬다면, 먼저 대시보드나 로그에서 해당 연결이 어떤 아웃바운드로 분배되는지 확인해 보세요. Global인데도 DIRECT로 찍힌다면 도메인·IP 규칙·프로바이더 규칙셋 오류일 수 있고, 프록시로 나가는데도 앱이 반응이 이상하면 노드 품질·UDP 쪽을 같이 봐야 합니다.

Windows에서의 단계별 점검

1단계: 시스템 프록시가 실제로 켜졌는지

설정 앱의 프록시 항목이나, 클라이언트가 시스템 프록시 사용을 켠 상태인지 확인합니다. 일부 빌드는 트레이에서 토글만 바꾸고 OS 레지스트리/설정과 어긋나면 “Clash는 살아 있는데 브라우저만 간헐적으로 된다” 같은 혼선이 납니다. 클라이언트를 재시작하거나 “시스템 프록시 동기화”에 해당하는 메뉴가 있으면 한 번 눌러 맞춥니다.

2단계: WinHTTP·백그라운드 업데이트

일부 구성 요소는 IE/엣지와 다른 WinHTTP 스택을 씁니다. 브라우저와 무관하게 실패하는 백그라운드 업데이트가 있다면, 이 축을 의심해 볼 수 있습니다. 여기까지는 여전히 “프록시를 아는 쪽” 이야기이고, 게임 실행 파일처럼 아예 프록시를 읽지 않으면 다음 단계로 넘어갑니다.

3단계: UWP와 루프백 격리

마이크로소프트 스토어 앱(UWP)은 네트워크 격리 정책 때문에 localhost 기반 프록시나 특정 루프백 시나리오에서 동작이 달라질 수 있습니다. 증상이 스토어 앱에만 국한되면 “UWP 루프백(UWP loopback)” 관련 도구·개발자 설정을 검색해 환경에 맞게 허용 목록을 조정하는 흐름이 자주 언급됩니다. 신뢰할 수 있는 문서를 따르고, 불필요한 전역 허용은 피하세요.

4단계: TUN과 관리자 권한

시스템 프록시만으로 부족하다고 판단되면 TUN을 켠 뒤 다시 테스트합니다. Windows에서는 가상 어댑터·라우트 변경에 관리자 권한이 필요한 경우가 많고, 보안 소프트웨어가 드라이버 로드를 막으면 TUN이 조용히 실패하기도 합니다. UAC·방화벽·다른 VPN과의 병행 여부를 함께 점검하세요.

macOS에서의 단계별 점검

1단계: 시스템 설정의 프록시와 클라이언트 동기화

macOS도 시스템 설정 > 네트워크에 표시되는 HTTP/HTTPS/SOCKS 프록시와 Clash 클라이언트 상태를 맞춥니다. 메뉴 막대 아이콘만 보고 “연결됨”으로 오해하지 말고, 실제 체크박스가 켜졌는지 확인합니다.

2단계: 네트워크 확장·시스템 확장 승인

TUN 또는 패킷 필터 계열 기능은 네트워크 확장(Network Extension)·시스템 확장 승인이 필요합니다. 설정 앱의 개인정보 보호 및 보안에서 확장을 허용했는지, 재부팅 요구를 남겨 두지 않았는지 확인하세요. 승인이 빠지면 “브라우저만 우연히 된다”는 패턴과 겹쳐 보일 수 있습니다.

3단계: 샌드박스 앱·자체 인증서

앱스토어 샌드박스 앱이나 자체 TLS 검증을 하는 클라이언트는 시스템 프록시를 우회하거나 MITM 환경에서 오류를 냅니다. 이때는 규칙만 만지는 것보다 앱 설정에 프록시를 직접 입력하거나 TUN으로 아래 레이어에서 맞추는지 선택해야 합니다.

언제 TUN으로 넘어가야 할까요?

다음에 해당하면 시스템 프록시만으로는 설명이 부족해지고 TUN 점검이 다음 단계입니다. 첫째, 대상 프로그램이 OS 프록시를 명백히 무시한다. 둘째, UDP·VoIP·일부 게임 트래픽이 중요하다. 셋째, 동일 노드에서 브라우저 속도와 앱 속도 차이가 계속 난다. 넷째, 규칙 로그에 원하는 도메인이 아예 안 찍힌다.

TUN을 켠 뒤에는 DNS 모드(fake-ip 등)와 tun.stack 조합에 따라 “사이트만 안 열린다”는 부작용이 생길 수 있으니, TUN 가이드의 DNS·스택 절을 같이 보는 것이 안전합니다.

한눈에 보는 점검 순서

1. Clash UI에서 모드(Global/Rule)와 실제 선택된 아웃바운드, 로그의 DIRECT 여부를 확인합니다.
2. 시스템 프록시가 OS에 반영됐는지(Windows 설정·macOS 네트워크) 확인합니다.
3. 문제가 UWP·스토어 앱에만 있으면 UWP 루프백·격리 정책 축을 조사합니다.
4. 그래도 데스크톱·게임 바이너리가 직결이면 TUN을 켜고 권한·방화벽·다른 VPN 충돌을 제거합니다.
5. macOS는 네트워크 확장 승인과 재시작 안내를 다시 따릅니다.

마무리

“Clash 전역 모드인데 브라우저만 된다”는 말은, 대부분 시스템 프록시를 따르는 소프트웨어와 그렇지 않은 소프트웨어가 함께 존재하기 때문에 생깁니다. Windows는 UWP·WinHTTP·권한 이슈가 겹치기 쉽고, macOS는 네트워크 확장 승인과 샌드박스 앱이 변수가 됩니다. 같은 증상이라도 OS별로 우선 순위를 나누면 원인 좁히기가 훨씬 빨라집니다.

비슷한 용도의 도구들과 비교해 볼 때, Clash·Mihomo 생태계는 규칙과 로그로 원인을 설명하기 쉬운 편이라, 시스템 프록시와 TUN 중 어디까지 켰는지부터 정확히 맞춰 두면 재현과 조정이 수월합니다. 기본 대응을 마친 뒤 필요하면 문서·튜토리얼과 연결 규칙 글을 함께 보완해 보세요.

지금 환경에 맞는 클라이언트를 받아 순서대로 확인해 보시려면 Clash를 무료로 다운로드한 뒤, 시스템 프록시만으로 브라우저를 검증하고 필요할 때 TUN을 단계적으로 켜는 흐름을 권합니다. → 지금 바로 Clash를 내려받고 원하는 앱까지 같은 정책으로 맞춰 보세요.