백화점·공항 WiFi 인증이 Clash 켜면 안 열릴 때: 캡티브 포털, 분할, 직접(DIRECT), 시스템 프록시·TUN

캡티브 포털이란, 왜 Clash랑 잘 엇갈릴까

쇼핑몰·백화점·공항·호텔·기차역처럼 무료 WiFi에 붙으면, 인터넷이 바로 풀리지 않고 브라우저로 먼저 동의·로그인을 요구하는 경우가 있습니다. OS나 안드로이드/아이폰은 이런 흐름을 캡티브 포털(captive portal) 검사로 감지하고, 쿠키·리다이렉트·HTTP 302, 때로는 같은 대역(사설 IP)에 있는 인증용 웹으로 연결하도록 합니다. 여기서 Clash를 켜 시스템 프록시나 TUN(가상 터널)이 전면에 서면, 본인도 모르는 사이 인증에 필요한 HTTP/HTTPS가 원격 프록시 노드로 흘러가거나, DNS가 Clash 쪽(예: fake-ip)을 보면서 게이트웨이가 돌려주는 “정답” 주소를 놓칩니다. 겉으로는 “WiFi는 잡혔는데, 외국 서버·오류 페이지·무한 리다이렉트”처럼 보이기 쉬워요.

또 “인증은 됐다”는데 Clash 켜자마다 다시 끊기면, 짧은 세션 토큰이 캡을 안 타는 경로(직접)로만 열려야 하는데, 전역 모드·불필요한 UDP·다른 DNS에 실려 세션이 무효화됐다고 보는 쪽이 낫습니다. 아래는 로컬 약관과 보안을 지키는 범위에서, 인증·일반 사용을 나누는 분할(스플릿)과 직접(DIRECT)을 실무적으로 쌓는 순서입니다. GUI나 코어는 Clash·Mihomo·Verge 등 공통으로 읽힐 수 있게 “행동 단위”로 썼습니다. TUN·시스템 경로의 차이는 TUN 모드 가이드와, “전역인데 앱은 안 먹는” 오판을 줄이는 시스템 프록시·TUN 점검을 먼저 훑고 오면 훨씬 수월합니다. 규칙 배치 자체는 규칙 분할(스플릿) 가이드와 맞닿습니다.

0단계: 가장 확실한 방법—인증할 때는 Clash(프록시)를 잠깐 끄기

이상적인 첫 응답은 “망·운영자 정책이 허용하는 범위에서, 인증 HTML이 로컬망(또는 사설)에서 직접 뜨게 한다”는 것입니다. 그래서 인증·동의·SMS·QR 한 번 할 때는 Clash를 끄거나(시스템 프록시 끄기, TUN 끄기), 최소 ‘프록시 사용 안 함’으로 맞추는 방식이 가장 재현률이 높습니다. GUI 클라이언트는 보통 시스템 프록시 토글, TUN 토글이 나뉘어 있으니, 둘 다 꺼지는지 확인하세요. TUN이 켜진 채로 시스템만 꺼도 터널이 남는 경우가 있어, 상태 아이콘·로그로 “가로채기”가 꺼졌는지 점검하는 편이 안전합니다.

