왜 “시스템 프록시”를 끄고 브라우저만 Clash에 붙이나

회사 노트북이나 가족과 나누는 Windows·macOS 머신에서 Clash·mihomo로 해외 사이트만 열고 싶을 때, OS의 시스템 프록시를 켜 두면 Slack·Microsoft Teams·사내 VPN·빌드·패키지 매니저까지 한꺼번에 127.0.0.1 쪽으로 흘러가며 “어제까지만 해도 됐는데” 류 오류를 부르는 일이 흔합니다. 반대로 시스템 프록시를 끄고, Chrome과 Microsoft Edge에만 수동 프록시·PAC(자동 프록시 구성)·확장 기반으로 Clash가 듣는 mixed-port(또는 HTTP/SOCKS5 전용)를 지정하면, 브라우저만 규칙·노드에 맡기고 나머지는 직접 연결로 남기기 쉽습니다. 전 PC를 한 번에 태우는 TUN(시스템급) 모드나, Windows 전체 튜토리얼이 다루는 “시스템 프록시 ON” 루트와는 의도가 다릅니다—이 글은 애플리케이션(브라우저) 수준에만 훅을 거는 쪽에 초점을 맞춥니다. 기능 개요·용어는 문서 개요와 함께 보면 설정 화면명이 더 익숙해집니다.

이 접근이 맞는 전형은 “구글·지도·SaaS만 프록시, 사내 Git·RDP·로컬 장비는 직접” 같이 트래픽을 나누는 목적이 분명한 경우입니다. 다만 분류(규칙)·DNS·secure DNS가 뒤섞이면, 브라우저에서만 “IP는 나갔는데 SNI/해석이 어긋난다”는 증상이 남을 수 있으니, 아래 단계는 한 번에 한 레이어씩만 바꾸는 것을 전제로 합니다.

1단계: Clash 쪽—시스템 프록시 끄기·로컬 포트 확인

사용 중인 Clash 계열 앱(예: CFW, Verge, 기타)에서 시스템 프록시(System Proxy) 토글을 끕니다. 그다음 mixed-port 혹은 port(HTTP)·socks-port의 현재 값을 대시보드·트레이·YAML에서 다시 읽으세요. 예시로 7890이 자주 쓰이지만, 구독·템플릿마다 다른 숫자로 열려 있을 수 있습니다. 브라우저·확장에 넣는 모든 칸은 지금 이 프로필이 실제로 열고 있는 포트와 같아야 합니다.

SOCKS5로 붙을지 HTTP/HTTPS로 붙을지에 따라 클라이언트 입력란 이름이 갈립니다. mixed-port는 한 구멍에서 둘 다 받는 경우가 많아, Chrome의 “프록시 서버” 수동 설정에는 보통 HTTP 쪽 포트·프로필이 맞습니다. 반대로 앱·확장이 SOCKS5만 고른다면, 실제 SOCKS5를 받는 포트가 mixed인지, 분리된 socks-port인지 확인하세요. 프로토콜과 포트 쌍이 틀리면 “연결 거부”나 빈 응답이 한 번에 옵니다.

2단계: Windows—OS·IE 레거시·Edge 정책이 덮지 않게

Windows 10/11에서는 설정 → 네트워크 및 인터넷 → 프록시에 수동 프록시나 스크립트(PAC) URL이 켜져 있으면, 일부 앱이 그 값을 WinHTTP/WinINet 경로로 읽습니다. 시스템 전역을 쓰지 않겠다는 목적이라면, 여기는 꺼 두거나 “프록시 사용 안 함”이 분명한 상태로 맞춥니다. 그룹 정책이나 회사 MDM이 프록시를 밀어 넣는 PC라면, 브라우저 쪽만 바꿔도 백그라운드가 여전히 시스템 값을 따를 수 있으니, 관리자 가이드와 충돌이 없는지 먼저 확인하는 것이 안전합니다.

Edge는 “이 PC의 기본 프록시 설정 사용”과, Edge 자체(수동) 프록시가 서로 다릅니다. 브라우저만 Clash에 붙이려면 기본(시스템)은 전달하지 않는 쪽으로 두고, 로컬 프록시 항목에 127.0.0.1과 위에서 읽은 포트를 직접 넣는 패턴이 이해가 빠릅니다. (정확한 UI 문자열·위치는 빌드에 따라 약간 다를 수 있으나, 시스템과 브라우저 전용의 이원화라는 구조는 동일합니다.)

