이 가이드가 맞는 경우
Clash 계열 GUI에서 프로필을 불러오고 노드를 고를 수 있으며, Windows 설정 > 네트워크 및 인터넷 > 프록시에 Clash가 켠 주소(예: 127.0.0.1과 mixed-port 또는 HTTP 포트)가 보이거나, Clash 앱의 «시스템 프록시» 토글이 켜져 있다고 가정합니다. 그런데도 Chrome 주소창으로만 해외 사이트가 막히거나 지역이 안 바뀌면, 이 글의 범위에 들어옵니다. 반대로 모든 앱이 동시에 실패한다면 먼저 구독 링크 만료·노드 전부 타임아웃·규칙에서 DIRECT로 떨어지는지부터 보는 편이 빠릅니다. 규칙 전반이 궁금하면 YAML 규칙 분기 가이드와 함께 읽으면 «브라우저만 이상」과 «전역 이상」을 빨리 가릅니다.
Chromium 계열은 Windows에서도 시스템 프록시를 읽지만, 우선순위가 더 단계적입니다. 명령줄 플래그와 기업 정책, 일부 확장 프로그램·보안 제품이 앞서면 사용자가 보는 «프록시 켬»과 무관하게 패킷이 빠져나갑니다. Clash 입장에서는 로그에 DIRECT로만 찍히거나, 아예 브라우저 TLS 핸드셰이크 전에 끊기는 패턴이 섞여 나옵니다.
0단계: 증상을 세 덩어리로 나누기
아래 중 어디에 가까운지 메모해 두면 이후 단계에서 되돌아올 기준점이 됩니다.
- A. 완전 직행: Chrome만 ISP 경로로 나가 차단되거나, 지역 한정 콘텐츠가 그대로입니다. Edge는 정상인데 Chrome만 다르면 브라우저 측 우회 경로를 의심합니다.
- B. 프록시는 타는데 실패: 오류 페이지는 프록시·DNS·인증 쪽 메시지에 가깝고, Clash 로그에는 해당 도메인 요청이 잡힙니다. 이 경우 DNS fake-ip·Redir-Host와 노드 품질을 같이 봅니다.
- C. 간헐적으로만 이상: 프로필 동기화·정책 갱신·확장 업데이트 타이밍과 맞물리면 원인 후보가 여럿이라, 아래 순서대로 «한 번에 한 축만» 고정해 재현을 줄입니다.
시스템 프록시와 TUN의 역할 차이는 Clash TUN·시스템 프록시 총정리에 표로 정리되어 있습니다. Windows 11에서 Microsoft Store·UWP만 별도 이슈라면 UWP·localhost 루프백 글과 결이 비슷하지만, 일반 데스크톱 Chrome은 127.0.0.1 mixed-port에 정상 붙는 경우가 대부분입니다.
1단계: Clash와 Windows 시스템 프록시를 같은 축으로 맞추기
Chrome에 손대기 전에 Clash 쪽 기준을 고정합니다. 데스크톱 클라이언트에서 mixed-port(HTTP+SOCKS 공용) 또는 HTTP·SOCKS 포트가 무엇인지 확인하고, 시스템 프록시 토글을 켠 뒤 Windows 설정 화면에 동일한 127.0.0.1:포트가 반영되는지 봅니다. 방화벽·보안 제품이 로컬 루프백 포트를 가로막으면 Chromium이 먼저 실패하는 일이 있으므로, 같은 PC에서 Edge로 동일 사이트를 열어 재현을 나눕니다.
구독 링크가 깨졌거나 노드가 전부 끊기면 브라우저 종류와 무관하게 망가집니다. 먼저 Clash 로그에서 해당 요청이 DIRECT인지, 특정 정책 그룹을 타는지 확인하세요. 규칙 순서를 바꾼 직후라면 GEOIP·MATCH 위치가 의도와 다르게 먹혔을 수도 있습니다.
2단계: Chrome 설정에서 OS 프록시와의 관계 확인
Chrome 주소창에 chrome://settings/system을 열고, 컴퓨터 프록시 설정 열기로 Windows 설정으로 점프합니다. 여기서 수동 프록시가 꺼져 있거나 예전 주소가 남아 있으면, Clash가 토글로 심은 값과 어긋납니다. Clash를 껐다 켜거나 시스템 프록시 토글을 한 번 off→on 하면 레지스트리·설정 앱 값이 다시 맞는 경우가 많습니다.
Chrome 내부의 보안 DNS 사용(기존 «DNS over HTTPS» UI)이 켜져 있으면, 프록시는 타도 이름 해석 경로가 Clash DNS와 충돌해 «페이지만 안 열린다»처럼 보일 수 있습니다. 문제 재현 중에는 잠시 끄고 대조 실험을 권합니다. Firefox 편에서 다룬 DoH·프록시 상호작용과 논리는 같고, Chromium은 설정 위치만 다릅니다. 같은 맥락의 브라우저 대칭 설명은 Firefox·Clash TUN 6단계와 병행하면 이해가 빠릅니다.
3단계: chrome://policy·chrome://version·확장 프로그램
chrome://version의 «명령줄»에 --proxy-server=..., --no-proxy-server, --winhttp-proxy-resolver 류가 보이면, 그것이 시스템 프록시보다 앞섭니다. 바로가기 속성의 대상 필드나 작업 스케줄러·서드파티 «브라우저 최적화» 런처가 플래그를 붙인 경우가 많습니다. 플래그를 제거한 순수 chrome.exe 실행으로 A/B 테스트하세요.
chrome://policy에서 ProxyMode, ProxyServer, ProxyPacUrl 등이 표시되면 기업·학교 관리 정책 또는 로컬 정책 스텁이 우선합니다. 값의 «소스» 열을 확인하고, 개인 PC라면 동기화된 관리 계정·설치형 보안 에이전트를 의심합니다. 정책이 잠긴 상태에서는 UI로 풀리지 않으므로, 원인 프로그램을 제거하거나 IT에 예외를 요청해야 합니다.
VPN·광고 차단·프라이버시 확장은 자체 프록시나 필터를 삽입합니다. 시크릿 창(확장 기본 비활성)에서만 정상이면 확장을 하나씩 끄며 좁힙니다. 크로미움 기반 ChatGPT Atlas 등 별도 브랜드 브라우저를 쓰는 경우에도 동일한 점검 순서가 적용됩니다. 도메인 분기가 필요하면 Atlas·Clash 분기 글과 주제를 나눠 읽을 수 있습니다.
4단계: «현재 사용자» 설정 복원과 프로필 분리
Chrome 설정의 고급 > 초기화 및 정리 > 설정을 원래 기본값으로 복원은 북마크·비밀번호를 대부분 유지하면서 브라우저 측 프록시·일부 꼬인 플래그를 되돌리는 데 유용합니다. «캐시만 지우기»와 달리 네트워크 스택에 남은 사용자 선택을 건드리므로, 시스템 프록시는 정상인데 Chrome만 이상할 때 우선 순위가 높습니다.
그래도 재현되면 새 사용자 프로필로 실행해 보세요. 명령줄에 --user-data-dir=C:\path\to\clean-profile를 붙이면 확장·정책 캐시를 거의 비슷한 조건에서 분리할 수 있습니다. 깨끗한 프로필에서만 정상이라면 기존 프로필의 정책·확장·동기화 데이터를 의심합니다. 회사 디바이스에서는 관리 프로필 자체가 고정되어 있을 수 있습니다.
| 조치 | 유지되는 것 | 초기화되는 것 |
|---|---|---|
| 설정 복원(기본값) | 대부분의 로그인·북마크 | 일부 네트워크·홈·검색 관련 사용자 설정 |
| 새 user-data-dir | 기존 프로필과 완전 분리 | 깨끗한 상태에서 원인 분리에 유리 |
| 시작 매개변수만 정리 | 프로필 데이터 | 잘못된 --proxy-server 등 |
5단계: Clash TUN으로 브라우저 우회를 덮어쓰기
Clash TUN은 가상 어댑터와 라우팅 테이블을 통해 트래픽을 Clash에 넘깁니다. 그래서 Chrome이 시스템 프록시를 일부 무시하는 상황에서도 접속이 안정되는 경우가 많습니다. 다만 이미 잘못된 --proxy-server가 있으면 애플리케이션이 먼저 로컬 프록시에 붙으려 하므로, 3~4단계를 거친 뒤 TUN을 켜는 순서가 재현성이 좋습니다.
TUN을 켠 뒤 PC 전체 인터넷이 멈추면 TUN만 끄고 시스템 프록시만으로 Chrome이 살아나는지 확인하세요. 살아난다면 다른 VPN·가상 스위치·보안 필터와의 충돌 가능성이 큽니다. 자세한 체크리스트는 TUN 종합 가이드의 «전체 단절» 절차를 따르면 됩니다. DNS 모드가 fake-ip일 때 로컬 이름이 깨지면 fake-ip·Redir-Host 글에서 split tunnel·nameserver-policy를 함께 맞춥니다.
6단계: 바로가기에 --proxy-server를 명시적으로 심기
시스템 프록시·TUN을 모두 쓰기 어려운 환경(일부 관리 정책, 다른 VPN과의 공존 테스트 등)에서는, Chrome 바로가기 대상 끝에 프록시를 직접 박는 방법이 분명합니다. 예시는 Clash가 안내하는 로컬 포트에 맞춰 조정하세요.
- HTTP mixed-port를 쓸 때:
"C:\...\chrome.exe" --proxy-server=http://127.0.0.1:7890 - SOCKS5만 쓸 때:
--proxy-server=socks5://127.0.0.1:7891
이 방식은 «이 바로가기로 연 Chrome만» 해당 출구를 쓰므로, 디버깅·업무용 프로필을 나누기에 좋습니다. 반대로 포트를 바꾸고 바로가기를 업데이트하지 않으면 예전과 같은 «한 브라우저만 안 됨» 패턴이 반복됩니다. TUN을 최종적으로 켤 계획이라면, 안정화 후에는 시작 매개변수를 걷어 중복 경로를 없애는 것이 운영에 유리합니다.
장기적으로는 한 PC 안에서 한 가지 기준(예: 평소 시스템 프록시, 게임·특수 앱만 TUN)을 정해 두고 예외만 바로가기로 분리하면 혼선이 줄어듭니다. 클라이언트 설치와 채널 고정은 ClashNote 다운로드 페이지에서 한곳에 모아 두었습니다.
자주 묻는 질문
Windows에서 Chrome은 기본적으로 시스템 프록시를 따르나요?
일반 설치형 Google Chrome은 Windows의 사용자 프록시 설정을 따르는 것이 기본에 가깝습니다. 다만 --proxy-server·--no-proxy-server, chrome://policy의 ProxyMode 등, VPN·필터 확장이 우선하면 시스템 프록시와 무관하게 직행하거나 고정 출구로 나갈 수 있습니다.
Clash TUN을 켜면 Chrome에 --proxy-server를 꼭 넣어야 하나요?
아닙니다. TUN은 OS 라우팅 계층에서 트래픽을 Clash로 넘기므로 많은 경우 단독으로 충분합니다. 잘못된 시작 매개변수가 먼저 적용되면 오히려 실패하므로, chrome://version을 비운 뒤 TUN만으로 검증하고 필요할 때만 플래그를 추가하세요.
기업 정책으로 프록시가 잠기면 사용자가 설정만으로 못 푸나요?
관리 Chrome에서는 정책이 UI보다 우선합니다. chrome://policy에서 소스를 확인하고 IT 범위 내 예외를 요청해야 합니다. 개인 기기라면 동기화·서드파티 앱이 정책 스텁을 심은 경우도 있으니 설치 목록을 함께 봅니다.
마무리
Windows에서 Chrome과 Clash를 같이 쓸 때는 «OS 시스템 프록시», «Chrome 명령줄·정책», «확장·보안 제품», «Clash TUN»이 동시에 말을 걸 수 있습니다. 위 여섯 단계는 그 목소리를 한 축씩 줄여 가는 순서입니다. Chromium 스택은 겉으로 단순해 보여도 레이어가 많아, Firefox 편에서 다룬 about:config와 대응하는 «chrome:// + 시작 매개변수」 축을 기억해 두면 이후 트러블슈팅이 빨라집니다.
개발자 도구·패키지 매니저까지 한 PC에서 나누는 패턴은 개발자용 프록시 분기 글과도 이어집니다. 기술 칼럼에서 주제별로 읽으면 전체 그림이 잡힙니다.