증상부터: 다른 앱은 되고 Firefox만 이상?

macOS나 Windows에서 Clash류 클라이언트로 시스템 프록시 또는 TUN/가상 어댑터를 켠 뒤, 동일 기기에서 Safari·Edge 등은 접속되는데 Firefox만 속도 지역이 다르거나, IP 확인 페이지에서만 나머지 앱과 다르게 나온다면 먼저 이중 프록시 여부부터 걷어냅니다. 전용 브라우저 확장(SwitchyOmega 등)과 Clash 동시 적용 패턴은 Clash와 SwitchyOmega 동시 사용 시 이중 프록시·루프 글 범위이고, 이 글은 확장을 끈 순정 프로필만 다룹니다. 확장이 꺼진 상태라도 예전 PAC URL이나 로컬 127 순환은 남을 수 있습니다.

Firefox만 다르게 보일 때 많은 사람이 규칙 YAML부터 만지지만, 증상이 「DNS 이름은 국내로 가고 TCP만 프록시」처럼 갈린다면 Clash 쪽 라우팅 이전에 Firefox가 DNS 요청 자체를 DoH 채널로 보냄으로써 사용자가 기대하는 경로와 엇나가는 패턴입니다. 코어 레벨에서는 Meta DNS 설정(nameserver·fallback·fake-ip-filter)로 정렬해 두었는지부터 상위에서 맞추고, 브라우저만 남아 있으면 이 글의 Firefox 단계와 짝으로 보시면 분석이 줄어듭니다.

직연으로 보일 때 우선 헷갈리는 두 축: TCP 프록시 vs DNS(DoH)

HTTP(S)·SOCKS 프록시 설정은 해당 연결의 TCP가 로컬 Clash 미러 포트를 타는지만 결정합니다. 반면 이름 해석 단계에서 Firefox가 DNS over HTTPS(DoH) 제공자까지 붙으면 브라우저 내부에서 질문이 끝나며, 결과 IP 분기와 나머지 앱 행렬이 어긋날 수 있습니다. 「프록시를 썼는데도 페이지가 현지 DNS 기준처럼 보인다」는 체감이라면 이름 계층을 끄고 차만 다시 겹쳐 보는 과정으로 좁히는 게 안전합니다. 시스템 전체에서는 fake-ip 증상이 섞였는지까지 보려면 규칙 분류 모범 맥락의 DNS 축 설명과도 연결됩니다.

IPv6 이중 스택에서도 이름 해석 분기만 달라질 때가 많습니다—IPv6와 DNS 분리 실측 안내와 같이 놓으면 단일 원인이라고 급하게 결론 내리지 않기 쉽습니다. Firefox에서는 TRR(TRusted Recursive Resolver)과 network.trr.mode 줄이 많이 등장합니다.

설정 및 about:config에서 DoH(TRR) 비활성화

설정 ▸ 일반 ▸ 네트워크 설정 또는 DNS 블록에 따라 도착 버전마다 차이 나지만, DoH 제공자 사용을 끄거나 기본 DNS로 두는 선택지가 있으면 먼저 해제 후 한 번 테스트합니다.

부족하면 about:config에서 우선 순서 없이 줄 이름만 패널 검색창으로 훑으며 다음을 포함해 조정합니다(변경 전 값은 스크린샷 또는 메모). 대표 줄: network.trr.mode는 빌드 문서에 맞춰 완전 끔 쪽 숫자로 맞추고, network.trr.uri에 외부 DoH 템플릿이 남았는지까지 확인합니다. 숫자 enum은 Firefox 메이저마다 허용치가 바뀌므로 해당 버전 표를 한 번 교차 검증해야 합니다. 재시작이나 새 창으로 테스트하는 게 안전합니다.

사내 디바이스는 그룹 정책·배포 프로필로 동일 줄이 재적용되는 경우도 있음을 잊지 마세요.

manual·PAC·타입별 network.proxy 잔류 점검

설정 ▸ 일반 ▸ 네트워크 설정에서 우선 시스템 프록시 설정 사용 한 번 선택합니다. 이전에 수동 프록시, PAC URL, 자동 검출(WPAD)을 오래 붙였다면 about:config에 문자열 줄이 많이 남습니다. 특히 network.proxy.type(0 시스템·1 수동·2 PAC·등)과 함께 network.proxy.http, network.proxy.ssl, SOCKS 관련 줄이 예전 종단값을 들고 있는지 확인하고, 필요하면 비우거나 초기 상태로 줄입니다.

코어 게이트웨이의 HTTP 미러 포트와 SOCKS 라벨 혼선이면 순정 Firefox까지 가기 전부터 충돌이 납니다—클라이언트 쪽 종류 선택은 플랫폼별 Clash 클라이언트 고르기 참고입니다. 순정만 쓰는 경우 브라우저 내부 수동 줄이 우선이라면 원하는 종단까지 도달하지 못한 「겉으로는 프록시 켠 것 같은데 실제 패킷은 다른 문」 상태가 재현되기도 합니다.

TUN처럼 OS 레벨 처리가 포함되면 증상이 또 다릅니다—스택 이해 보조용으로는 TUN 모드 심층을 같이 놓습니다. 종료했는데만 시스템 레지스트리나 환경설정에 프록시가 남아 전체 접속 불가처럼 변하면 Clash 종료 후 시스템 프록시 잔류 정리 단계부터 점검합니다.

Captive 포털·연결 상태 검사가 섞일 때

공항망처럼 검사 때문에 연결 테스트만 반복 빌드되어 브라우저 간 스택 차이만 드러나는 패턴도 있습니다. 패널에서 captive 등을 검색해 관련 줄이 있으면 시험용 프로필에서만 잠깐 꺼 보고 재현 차이가 있는지 비교합니다.

IP 표시가 다르다면 WebRTC·실제 IP 우회 검사도 동시 확인하는 편이 좋습니다.

복구 순서 체크리스트(복붙 가능)

많이 밟는 순서를 그대로 적습니다.

  1. 확장으로 프록시 잡던 것이 있으면 끄거나 비활성화해 순정만으로 재현.
  2. 설정 패널에서 시스템 프록시 설정 사용.
  3. 설정/UI에서 DoH 쪽 비활성.
  4. about:config에서 TRR 줄 (network.trr.mode 등)과 network.trr.uri 확인.
  5. network.proxy*: type·포트 줄이 원하는 상태인지 초기화.
  6. about:profiles로 임시 프로필 새로 만들어 깨끗한 상태와 비교.
  7. TUN/OS 차원 논점은 연결 패널·별도 글로 크로스 체크.

한 줄 바꿀 때마다 동일 테스트 URL 두세 개 결과만 줄지어 적어도 교차 원인이 줄어듭니다.

맺음말

Firefox만 Clash 흐름과 다르다면, 증상이 단순히 「규칙이 깨져서」가 아니라 TCP 종단 선택과 이름 종단 선택(DoH 포함) 두 축이 합친 패턴일 수 있습니다. 순정 프로필에서 DoH·network.proxy 순서부터 정렬해 보세요.

패키지는 한 경로 정리되어 있는 공식 페이지에서 받는 편이 좋습니다. → 공식 페이지에서 Clash V.CORE를 무료로 받고 시스템 프록시·Firefox 프로파일 테스트를 순서대로 마쳐 보세요.