왜 «규칙 순서」가 캠퍼스망에서 특히 중요한가
Clash 계열 클라이언트는 위에서 아래로 첫 매칭 규칙 하나에 트래픽을 붙입니다. 집이나 일반 회선에서는 «해외 사이트만 프록시» 같은 단순 패턴도 잘 돌아가지만, 학교·기관 Wi‑Fi는 예외가 한꺼번에 몰립니다. 포털 검사용 도메인, 리다이렉트 URL, SSO(통합 로그인) 호스트, 도서관·전자출결·캠퍼스 클라우드 같은 교내 전용 FQDN, 그리고 사설 대역 10.0.0.0/8·172.16.0.0/12·192.168.0.0/16에 붙는 관리 페이지까지, 전부 «일반 웹»과 같은 글로벌 규칙에 묶이면 안 됩니다.
여기에 Captive Portal이 개입합니다. OS와 브라우저는 연결 상태를 확인하기 위해 특정 호스트에 HTTP 요청을 보내고, 차단망이면 로그인 페이지로 돌려보냅니다. 이 요청이 Clash의 Proxy 체인을 타면 응답 지연·지역 불일치·TLS 검증 문제로 «온라인인데도 오프라인»처럼 보일 수 있습니다. 반대로 인증 전에 TUN까지 켜 두면 가상 NIC·라우팅이 먼저 개입해 포털 탐지 자체가 실패하는 사례도 흔합니다. 그래서 이 글에서는 인증 전후를 나누는 것과 rules 최상단에 DIRECT 묶음을 같은 축으로 봅니다.
이미 TUN·시스템 프록시 차이나 fake-ip·로컬 DNS를 읽었다면 좋습니다. 본문은 그보다 «학교망 + 포털」에 특화한 실행 순서에 집중합니다.
1단계: 인증 전에는 우회를 잠시 줄이기
새로 Wi‑Fi에 붙었을 때 가장 안전한 기본값은 Clash의 시스템 프록시·TUN을 끄거나, 클라이언트를 종료한 뒤 OS가 띄우는 연결 안내를 따르는 것입니다. Windows·macOS·모바일은 각각 네트워크 로그인 페이지 열기 메뉴를 제공하고, 일부 환경에서는 브라우저만 자동으로 포털 URL을 열어 줍니다.
프록시를 꼭 켜 둔 상태로 테스트해야 한다면, 규칙 모드에서 기본 출구가 전역 프록시로만 고정돼 있지 않은지 먼저 확인하세요. 인증용 트래픽은 DIRECT로 빠져야 하며, 이때 중요한 것이 아래 2~3단계의 rules 상단 예외입니다. «끄기가 귀찮다»고 채널만 바꿔 테스트하면 원인이 섞여서 시간만 늘어납니다.
2단계: Captive Portal·연결 검사 호스트는 DIRECT로 고정
운영체제마다 연결 검사 URL이 다릅니다. 예를 들어 Apple 계열은 captive.apple.com, Windows는 www.msftncsi.com 등을 사용합니다. 학교망에서는 이 요청이 지연되거나 잘못된 지역 노드를 타면 «인터넷 없음» 배지가 뜨고, 사용자는 같은 SSID에서 반복해서 로그인만 시도하게 됩니다.
YAML의 rules:에서 이들을 가장 위쪽에 두고 DIRECT로 보냅니다. 학교에서 안내하는 포털 도메인(예: login.university.ac.kr 형태)과 SSO 제공자 도메인도 함께 넣습니다. 서브도메인이 많다면 DOMAIN-SUFFIX로 묶는 편이 관리에 유리합니다. 여기서 흔한 실수는 GEOIP나 DOMAIN-KEYWORD 같은 넓은 규칙을 더 위에 두는 것입니다. 좁고 확실한 예외가 먼저 와야 합니다.
구체적인 문법은 YAML 규칙 분기 가이드의 Rule Providers·스니펫 순서 설명과 짝을 이룹니다. 캠퍼스 전용으로는 «포털 + 교내 도메인 + 사설 IP」 세 묶음을 DIRECT 스니펫으로 만들어 두고 원격 규칙 세트보다 앞에 두는 패턴이 재사용하기 좋습니다.
3단계: 내부망·사설 대역·멀티캐스트는 프록시 밖으로
강의실 프린터, 도서관 DB, 실험실 NAS, 캠퍼스 Wi‑Fi 관리 페이지는 대개 RFC1918 사설 주소나 학교 전용 공인 대역에 있습니다. 이 트래픽을 해외 노드로 보내면 당연히 실패하고, 일부 노드는 사설 목적지를 아예 막기도 합니다. IP-CIDR 규칙으로 사설 세 구간을 DIRECT로 묶고, geoip:private를 Meta 계열에서 쓸 수 있다면 인증·내부 서비스 보호에 도움이 됩니다.
또 한 가지는 DNS입니다. fake-ip 모드에서는 내부 이름이 클라이언트에 가짜 IP로 잡혀 실제와 다른 경로로 나갈 수 있습니다. 교내 포털·내부 호스트 이름이 있다면 fake-ip-filter에 넣거나, 해당 도메인을 redir-host 쪽으로 맞추는 전략을 검토하세요. 세부 트레이드오프는 fake-ip 전용 글과 중복되므로, 여기서는 «캠퍼스망에선 내부 이름이 먼저 깨지지 않게 할 것」만 강조합니다.
| 대상 | rules에서의 일반적 처리 | 비고 |
|---|---|---|
| 포털·연결 검사 호스트 | DIRECT 최우선 |
지연·오판 방지 |
| 학교 SSO·전자출결·도서관 | DOMAIN-SUFFIX → DIRECT |
제공자 안내 도메인 기준 |
| 사설 IP 대역 | IP-CIDR → DIRECT |
프린터·NAS·관리 UI |
| 일반 웹·앱 | 정책 그룹(Proxy) | MATCH 전에 위 규칙이 소모 |
4단계: TUN과 시스템 프록시, 인증 전후 순서 정하기
TUN 모드는 트래픽을 넓게 잡아 주지만, 캡티브 환경에선 인증 전에 켜면 라우팅·DNS가 먼저 엉켜 포털이 안 뜨는 경우가 있습니다. 실무에서는 (1) 첫 연결 시에는 시스템 프록시만 또는 둘 다 끄기 → (2) 로그인 완료 → (3) 필요 시 TUN 켜기, 순으로 두는 편이 안전합니다.
이미 TUN을 상시 켜 두는 습관이 있다면, 학교 SSID에 붙을 때만 프로필 전환이나 간이 DIRECT 프로필을 쓰는 방법도 있습니다. 예를 들어 «Campus-DIRECT.yaml」처럼 규칙 최상단만 채우고 나머지는 최소화한 프로필로 인증만 마친 뒤, 일상용 구독 프로필로 바꿔 끼우는 방식입니다. GUI에서 프로필 바꾸기가 번거롭다면 Rule Set으로 «SSID 이름은 알 수 없으니」 수동 전환을 습관화하는 쪽이 낫습니다.
Windows에서는 다른 VPN·보안 에이전트와 TUN이 겹치면 어댑터 우선순위가 꼬이기도 합니다. 캠퍼스망은 원래 불안정한 편이니, 한 번에 한 계층만 바꿔 가며 테스트하세요.
5단계: 인증 후 구독·노드·시간 동기화 점검
포털을 통과한 뒤에도 Clash가 «안 된다»면 원인은 종종 구독 링크 쪽에 있습니다. 학교 방화벽이 특정 CDN·도메인을 막거나, TLS 검사로 인해 구독 URL 요청만 실패하는 경우입니다. 클라이언트에서 수동 갱신을 눌러 HTTP 상태·지연을 확인하고, 차단이 의심되면 다른 네트워크에서 받은 프로필을 USB로 옮기는 등 우회를 고려해야 합니다. 무료 공개 규칙 세트를 쓰는 경우에도 동일합니다.
노드 지연 측정이 전부 타임아웃이면, 규칙보다 먼저 시스템 시각이 맞는지 봅니다. TLS 인증서 오류는 «전부 안 됨»으로 보이기 쉽습니다. 그다음 DNS가 학교 DNS를 쓰는지, Clash DNS가 상위를 덮어쓰는지 확인합니다. 마지막으로 MATCH 이전에 REJECT나 광고 차단 규칙이 과하게 넓지 않은지 살핍니다.
장시간 도서관에서 쓸 때는 절전·슬립 후 깨어났을 때만 끊긴다면, 깨어난 직후에는 다시 1단계부터 포털 세션 만료를 의심하는 것이 좋습니다. 세션 만료 시에도 증상은 비슷하지만, 원인은 규칙이 아니라 재인증입니다.
자주 묻는 질문
캠퍼스 Wi‑Fi에서 Clash를 켜면 인증 페이지가 안 열릴 때 무엇부터 하나요?
먼저 시스템 프록시·TUN을 잠시 끄거나 규칙 모드에서 인증에 필요한 트래픽이 DIRECT로 나가게 한 뒤, 운영체제 또는 브라우저가 띄우는 Captive Portal 안내를 따릅니다. 인증이 끝난 다음에 프록시와 규칙을 다시 켜는 순서가 가장 안전합니다.
강제 포털(captive.apple.com 등)이 프록시로 가면 어떻게 되나요?
연결 검사용 호스트가 해외 노드를 타면 «인터넷 없음»으로 오판되거나 리다이렉트가 깨져 로그인 창이 뜨지 않을 수 있습니다. rules 상단에 해당 DOMAIN-SUFFIX·필요 시 IP 대역을 DIRECT로 두고, 학교 포털·내부망 RFC1918 대역도 DIRECT로 묶는 것이 일반적인 해결책입니다.
TUN 모드와 시스템 프록시, 캠퍼스망에서는 무엇을 먼저 켜야 하나요?
인증 단계에서는 범위가 넓은 TUN보다 시스템 프록시만 켜 두거나 둘 다 끈 상태로 포털을 여는 편이 충돌이 적습니다. 인증이 완료된 뒤 필요하면 TUN을 켜고, fake-ip·DNS hijack이 내부 이름을 가리지 않는지 함께 확인합니다.
인증 후에도 구독·노드가 안 잡힐 때 점검할 것은?
시스템 시각·TLS·구독 URL이 학교 방화벽에 막히지 않는지, User-Agent·403·DNS가 규칙에 의해 의도치 않게 REJECT되지 않는지 순서대로 봅니다. 클라이언트로 프로필을 다시 불러와도 동일하면 규칙·DNS 쪽을 우선 의심합니다.
마무리
Clash 캠퍼스 Wi‑Fi 문제의 핵심은 종종 노드 품질이 아니라 Captive Portal과 분류 규칙의 순서입니다. 인증 전에는 우회 범위를 줄이고, 강제 포털·교내 도메인·사설 대역을 DIRECT로 먼저 보낸 뒤, 나머지 트래픽만 정책 그룹으로 넘기면 «로그인은 됐는데 프록시만 안 된다»는 모순이 크게 줄어듭니다. 같은 증상이라도 집에서는 안 나오고 학교에서만 난다면, 이 순서를 의심해 보세요.
설치 파일과 클라이언트 선택은 ClashNote 다운로드 페이지에서 한곳에 모아 두었습니다. 여러 플랫폼 빌드를 비교한 뒤, 위 5단계를 프로필에 반영해 보시면 됩니다.
공유기 게이트웨이와 PC 클라이언트를 같이 쓰는 경우는 OpenWrt·게이트웨이 DNS 글과 주제가 겹치니, «학교 SSID 한 기기」에 집중했다면 본문 순서를 우선 적용하고, 집 공유기와 병행할 때만 해당 글을 참고하면 흐름이 섞이지 않습니다. 더 넓은 규칙 설계는 기술 칼럼의 YAML·스트리밍 가이드와 이어 읽으면 좋습니다.