1. 증상이 “반만 프록시”처럼 보일 때

대부분의 사용자는 테스트 페이지나 스트리밍에서만 이상 신호를 봅니다. 주소창 접속 줄은 선택한 노드 규칙을 따르는데 같은 탭 안의 QUIC 대상 자원만 현지처럼 깨져 보일 수 있습니다. 또는 안전 DNS 때문에 이름 해석이 프록시의 fake-ip 경로와 엇나가고, 결과적으로 특정 호스트 이름만 규칙 테이블에 안 잡힙니다. “Edge는 되는데 크롬만 아니다”는 조합이라면 크롬 내부 실험 플래그·브라우저 전용 설정· 확장 프로그램을 먼저 의심하는 편이 빠르고, UWP 루프백 예외가 필요한 저장소 앱 절차는 다른 문서입니다.

2. 시작 전: Wi-Fi·Ethernet과 Clash 상태를 한 줄로 확인

클라이언트 패널에서 시스템 프록시를 켰는지, mixed-port(또는 HTTP·SOCKS가 분리되어 있다면 해당 포트가 실제로 리스닝인지부터 적어 둡니다. 같은 기기 안에서 회사 SSO·방화벽·안티바이러스가 HTTPS 검사 또는 자체 PAC을 심어두면 레지스트리 기반 설정과 GUI가 다른 값을 들고 있어도 겉표시가 정상이라 착각할 수 있습니다.

3. 크롬이 ‘시스템’을 따라가도록

주소 표시줄에 chrome://settings/system 로 들어가 작업 장치 설정에서 프록시를 열도록 허용 과 OS 쪽 진입 버튼이 의도와 맞는지 확인합니다. ms-settings:network-proxy 또는 이전 패널의 인터넷 옵션 → 연결 → LAN 설정에서 같은 호스트 포트 문자열과 인증 상태를 점검합니다. Clash 클라이언트가 ‘시스템 프록시’ 또는 PAC를 작성하는 방식이 바뀌었는데 이전 문자열이 남아 있다면 문자 한 치이라도 새 기본 게이트웨이와 어긋납니다.

4. QUIC(HTTP/3) 줄을 끄기

UDP 기반 QUIC 줄은 종종 사용자 공간 리버스 프록시나 시스템 프록시 핸들과 같은 방식으로 잡히지 않습니다. chrome://flags/ 에서 QUIC 관련 항목(표기는 버전에 따라 다름. 예를 들어 QUIC 프로토콜 사용 중지 실험)을 찾아 끈 뒤 크롬 전체 종료 재시작을 합니다. 단기 진단이라면 레지스트리·전사 정책으로 제한되는 환경이 아닌 한 플래그 실험이 가장 즉시 재현 줄을 분리하기 쉽습니다. 대규모 사이트는 HTTP/3로만 일부 패치를 줄 때도 있어, 끊김이 남아 있으면 HTTP/3 강등 대비로 일반 새로고침과 캐시 삭제 순서까지 메모합니다.

5. 보안 이름 확인과 Clash DNS

크로미엄의 보안 DNS(DoT/DoH) 는 ‘사용 가능한 제공자’ 선택이나 제공자 무시 순서 때문에 OS 라운덜과 다르게 질의가 나가면, 패널에 찍히는 호스트 문자열 묶음과 페이지가 받는 결과가 어긋납니다. Clash 설정에 안전 DNS 과 fake-ip 블록이 동시에 켜져 있어야 한다는 신념 때문에 실제로는 앞줄 GEOIP 때문에 직접 연결 줄이 새는 경우와 혼동할 수 있습니다. 우선 제공자 선택을 비활성화하거나 “현재 서비스 공급자”로 바꿔 테스트해 보세요. 테스트 후 조직 허용 범위만 다시 활성화하는 순서가 안전합니다.

6. 확장 프로그램·기업 정책을 잠깐 거두기

프록시 전환형 확장(SwitchyOmega 등)과 핑거프린트 차단류는 자체 패치와 예외 패턴으로 시스템 프록시를 덮습니다. 모바일·원격 과제에서 정책으로 프록시를 주입했다면 레지스트리와 정책 JSON이 사용자가 보는 UI와 다른 값일 수 있습니다. 진단 순간에는 프로필에 설치 확장 숫자부터 줄임으로써 ‘반만 된다’는 체감을 빠르게 줄일 수 있습니다.

7. TUN 모드와 UDP 줄

시스템 프록시만 따를 때 QUIC이 독자 경로에서 튀더라도 TUN 모드를 켜면 인터페이스 수준으로 묶이는 예가 많습니다. 그 반대로 TUN까지 켠 뒤에도 문제가 재현된다면 해당 네임스페이스가 예외로 빠져 있거나, 사용자 공간 프로그램이 드물게 직연결 허용 패턴으로 태워지고 있어서 룰이 아니라 순서 검증부터 해야 할 수 있습니다. 일반 사용자면 “시스템 만 → TUN 보강 → 여전히 같으면 DNS· QUIC · 확장 순”이라는 순서 메모 하나가 반복 줄을 줄여 줍니다.

8. 테스트 방법을 단순화하기

여러 테스트 사이트를 동시에 띄워 비교하면 캐시·HTTP/3·지역 간선에 따라 결과가 분산됩니다. 한 탭씩 새 시크릿 창에서 동일 과정을 재현하면 확장 변수를 줄일 수 있습니다. 다만 테스트 자체 트래픽이 과금·과도한 속도 테스트로 이어지면 공급자 약관을 함께 확인하세요. 내부망 과제에서는 이런 공개 테스트도 필터링될 수 있습니다.

9. Clash 측 분류 규칙과 로그

연결 패널에서 테스트 중인 페이지의 호스트 문자열과 정책 이름을 같이 봅니다. 상단 줄에 놓아 둔 DOMAIN-KEYWORD 나 광역 GEOIP 가 의도하지 않게 DIRECT 를 먼저 맞히면 패널에서는 직연결 줄로만 깔끔히 보입니다. 패킷 줄이 QUIC에서만 깨져 보였다면 먼저 이 절까지 돌아가 §4 QUIC 전제를 재확인하는 편이 일관적입니다. 일반 문제 전체 순서 망라는 Clash 문제 해결 을 같이 놓습니다.

10. 동시에 다른 VPN이 깔려 있는 경우

상용 제품 또는 상관 없는 브러우저 제품까지 가상 어댑터를 남긴 상태에서는 라우팅 테이블이 자주 교체됩니다. 순서별로 해당 제품 종료 또는 부팅 순서 변경으로 비교 테스트해 보세요. 가정용에서도 부모링 제어 프로그램이 유사한 필터링을 하는 경우 앞장에서 가로막히는 줄이 크롬에만 해당하는 것처럼 보입니다.

11. 파이어폭스 실측 기사와 무엇이 다른가

Firefox 진영에서는 수동 SOCKS·프로필·about:config 과 TRR 줄이 깊숙하게 붙습니다. 크롬에서는 보안 이름 확인과 QUIC이 동일 축이라고 과대 일반화하기 어렵고, 운영체제 정책과 결합되어 보이는 패턴도 다릅니다. 두 브라우저를 같은 PC에서 쓰더라도 이 글의 순서만 따르지 말고 앱별로 출구 줄을 증명해 나가는 접근을 권합니다.

12. 안내

이 문서는 불법 회피를 조장하지 않으며, 허용된 범위에서 고객·조직 규칙 안에서 네임·추적·패치 줄을 진단하기 위한 절차입니다. 적용 전 약관·내부 보안 규칙과 관할 법령을 확인하세요.

13. 정리

크롬 은 QUIC·안전 이름 확인·실험 플래그가 겹치면 Clash 패널에 찍히는 줄과 페이지 인상이 순간적으로 불일치하는 일이 많습니다. Windows 시스템 프록시와 클라 문자열 숫자를 먼저 맞추고 QUIC을 끄며 DNS 줄을 줄인 뒤, 연결 기록과 정책 이름으로 교차 증명하는 실측 흐름이 가장 짧았습니다.

Mihomo 기반 Clash는 연결 문자열 패널과 DNS· 규칙 스택 을 같은 화면에서 다룰 수 있어 “Chrome만 다른 줄”이라는 패턴 확인에 시간을 덜 들이게 하는 편입니다. 유사 과제에서는 오픈소스 생태 안에서도 패널 제공 방식 차이보다 패킷 줄과 규칙 매칭이 일치했는지를 먼저 보는 패턴으로 정리되는 경우가 많습니다. → Clash 무료 받기 페이지에서 브라우저와 같은 축으로 시스템 프록시·로그 패널 설정을 시작해 보세요.