2′단계: macOS—“웹 프록시(HTTP)·SOCKS”를 브라우저/프로필에만

macOS 시스템 설정의 네트워크 → 세부정보 → 프록시에 전역으로 127.0.0.1을 넣으면, 터미널·일부 네이티브 앱까지 같은 길로 나가곤 합니다. “브라우저만”을 원한다면, 전역 프록시는 끄고, Chrome의 전용 User Data 디렉터리를 쓰거나(업무/개인 프로필 분리), 아래 확장·PAC 쪽에만 Clash 포트를 주입하는 식이 실무에 잘 맞습니다. 사파리는 시스템 프록시를 더 밀접히 따르는 편이므로, 크로스 브라우저로 동일을 기대하려면 각각 손봐야 합니다.

3단계: Google Chrome—고정·PAC·(선택) SwitchyOmega

Chrome은 자체로 세세한 프록시 UI를 최소로 두는 대신, 시스템을 따르며—우리는 시스템을 Clash에 맞기지 않기로 했으므로—보통 (1) --proxy-server= 같은 실행 인자로 프로필을 띄우거나, (2) PAC 파일(로컬 file:// URL 포함)로 “어떤 URL은 프록시, 나머지는 직접”을 적거나, (3) Switchy Omega 류 확장으로 상황별로 127.0.0.1:포트에 붙이는 셋 중 하나를 택합니다. (3)을 쓸 때는 시크릿 모드·다른 프로필에서 확장이 꺼진 채로 열리는지 주의하세요. “이 탭만 직접” 같은 기대는 확장 없는 윈도우에선 적용되지 않습니다.

PAC는 “도메인별로 DIRECT vs PROXY 127.0.0.1:포트”를 쓰는 작은 JavaScript입니다. Clash 쪽 분류(규칙)의 큰 흐름—예: 사내 *.company.local은 직접, 나머지는 PROXY—을 한 번 더 흉내 낼 수 있어, 브라우저만 미세 분기하고 싶을 때 유리합니다. 다만 두 겹이 되면 “왜 이 호스트는 여기로 갔지?” 디버깅이 어려워지므로, 간단한 PAC + Clash는 Rule/글로벌 중 하나만 복잡하게 가져가는 편이 낫습니다.

Chrome의 보안 DNS( secure DNS / DoH )를 공용 리졸버로 켜 두면, Clash fake-ip·코어 DNS와 다른 응답을 받을 수 있어, 이 글의 주제(브라우저만)와 관계없이 끊김·잘못된 지역이 생깁니다. 의심될 때는 일시 끄기 후 같은 재현이 있는지 비교해 보세요.

4단계: Microsoft Edge—프로필·“기본”과 “수동” 구분

Edge 사이드바·Copilot·쇼핑·계정 동기화는 일반 탭과 WebView2·백그라운드가 섞이며, Win11·Copilot·엣지 분류 글에서 말하듯 호스트가 흩어질 수 있습니다. “브라우저만 Clash”로 통일해도, 엣지가 시스템 대신 자체 프록시를 쓰도록 맞춰야 할 때가 있고, 프로필(직장·개인)마다 확장·정책이 달라 한쪽만 프록시가 켜진 것처럼 보이기도 합니다. 같은 엣지 프로필에서 주소와 프록시가 일관하는지 먼저 보는 것이 좋습니다.

5단계: Clash 분류(규칙)·DNS와 “브라우저만”의 정합

OS 시스템 프록시를 쓰지 않아도, Clash 규칙은 HTTP CONNECT·TLS 호스트를 그대로 봅니다. Chrome·Edge가 127.0.0.1:포트로만 나가도, 최종 목적지 SNI/도메인에 맞춰 DIRECT·REJECT·전략 그룹이 정해집니다. 분류가 “넓은 GEOIP”나 “MATCH가 너무 앞이 아닌가” 순서는 규칙 심화와 같고, fake-ip·DNS는 TUN 가이드의 DNS 절을 함께 읽는 편이 수월합니다. 브라우저만 프록시해도, DoH/시스템 DNS가 코어 DNS와 싸우면 “화면만 열리고 API는 실패” 패턴이 남습니다.

정리하면, (A) Clash가 듣는 포트·프로토콜 = (B) Chrome/Edge·확장에 적은 주소:포트 = (C) (선택) PAC의 PROXY 라인, 이 셋이 같은 전제를 공유하는지 먼저 맞추고, 그 다음에 도메인 규칙을 다루는 순서가 재현·지원이 쉽습니다.

흔한 꼬임: 확장, 프로필, 포트 숫자, 이중 TUN

첫째, 포트를 예전 구독에서 외운 숫자로만 쓰다가, 프로필 전환 뒤 mixed-port가 바뀌었는지 모르는 경우. 둘째, VPN·다른 프록시 앱이 시스템이나 가상 NIC에 손을 대고 있어, 브라우저는 127.0.0.1에 붙는 척하지만 다음 홉이 뒤엉킨 경우. 셋째, TUN을 켠 채 브라우저 수동 프록시까지 겹쳐 이중으로 태우는 경우—증상이 “가끔만” 나와 원인이 잘 안 잡힙니다. 한 레이어씩 끄고 다시 켜며 비교하세요. 넷째, 광고 차단·HTTPS 전역 필터 확장이 일부 도메인을 가로막아 Clash 로그와 어긋난 “타임아웃”이 나는 경우—확장 끄기로 A/B를 권합니다.

전 PC(TUN/시스템 프록시) 가이드와의 관계

Windows 전체·TUN·시스템 프록시 ON 흐름은 동일 코어를 쓰지만, “모든 Win32/스토어 앱이 같은 출구”를 쓰게 맞추는 데 가깝고, 이 글의 “Chrome·Edge만”은 훅이 브라우저 스택에만 닿습니다. 요구에 따라 둘 중 하나를 기본 전제로 잡는 것이 좋고, 문서·지원팀에 설명할 때도 “TUN(전 PC) / 시스템 프록시 / 브라우저 수동”을 섞지 않는다고 말로 고정해 두면 혼선이 줄어듭니다.

한 장 체크리스트

  1. Clash에서 시스템 프록시 끄기, mixed-port·HTTP·SOCKS 실제 수치 기록
  2. OS 프록시 화면(윈/맥)이 꺼져 있거나 이 시나리오와 충돌 없는지
  3. Chrome·Edge 각각, 같은 프로필에서 수동/PAC/확장 중 하나를 기준으로 통일
  4. 127.0.0.1 프로토콜+포트가 mixed / HTTP / SOCKS 구분과 맞는지
  5. 보안 DNS(DoH)·시스템 DNS와 Clash DNS 의도한 단일 전제
  6. 규칙(분류) 순서·fake-ip가 의도한 전략 그룹을 타는지
  7. TUN·타 VPN·브라우저 수동의 이중 여부

맺음: 가벼운 훅이 요구에 맞을 때

사무·교육·공용 PC에서 브라우저만 Clash 뒤에 두는 방식은, OS 시스템 프록시를 건드리지 않고 협업·빌드·사내툴의 직접 경로를 지키는 데 잘 맞습니다. Chrome·Edge의 수동·PAC·(선택) 확장은 각각 프로필·빌드에 민감하니, “한 번 맞췄다”가 프로필 전환 뒤에도 그대로인지를 주기적으로 확인하는 습관이 있으면 반복 사고를 줄이기 쉽습니다. 분류(규칙)·DNS 쪽은 브라우저 경로만 바꿔도 똑같이 적용되며, 전 PC 가이드와 상호 보완으로 읽을 때 그림이 가장 또렷해집니다. 여러 클라이언트·프로필을 쓰는 팀에서도, 로컬 포트와 전략 그룹을 한 표에 적어 공유해 두면 온보딩 비용이 줄어듭니다. 같은 목적의 툴 가운데 Clash 계열은 규칙과 로그를 한꺼번에 보려는 사용자에게 익숙한 선택이 되는 경우가 많습니다.

→ Clash 공식 클라이언트 무료 다운로드 — mixed-port와 시스템 프록시·DNS를 먼저 맞춘 뒤, Chrome·Edge 쪽 수동 프록시나 PAC만 한 가지씩 바꿔 가며 다시 열어 보시면, 흰 화면만 남는 탭이 줄어드는 감이 납니다.