이 가이드가 맞는 경우
이미 Clash 계열 GUI에서 노드를 고를 수 있고, 같은 기기의 다른 브라우저(Chrome·Edge·Safari 등)에서는 원하는 대로 분기된다고 가정합니다. 문제의 핵은 «Firefox만 예외적으로 동작한다»는 점입니다. YAML 규칙 전반이 궁금하면 규칙 분기 가이드와 병행해 읽으면, 노드는 맞는데 브라우저만 어긋나는 상황을 더 빨리 가릴 수 있습니다.
Firefox는 Chromium 계열과 달리 자체 네트워크 설정과 about:config에 강하게 의존합니다. Clash가 OS에 시스템 프록시를 심었어도, Firefox가 «시스템 설정 사용»이 아니면 그 신호를 무시합니다. 반대로 브라우저에만 수동 프록시를 넣어 두고 Clash에서 TUN과 시스템 프록시를 동시에 만지면, 어떤 경로로 패킷이 나가야 할지 애매해져 TLS 오류·끊김처럼 보이기도 합니다.
0단계: 증상을 두 덩어리로 나누기
먼저 아래 중 어디에 가까운지 적어 두세요. 이후 단계에서 되돌아오는 기준점이 됩니다.
- A. 완전 직행: Firefox 주소창에 해외 사이트를 넣었을 때 ISP 경로로 나가 차단되거나, 지역 한정 페이지가 그대로 보입니다. 개발자 도구 네트워크 탭에서 연결 대상 IP가 예상과 다르게 보이는 경우도 포함합니다.
- B. 프록시는 타는데 실패: 연결은 프록시 쪽으로 가는데 인증 오류·타임아웃·DNS_PROBE만 반복됩니다. 이 경우 Clash 로그와 Firefox의 DNS 설정(DoH, «DNS를 프록시를 통해 전달»)을 같이 봐야 합니다.
A라면 «Firefox가 시스템 프록시를 안 읽는다» 쪽을 먼저 보고, B라면 «출구 노드·DNS·규칙» 쪽을 Clash에서 좁히는 순서가 맞습니다. TUN과 시스템 프록시의 역할 차이는 TUN·시스템 프록시 총정리에서 표로 정리해 두었으니, 개념이 헷갈릴 때 한 번만 훑어도 이후 단계가 수월합니다.
1단계: Clash에서 포트·시스템 프록시 스위치 확인
Firefox에 손대기 전에 Clash 쪽 기준을 고정합니다. 대부분의 데스크톱 클라이언트는 mixed-port(HTTP+SOCKS가 같은 포트) 또는 HTTP 포트와 SOCKS 포트를 나눕니다. 시스템 프록시 토글을 켜면 Windows·macOS의 시스템 설정에 그 포트가 반영되는지 확인하세요. 여기서 포트가 꺼져 있거나, 방화벽이 127.0.0.1의 해당 포트를 막으면 Chromium은 자체 정책으로 살아남아도 Firefox는 실패할 수 있습니다.
구독 링크가 만료되었거나 노드가 전부 타임아웃이면 브라우저 종류와 무관하게 망가집니다. 먼저 같은 Clash에서 Chrome으로 동일 사이트를 열어 재현 여부를 나누세요. Chrome만 된다면 이 글의 범위에 들어오고, 둘 다 안 되면 구독·노드·규칙 모드부터 다시 보는 편이 빠릅니다.
DIRECT로 찍히는지, 프록시 체인에 올라오는지부터 확인하면 «Firefox 설정 문제」인지 «규칙 문제」인지 한 번에 갈립니다.
2단계: Firefox 설정 > 일반 > 네트워크 설정
설정 화면에서 일반 패널 맨 아래 네트워크 설정의 «설정…»을 엽니다. 여기서 선택지는 실질적으로 세 가지 축입니다. (1) 시스템 프록시 설정 사용 (2) 수동 프록시 설정 (3) 프록시 없음입니다. Clash가 시스템 프록시를 켜 두었다면, Firefox는 (1)이 가장 자연스럽습니다. 그런데도 직행이면 (2)로 과거에 박아 둔 주소가 남았거나, 반대로 기업 정책·프로필 동기화로 (3)이 강제된 경우를 의심합니다.
수동으로 넣을 때는 Clash가 안내하는 127.0.0.1과 SOCKS5 포트를 정확히 맞추세요. HTTP 프록시 칸만 채우고 HTTPS는 비워 두면, 혼합 콘텐츠·HSTS 사이트에서 이상 증상이 날 수 있습니다. «모든 프로토콜에 이 프록시 사용» 옵션을 켜면 실수로 HTTP만 타는 경우를 줄일 수 있습니다. Windows에서 Microsoft 계정 앱과의 상호작용은 UWP·localhost 루프백 이슈와 결이 비슷하지만, Firefox는 일반적으로 데스크톱 브라우저로 127.0.0.1에 잘 붙습니다. 붙지 않을 때는 보안 제품의 애플리케이션 방화벽을 의심합니다.
3단계: about:config에서 프록시 타입 고정 해제
주소창에 about:config를 입력하고, 경고를 통과한 뒤 다음 키를 검색합니다. 값이 사용자 프로필에 오래 남아 있으면 GUI의 «시스템 프록시 사용»과 충돌합니다.
network.proxy.type— Mozilla 기준 0은 프록시 없음, 1은 수동, 2는 PAC URL, 4는 시스템 프록시 설정 사용, 5는 WPAD 자동 검색입니다. OS의 시스템 프록시를 그대로 따르게 하려면 4가 맞는지 확인하세요. 혼란이 있으면 백업 후 사용자 값을 지우고 Firefox를 재시작해 기본값으로 되돌린 다음, GUI에서 «시스템 프록시 설정 사용»만 다시 고르는 방법이 안전합니다.network.proxy.socks,network.proxy.socks_port— 수동 SOCKS 호스트가 남아 있으면 시스템 프록시와 무관하게 SOCKS로만 나갑니다. Clash 포트를 바꿨는데 여기 숫자가 옛날이면 전형적인 «한쪽만 안 됨» 패턴이 됩니다.network.proxy.share_proxy_settings— true면 모든 프로토콜에 동일 프록시를 씁니다. 분기 테스트 중이라면 의도적으로 false로 쪼개 둔 흔적이 없는지 확인합니다.
기업용 Firefox나 정책 프로필을 쓰는 경우, 일부 키가 잠금(locked)되어 있을 수 있습니다. 그때는 about:policies 페이지에서 관리자 정책을 확인해야 하며, 개인 사용자라면 동기화된 다른 기기에서 잘못된 프록시 설정이 내려온 경우도 있습니다.
4단계: SOCKS5만 쓸 때와 시스템 프록시만 쓸 때의 순서
둘 중 하나를 주 경로로 정하면 디버깅이 쉬워집니다. 시스템 프록시만 쓸 계획이라면 Firefox를 시스템 설정 따르기로 두고, Clash의 시스템 프록시 토글만으로 on/off를 맞춥니다. 이 구성은 «브라우저는 OS가 알려 준 프록시를 신뢰한다»는 전제이므로, OS 자체가 프록시를 잃어버리면 Firefox도 같이 망가집니다.
SOCKS5만 브라우저에 직접 줄 계획이라면 Clash 쪽 시스템 프록시는 잠시 끄고, Firefox 수동 설정에 127.0.0.1과 SOCKS 포트만 넣어 A/B 테스트해 보세요. 이때 network.proxy.socks_remote_dns를 true로 두면 DNS 쿼리도 프록시 쪽으로 올라가 지역 노출을 줄일 수 있지만, Clash의 DNS 모드(fake-ip 등)와 맞물리면 «이름은 되는데 페이지만 안 열린다»가 될 수 있으니 fake-ip·DNS 글과 함께 보는 것이 좋습니다.
| 구성 | 장점 | 주의 |
|---|---|---|
| 시스템 프록시만 | 브라우저 설정이 단순하고, OS와 동작이 일치 | Firefox가 시스템을 안 따르면 즉시 직행 |
| Firefox에 SOCKS5만 | Clash 포트만 맞으면 Chromium과 독립적으로 검증 가능 | 포트·DNS·HTTP/HTTPS 혼합 시 오설정 빈번 |
| TUN + 브라우저 기본 | 프록시 미인지 트래픽도 규칙으로 끌어올리기 쉬움 | 다른 VPN·필터와 충돌 시 전체 단절 가능 |
5단계: Clash TUN을 켤 타이밍과 Firefox의 관계
Clash TUN은 가상 NIC을 통해 라우팅 계층에서 트래픽을 가로채는 방식이라, Firefox가 시스템 프록시를 무시하는 성향이 있어도 많은 경우 접속이 정상화됩니다. 다만 이미 Firefox에 잘못된 수동 프록시가 들어 있으면, TUN이 잡기 전에 브라우저가 127.0.0.1의 엉뚱한 포트로 먼저 붙으려 해서 오류가 날 수 있습니다. 권장 순서는 (1) Firefox 네트워크 설정을 시스템 따르기 또는 프록시 없음으로 단순화 (2) Clash에서 시스템 프록시로 한번 검증 (3) 필요 시 TUN을 켠다 입니다.
TUN을 켠 뒤 갑자기 PC 전체 인터넷이 멈추면, TUN만 끄고 시스템 프록시만으로 Firefox가 살아나는지 확인하세요. 살아난다면 원인은 TUN 스택·DNS hijack·다른 VPN과의 충돌 쪽에 가깝습니다. 이때 세부 점검표는 앞서 인용한 TUN 종합 가이드의 «전체 인터넷이 안 될 때» 절차를 그대로 밟으면 됩니다. 반대로 TUN을 켰는데도 Firefox만 이상하다면, 브라우저 프로필의 확장·DoH·사내 PAC가 남아 있는지 6단계로 넘어갑니다.
6단계: DNS over HTTPS·확장·보안 소프트웨어
Firefox는 Chromium보다 DoH UI가 앞에 나와 있어, 사용자가 켜 둔 DNS over HTTPS가 Clash의 DNS(fake-ip, redir-host 등)와 겹치면 이상한 증상이 납니다. 설정에서 네트워크 설정 아래의 DNS 항목을 확인하고, 문제 재현 중에는 잠시 «기본값 사용»으로 돌려 대조 실험을 하세요.
광고 차단·VPN형 확장·프라이버시 스위트는 자체 프록시나 필터를 삽입합니다. 시크릿 창(확장 비활성)에서만 정상이라면 확장을 하나씩 끄며 원인을 좁히면 됩니다. 마지막으로 백신·엔드포인트 보안 제품의 «브라우저 보호» 기능이 로컬 프록시를 간섭하는 사례도 있으므로, 테스트 세션 한정으로 예외를 두거나 해당 모듈을 잠시 끄고 Firefox만 다시 확인합니다.
자주 묻는 질문
Chrome은 되는데 Firefox만 직행하는 이유는 무엇인가요?
Firefox는 기본적으로 OS의 시스템 프록시를 따르지만, 설정에서 수동 프록시·SOCKS만 지정했거나 about:config의 network.proxy.type 등이 고정되어 있으면 Clash가 켠 시스템 프록시와 무관하게 동작합니다. 또한 DNS over HTTPS(DoH)나 확장 프로그램이 경로를 바꿀 수 있습니다.
Clash TUN을 켜면 Firefox 설정을 다시 손볼 필요가 있나요?
TUN은 OS 라우팅 계층에서 트래픽을 끌어당기므로, Firefox가 시스템 프록시를 무시하더라도 많은 경우 접속이 복구됩니다. 다만 브라우저에 수동 HTTP 프록시만 넣고 TUN과 포트가 어긋나면 이중 경로·루프로 실패할 수 있어, 우선 Firefox를 시스템 설정 따르기로 두고 TUN을 켜는 순서를 권장합니다.
SOCKS5만 브라우저에 넣으면 Clash 시스템 프록시는 끄나요?
둘 다 켜도 되는 경우가 많지만, 혼선을 줄이려면 한 축을 기준으로 잡는 편이 낫습니다. SOCKS5만 쓸 때는 Clash의 mixed-port 또는 SOCKS 포트와 호스트(보통 127.0.0.1)를 맞추고, 원격 DNS(network.proxy.socks_remote_dns) 여부를 결정해야 합니다. 시스템 프록시만 쓸 때는 Firefox가 그 설정을 읽는지부터 확인하세요.
마무리
Firefox와 Clash를 같이 쓸 때는 «같은 포트를 누가 주장하느냐»가 핵심입니다. OS의 시스템 프록시, 브라우저의 수동 설정, about:config의 잔존 값, 그리고 Clash TUN이 동시에 말을 걸면 사용자 입장에서는 단순히 «Firefox만 안 된다»로 보입니다. 위 여섯 단계는 그 목소리를 하나씩 줄여 가는 순서입니다.
장기적으로는 한 기기 안에서 한 가지 기준(예: 평소는 시스템 프록시, 스트리밍·게임만 TUN)을 정해 두고, 예외가 필요할 때만 Firefox 프로필을 분리하는 방식이 운영 부담을 줄입니다. 클라이언트 설치와 버전 고정은 ClashNote 다운로드 페이지에서 한곳에 모아 두었습니다.
다른 앱·IDE 트래픽을 분리하는 패턴은 개발자용 프록시 분기 글과도 연결됩니다. 기술 칼럼에서 주제별로 이어 읽으면 전체 그림이 잡힙니다.