1. Firefox만 예외인 이유: 자체 네트워크 스택
많은 운영체제에서 “시스템 프록시 사용”을 켜면 Chromium·일부 네이티브 앱은 동일한 PAC·HTTP 프록시 핸들을 물려 받습니다. 반면 Firefox는 최상위 메뉴의 설정 → 일반 → 네트워크 설정에서 “시스템 프록시 설정 사용”과 “수동 프록시 설정”을 명시적으로 고를 수 있고, 선택이 프로필에 저장되어 재시작 뒤에도 남습니다. 한때 수동으로 넣어 둔 호스트·포트가 나중에 Clash에서 바뀐 Clash SOCKS5 포트와 다르면, 겉으로는 “프록시를 했는데 안 된다”로 보입니다. 또한 about:config의 network.proxy.* 계열은 UI와 동기화되지만, 실험 중인 토글을 직접 만진 뒤 UI만 되돌린 경우 값이 남아 있을 수 있어, 설정 화면만 보고 판단하기 어렵습니다.
첫 단계에서는 “지금 이 프로필이 진짜로 어떤 출구를 쓰는지”를 의심 목록으로 적고, 아래 순서대로 하나씩 제거해 가는 편이 빠릅니다. 공항 규칙이 헷갈리면 구독 가져오기와 규칙 병합부터 정리한 뒤 브라우저 쪽으로 넘어와도 됩니다.
2. 권장 점검 순서: 브라우저 → OS → Clash
- Firefox 추가 기능 관리에서 프록시·VPN·“보안·DNS”류 확장을 일시 비활성화하고 새 창에서 재현합니다.
- 설정 → 일반 → 네트워크 설정에서 “시스템 프록시 설정 사용”과 “수동 프록시” 중 무엇이 선택돼 있는지 확인하고, Clash가 노출하는 포트(
socks-port,mixed-port)와 숫자가 일치하는지 적습니다. - about:config에서
network.proxy.socks,network.proxy.socks_port,network.proxy.type,network.trr.mode등을 확인합니다. - Clash에서 TUN 모드를 켠 상태와 끈 상태(시스템 프록시만)를 번갈아 가며 동일 사이트에 접속해, Firefox 연결이 로그에 잡히는지 봅니다.
- 그래도 불분명하면 임시 새 프로필(
about:profiles)으로 같은 테스트를 반복해 “오염된 설정” 여부를 가릅니다.
3. 수동 프록시 vs 시스템 프록시: 숫자 한 칸 차이
Clash 계열 클라이언트는 종종 HTTP(S)와 SOCKS를 한 포트로 받는 mixed-port와, SOCKS 전용 포트를 동시에 엽니다. Firefox 수동 설정에서 SOCKS 호스트만 넣고 포트를 HTTP용으로 착각하면, 핸드셰이크가 실패하거나 다른 프로그램과 달리 페이지만 열리지 않는 식으로 증상이 갈립니다. 반대로 mixed-port에 SOCKS5를 지정해야 하는 필드에 잘못 넣은 경우도 있습니다. GUI에서 실제로 리스닝 중인 포트를 확인한 뒤, Firefox 쪽 SOCKS 열과 “HTTP 프록시” 열을 동시에 쓸지·SOCKS만 쓸지 정하세요. 가능하면 문서에 적힌 기본값을 믿기보다, 당일 실행 중인 설정 파일과 앱 상태를 기준으로 적는 습관이 안전합니다.
4. Clash SOCKS5와 Firefox의 맞물림
Clash SOCKS5는 TCP 기반 사이트 탐색에는 잘 맞지만, 브라우저가 기대하는 원격 DNS 해석 동작과 충돌하면 “이름은 풀렸는데 경로만 이상하다”는 느낌이 날 수 있습니다. Firefox에는 “SOCKS v5 사용 시 DNS도 프록시를 통해” 옵션이 있으며, 이는 about:config의 network.proxy.socks_remote_dns에 대응합니다. Clash 측 DNS(fake-ip, redir-host 등)와 브라우저가 보내는 질의 방식이 엇갈리면, 규칙은 맞는데도 특정 도메인만 실패하는 패턴이 나옵니다. 이때는 브라우저 옵션을 켜거나 끄는 실험과 함께, Clash 연결 패널에서 해당 FQDN이 어떤 정책으로 매핑되는지 함께 보는 것이 좋습니다.
5. TUN 모드와 Firefox: 시스템 프록시를 건너뛰는지
TUN 모드가 켜지면 OS 라우팅 테이블 쪽에서 트래픽이 가상 인터페이스로 끌려 가므로, 애플리케이션이 시스템 프록시를 무시해도 이론상 같은 출구로 묶이기 쉽습니다. 그러나 VPN이나 다른 TUN 제품과 동시에 켜면 표본이 흔들리고, 분할 터 스크립트가 Firefox 관련 경로를 예외로 두었을 때도 증상이 남습니다. “TUN 켜면 되고 프록시만으론 안 된다”면 우선 TUN 경로가 정상인지 확인한 뒤, Firefox가 여전히 예외인지를 나누어 보세요. 반대로 “TUN만 켜면 DNS만 이상하다”면 DoH 쪽을 다음 절로 넘깁니다.
6. about:config에서 먼저 보는 키
아래 목록은 진단용 출발점이며, 변경 전·후를 메모해 두는 것이 좋습니다.
| 키(예시) | 의미 | 메모 |
|---|---|---|
network.proxy.type | 프록시 사용 방식 | 0(사용 안 함), 1(수동), 2(PAC URL), 4(시스템 설정), 5(시스템 WPAD 등) 등과 연동됩니다. |
network.proxy.socks / network.proxy.socks_port | SOCKS 주소·포트 | GUI 수동 설정과 동일한 값이어야 합니다. |
network.proxy.socks_remote_dns | SOCKS 경유 DNS | 끄면 로컬 해석이 섞여 Clash fake-ip와 충돌할 수 있습니다. |
network.proxy.share_proxy_settings | 다른 프로토콜과 공유 | 혼합 환경에서 기대와 다른 출구로 갈 수 있어 점검 대상입니다. |
network.trr.mode | DoH(TRR) 동작 | 0~5 범위; 업스트림 문서와 조직 정책을 확인한 뒤 조정하세요. |
키 이름은 버전에 따라 폐기·대체될 수 있으므로, 최신 릴리스 노트와 Mozilla 문서를 함께 확인하는 것이 안전합니다. 임의 실험 대신 “새 프로필에서 기본값 대비 무엇이 바뀌었는지”를 비교하는 방법이 재발 방지에 유리합니다.
7. DNS over HTTPS(Trusted Recursive Resolver)와 프록시
Firefox의 DNS over HTTPS는 UX상 “보안 연결” 메뉴와 연결되어 있지만, 끄거나 전환해 두었어도 network.trr.* 계열이 남아 예전 업스트림을 볼 수 있습니다. DoH 트래픽이 시스템 프록시를 타지 않고 직접 나가면, 페이지 HTML은 프록시를 탔는데 이름 해석만 다른 경로로 간 것처럼 보일 수 있습니다. 조직망 정책에서는 DoH가 제한되기도 하니, “불법 우회”가 아니라 허용된 범위 안에서 DNS·프록시 일관성을 맞추는지 확인하세요. Clash의 DNS 섹션과 브라우저 DoH가 동시에 켜져 있으면, 어느 쪽이 우선인지 로그로 증명하는 편이 빠릅니다.
8. 확장 프로그램: SwitchyOmega·VPN 계열
프록시 전환 확장은 자체 PAC이나 직접 연결 규칙을 Firefox 안에 다시 심습니다. 내장 “시스템 프록시”보다 우선하는 경우가 많아, Clash를 켜도 특정 패턴만 직접 연결로 빠질 수 있습니다. VPN/안티트래킹 확장 중 일부도 프록시 스택을 건드립니다. 진단 때는 전부 끄고 기본 탭에서만 재현한 뒤, 필요한 것만 하나씩 다시 켜며 범인을 좁히세요. “한 번 설치해 둔 확장이 수년간 조용히 PAC을 유지한다”는 사례도 흔합니다.
9. OS 레이어: Private DNS·방화벽·다른 VPN
Android의 Private DNS, Windows의 타사 필터 드라이버, iCloud Private Relay나 상용 VPN이 동시에 올라가 있으면 Firefox만이 아니라 전체 스택이 흔들립니다. 다만 사용자 체감은 Firefox에서만 두드러질 수 있습니다. 다른 브라우저와 동일 사이트를 열어 차이를 보고, Clash 로그에 해당 세션이 찍히는지를 함께 확인하세요. 회사 단말이라면 MDM으로 고정된 프록시나 인증서가 있을 수 있어, 개인 설정만으로는 한계가 있는 경우도 있습니다.
10. Clash 측에서 확인할 것: 로그·모드·규칙
브라우저를 손보기 전에 Clash 코어가 실제로 트래픽을 받는지부터 확인합니다. 분류 규칙에서 테스트 중인 사이트가 DIRECT로 떨어지면 IP는 당연히 로컬 출구로 보입니다. GEOIP 상단 규칙이 의도치 않게 직결을 강제하는지도 함께 봅니다. 노드가 장애 중이면 “프록시를 썼는데 연결 거부”로 Firefox 타임아웃만 남기도 합니다. 일반적인 코어·포트 이슈는 Clash 트러블슈팅에서 먼저 거르는 것이 효율적입니다.
11. 새 프로필 테스트로 남은 설정 찌꺼기 제거
모든 단계를 거쳐도 증상이 남으면, 기존 프로필에 남은 사용자 스크립트·about:config 실험·기업 정책(policies.json)이 의심됩니다. about:profiles에서 깨끗한 프로필을 만들고 동일 PC·동일 Clash 상태에서만 비교 실험하면, 브라우저 내부 원인인지 OS·Clash 원인인지 빠르게 가를 수 있습니다. 깨끗한 프로필에서 정상이라면, 장기적으로는 중요 데이터를 내보낸 뒤 프로필을 재구성하거나 문제 토글만 선별 이관하는 편이 덜 고통스럽습니다.
12. Chromium·터미널 사례와의 차이
Chromium 계열은 OS 프록시를 상대로 더 단순하게 움직이는 편이고, 터미널은 HTTP_PROXY 환경 변수가 핵심인 경우가 많습니다. Firefox는 그 중간쯤에서 “프로필 단위 설정” 비중이 커서, 문서화되지 않은 개인 습관이 누적되기 쉽습니다. 이 글의 순서는 Firefox 사용자가 시스템 프록시와 Clash SOCKS5·TUN 모드를 동시에 다룰 때의 충돌을 줄이는 데 초점을 둡니다.
13. 준수 안내
이 문서는 불법적인 네트워크 우회를 조장하지 않으며, 조직이 허용한 범위에서 클라이언트·DNS·프록시 설정을 일관되게 맞추어 문제를 줄이는 기술적 절차를 설명합니다. 적용 전 서비스 약관·내부 보안 정책·관할 법규를 확인하세요.
14. 정리: Firefox 프록시 스택을 Clash 한 축에 맞추기
Firefox 프록시 문제의 대부분은 “브라우저 UI·about:config·DoH·확장” 중 하나가 Clash SOCKS5 또는 시스템 프록시 숫자와 어긋난 데서 시작합니다. TUN 모드를 켠 뒤에도 예외라면 DNS와 확장부터 의심하고, 로그로 실제 정책과 FQDN을 증명한 다음 규칙을 손보세요. 브라우저마다 설정층이 다르니, 한 번 맞춰 둔 패턴을 그대로 다른 앱에 복사하기보다 앱별로 출구를 검증하는 습관이 장기적으로 시간을 아낍니다.
Mihomo 코어를 포함한 클라이언트에서는 연결 기록과 프로필 전환을 한 화면에서 다루기 쉬워, “브라우저만 예외” 같은 증상을 빠르게 좁히는 데 유리합니다. 범용 프록시 앱과 비교해도, 분류·DNS·로그가 함께 있으면 원인을 덜 돌아가게 찾을 수 있습니다. → Clash를 무료로 내려받고 Firefox와 Clash SOCKS5·TUN 설정을 한 줄로 맞춰 보세요