끄고 사파리(맥, 아이폰)나 크롬으로 아무 HTTP 사이트나 열어 보면(예: http://captive.apple.com 또는 http://connectivitycheck.gstatic.com — 환경마다 다릅니다) 운영자 포털로 끌려가면 성공 궤도입니다. “왜 하필 끄냐”는 질문엔, 캡티브는 그 장소의 AP가 설계한 직접·리다이렉트에 의존하는 경우가 많고, 전역 프록시/터널이 끼면 그 검사 패킷이 의도한 인터페이스로 가지 못해 깨질 수 있기 때문입니다.

1단계: TUN 끄기 vs 시스템 프록시만: 무엇부터 의심하나

TUN은 앱 전체(또는 광범위한) 트래픽을 가상 인터페이스로 끌어가므로, 캡티브 검사·리다이렉트·로컬 인증 URL에 가장 민감합니다. 시스템 프록시(HTTP/HTTPS, PAC)만 켠 상태는, 일부 OS·앱이 시스템대로 안 가는 경우(분리된 DNS, UWP, 특정 런처)가 있어도, 브라우저만으로 인증할 땐 TUN만큼 “전면막”은 아닌 편이 많습니다. “공항에선 시스템만 해도 됐는데, 백화점에선 TUN 켤 때만”처럼 장소마다 다르면, 그 장소는 캡티브 + DNS/차단 + HTTPS 검사의 조합이 다르다고 보면 됩니다. 요약하면, 고장 순서: TUN(전역) > 시스템 프록시(클라이언트·브라우저 위주) > Clash 끄기로 점검하세요.

2단계: 끄지 않고 쓰고 싶다면—DIRECT(직접)과 로컬·사설망

끄기가 번거롭다면(예: 룰만으로 유지) 규칙(rules) 상단에 로컬·사내·캡티브에 흔한 직접(DIRECT) 예외를 쌓는 전략이 있습니다. 대표적으로 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 같은 RFC1918(사설) 대역, 192.0.0.0/24(일부 iOS/포털 쪽 힌트), localhost, LAN·LOCAL 키워드(코어/프로필이 지원할 때)를 프로시 그룹보다 먼저 DIRECT로 두는 방식입니다. 지역/운영자 고정 도메인이 보이면(로그·개발자 도구로 호스트 캡처) DOMAIN-SUFFIX,wifi.xxx, DIRECT 같이 명시하는 편이 안정적입니다. 규칙 순서가 뒤섞이면 GEOP·MATCH가 먼저 잡혀서 여전히 원격으로 나갈 수 있으니, 분할 문서의 “앞이 이긴다”는 느낌을 맞춥니다.

이때 “분할(스플릿)이란, 중요한 흐름이 직접(DIRECT)으로, 나머지가 선택한 프록시로 간다”는 뜻을 문장으로 고정해 두는 게 좋습니다. 전역(글로벌) 모드이면 예외가 먹히는지, Rule 모드이면 첫 히트가 맞는지 Clash 로그를 같이 봅니다. LAN 공유 Allow LAN·방화벽이 걸릴 수 있는 휴대폰 시나리오는 Allow LAN·휴대폰 점검 쪽과는 다른 축이지만, “로컬망·방화벽”을 의심할 때 참고하세요.

3단계: DNS·fake-ip—포털 주소를 Clash가 앞질러 캡하지 않게

캡티브가 안 뜨는 흔한 이유는 DNS입니다. fake-ip를 켜면 도메인이 Clash 쪽 먼저 풀리는데, 공용망 게이트웨이가 “인증이 필요하다”는 별도의 리다이렉트/피를 주는 흐름과 부딪힐 수 있습니다. 도메인 기반 인증 URL이 “거짓 IP”로 잡혀, 브라우저가 엉뚱한 곳에 붙는 패턴이죠. 점검은 (1) 잠시 필수 도메인·로컬 탐지용 도메인을 fake-ip-filter·nameserver 정책에 넣거나, (2) 캡티브 구간에 한해 Clash의 DNS(또는 캡처)를 끄는—즉, OS 기본 DHCP DNS로 질의가 가게—하는 쪽이 안전한 경우가 많습니다. DoH/DoT를 강제로 쓰는 OS·브라우저 설정이 있으면, AP가 기대한 투명한 DNS가 아닌 쪽으로 가서, 인증 HTML 대신 노드/차단/오류로 보일 수도 있습니다. 이 단계는 코어/프로필마다 키 이름이 조금씩 달라 사용 중인 GUI 문서의 DNS 섹션과 함께 읽는 것이 좋습니다.

4단계: 인증이 끝난 뒤—Clash 다시 켜기와 끊김 줄이기

“로그인은 했는데, Clash 켜자마다 강제로 로그인으로 돌아간다”면 세션이 캡을 안 타는 경로(직접)로 유지돼야 하는 트래픽이, 프록시/다른 SNAT로 나가 소스·쿠키가 꼬였을 가능성을 봅니다. (1) 게이트웨이/운영자 포털 도메인·.local·내부 캡처 호스트는 당분간 DIRECT에 두고, (2) UDP가 필요한 앱(음성, 일부 게임)이 인증/차단 API와 같은 룰에 잡혀 다른 국가 노드로 가면 세션 쪽만 실패하는 식이 됩니다. (3) MTU/분할이 지나치게 작을 때(일부 TUN) 큰 응답이 깨져 “또 로그인”으로 보일 수도 있으니, 다른 글·환경에선 MTU를 따로 봅니다(예: WSL2 병행은 WSL2·MTU 참고. 공용망과는 원인이 다를 수 있음).

5단계: 아이폰·안드로이드, 노트북—차이만 짚기

iOS·macOS는 “Wi-Fi” 상세·사파리, Captive 관련 시스템 프로브에 의존하는 편이 큽니다. VPN/프로필·Always-on VPN이 켜져 있으면 캡티브보다 VPN이 우선돼, 포털이 뒤로 밀릴 수 있습니다. Android는 제조사·OS 버전에 따라 “연결·포털” 알림, 수동 “로그인” 진입, 개인 DNS 강제가 끼어듭니다. 노트북(윈/맥)에선 시스템·브라우저·TUN의 우선순위를 실제로 꺼 켤로 확인하세요. 모바일은 PC 테더링 뒤 PC에서만 Clash를 쓰는 식이면, 캡티브는 폰/테더 쪽에서 먼저 끝내는 편이 낫습니다.

주의: 공용망, 약관, 스니핑

무료 공공 WiFi는 운영자·지역 이용 약관·보안(로그, 포털 수집)이 다릅니다. HTTPS는 도메인을 지키는 데 중요하고, 민감 계정은 캡티브 망이 아닌, 신뢰할 수 있는 연결(개인망, 알려진 VPN 정책)에서 처리하는 것이 일반적입니다. 본문은 접속 불편(기술)을 줄이는 절차이며, 현지 법·시설 규정·고용/학내 정책을 대신해 주지 않습니다.

정리

캡티브 포털은 공용 WiFi에 붙을 때 인증 페이지·리다이렉트·로컬/사설 직접(DIRECT) 경로가 어우러지는 흐름입니다. Clash의 시스템 프록시·TUN·DNS(fake-ip)·전역/규칙이 그 사이에 끼면, “로그인이 안 뜬다 / 끊긴다”로 보이기 쉽습니다. 실전에서는 인증 직전엔 Clash 잠시 끄기가 가장 확실하고, 계속 켜둔다면 로컬·사설·감지된 인증 도메인을 DIRECT로, DNS는 AP가 주는 흐름이 안 깨지게 맞추는 순서로 점검하세요. 인증 뒤에는 분할(스플릿)이 유지돼, 필요한 망만 직접 두고 나머지는 기존 그룹으로 두는 편이 관리에 유리합니다.

다른 류의 프록시와 비교해 볼 때, Clash·Mihomo는 구독·규칙 분할·로그를 한 화면에 묶기 쉬워, 캡티브 한 번 건드린 뒤에도 호스트를 규칙에 굳이기 좋은 편입니다. 한 사슬씩 로그에 쌓이면, 다음에 같은 공항/체인에서 반복이 줄어듭니다.

지금 쓰는 OS·클라이언트에 맞는 설치로 바로 점검하려면 Clash를 무료로 다운로드한 뒤, 시스템 프록시·TUN을 구분해 켜고 끄며 위 순서를 적용해 보시기 바랍니다. 오픈소스 GitHub에서 릴리스·이슈를 찾는 것도 가능하되, 패키지 설치는 항상 이 사이트 다운로드를 먼저 쓰는 것을 권장합니다.