왜 유학생은 Clash “분류”부터 고민하나
유학생이나 교차 등록으로 두 캠퍼스를 오가는 경우, 한 대의 노트북에서 Zoom·Microsoft Teams 같은 화상 수업, 학교 SSO와 수강신청 포털, 그리고 거주 국가와 계약 지역이 다른 스트리밍을 같은 날 처리해야 할 때가 많습니다. 이때 클라이언트를 글로벌 프록시 하나에 묶어 버리면 간단해 보이지만, 실제로는 Zoom 미디어 서버만 느려지거나, 교무 시스템이 “허용되지 않은 지역”이라며 로그인을 막거나, OTT는 원하는 카탈로그가 안 열리는 식으로 증상이 갈라집니다.
핵심은 하나의 출구가 아니라 “트래픽 종류별로 다른 출구를 택하게 만드는 분류 규칙”입니다. Clash·Mihomo 계열은 규칙 모드에서 도메인·지역·프로세스 단위로 경로를 나눌 수 있어, 같은 프로필 안에서 수업은 지연 안정 위주, 학교 행정은 해당 국가 IP, 엔터테인먼트는 별도 리전 노드로 보내는 식의 분할 라우팅이 가능합니다. 이 글은 이미 공항 구독을 넣어 두었다는 전제에서, 목표별로 규칙과 정책 그룹을 어떻게 쌓는지 순서를 드러냅니다. 설치·첫 연결은 Windows용 Verge Rev 설치 가이드나 macOS 사용법과 짝을 이룹니다.
1단계: 트래픽 목록을 적고 출구 축을 정하기
설정을 건드리기 전에 표 하나를 만드는 것이 이후 실수를 줄입니다. 열은 대략 다음 네 가지면 충분합니다. 서비스 이름, 필수 지역(본국 캠퍼스인지 거주국인지), UDP 여부, 브라우저만 쓰는지 앱 전체인지입니다. Zoom과 Webex는 미디어용 UDP가 많고, 학교 포털은 HTTP 리다이렉트 체인이 길며, Netflix·YouTube Premium·지역 방송 앱은 카탈로그 판별에 쓰는 호스트가 CDN별로 갈립니다. 이때 “이 줄은 무조건 DIRECT”처럼 원칙을 먼저 박아 두면 나중에 GEOIP 줄을 넣을 때 덮어쓰기 싸움을 줄일 수 있습니다.
학교가 요구하는 IP 범위 문서가 있다면 캡처해 두고, 없더라도 SSO 도메인·캘린더·과제 제출 호스트 이름은 브라우저 주소창과 개발자 도구의 네트워크 탭에서 금방 모읍니다. 스트리밍은 공급자가 배포하는 규칙 스니펫을 구독에 섞는 방법이 흔한데, 그 경우 “수업용 그룹보다 아래에 두었는가”를 항상 확인해야 합니다. 넓은 GEOIP 한 줄이 좁은 교육 도메인을 삼켜 버리면 증상이 이상하게만 보입니다. 우선순위에 대한 개념은 라우팅 규칙 전략 글과 같이 읽으면 흐름이 잡힙니다.
2단계: 정책 그룹을 역할별로 쪼개기
기본 PROXY 하나만 두지 말고, 실제 사용에 맞춰 이름 있는 그룹을 만듭니다. 예시 이름은 독자 환경에 맞게 바꿔도 됩니다. ZOOM_STABLE 같은 SELECT 그룹에 체감 지연이 가장 낮은 노드 한두 개만 넣고 수업 시간에는 그대로 고정합니다. CAMPUS_HOME에는 학교가 요구하는 국가의 노드를 모아 두고 SSO 전체를 이쪽으로 보냅니다. STREAM_KR·STREAM_US처럼 OTT 전용 그룹을 분리하면, 수업 중에 스트리밍 노드를 고를 필요 없이 규칙이 자동으로 대신합니다.
URL-TEST나 Fallback 계열을 Zoom에 직접 연결하면 측정 주기마다 출구가 바뀌어 세션이 끊기는 패턴이 종종 나옵니다. 자동 그룹은 “백업용 PROXY” 정도에 두고, 화상 구간에는 SELECT 고정을 권합니다. 노드 품질 변동이 심할 때는 공급자 쪽 지연 테스트 간격을 늘리는 것도 같은 이유입니다. 모바일에서 같은 프로필을 쓴다면 Android 클라이언트 사용법에서 모드 전환 순서를 같이 맞추면 혼선이 줄어듭니다.
3단계: 도메인 규칙을 위에서부터 채우기
YAML의 rules: 블록은 위에 둔 줄이 우선입니다. 일반적인 순서는 다음과 같습니다. 로컬·사설 대역 DIRECT, 교내·행정 도메인(학교가 본국만 허용하면 해당 그룹, 아니면 DIRECT), 화상 회의 호스트(zoom.us, zoom.com 계열, Teams나 Webex 제공 목록), 클라우드 스토리지나 Git 호스트 중 수업에서 쓰는 것, 마지막으로 스트리밍 목록, 그 다음 GEOIP와 MATCH입니다. DOMAIN-SUFFIX로 묶을지 DOMAIN-KEYWORD로 넓게 잡을지는 오탐과 누락의 트레이드오프입니다. 학기 초에 한 번 로그를 보며 빠진 호스트를 보완하는 편이 안전합니다.
Zoom은 브라우저 접속과 클라이언트 미디어가 다른 이름을 쓰는 경우가 있어, 끊김이 남으면 클라이언트 로그나 방화벽 로그에 찍힌 SNI를 규칙에 추가합니다. 학교 이메일이 Gmail로 통합돼 있어도 SSO만 분리해 두면 로그인 경로가 단순해집니다. 스트리밍 규칙을 외부에서 가져올 때는 “내 수업용 DIRECT 줄보다 아래에 있나”를 다시 확인하세요. DNS가 fake-ip냐 redir-host냐에 따라 같은 규칙도 체감이 달라지므로 fake-ip와 redir-host 비교를 참고해 캠퍼스·뱅킹 앱과 충돌이 없는지 봅니다.
4단계: DNS, TUN, 시스템 프록시 정렬
규칙이 정확해도 단말이 라우터 밖 DNS로 직접 질의하면 매칭이 어긋납니다. 운영체제 네트워크 설정, 브라우저의 “보안 DNS”, VPN 어댑터가 동시에 살아 있으면 “반만 프록시”처럼 보입니다. TUN 모드를 켜 전체 트래픽을 코어로 끌어들이는 방법은 강력하지만, 다른 VPN과 경쟁하거나 일부 대학 클라이언트와 충돌할 수 있습니다. TUN 모드 가이드에서 켜고 끄는 기준을 함께 읽고, 수업 시간에는 가능하면 한 레이어로 단순화하는 것이 좋습니다.
IPv6가 켜져 있는데 규칙은 IPv4만 다루면 트래픽이 새는 사례가 있습니다. 문제가 난 기기에서 IPv6 주소가 붙는지, DNS가 어디를 가리키는지 같이 봅니다. 회사나 학교에서 배포한 전용 VPN을 동시에 켜야 한다면, 그 터널 대역은 DIRECT 예외에 넣지 않으면 이중 NAT로 Zoom이 불안정해질 수 있습니다.
5단계: 수업 전에 로그로 검증하기
실제 수업 전 10분을 할애해 “이름이 기대한 정책 그룹으로 잡히는지” 확인합니다. 로그와 규칙 적중 글의 흐름대로 클라이언트 로그를 열고 Zoom 접속 직후 걸린 줄을 봅니다. 스트리밍은 카탈로그 재생 전에 우회 판별 도메인이 먼저 매칭되는지 확인하면 지역 오류 메시지를 줄일 수 있습니다. 규칙을 크게 바꿨다면 캐시된 연결을 끊기 위해 브라우저 프로필을 새로 열거나 클라이언트를 한 번 재시작하는 것도 방법입니다.
수정이 반복되면 프로필을 “학기용 기본”과 “시험 기간 최소 규칙”으로 나눠 두고, YAML 상단에 짧게 주석으로 블록 목적을 적어 둡니다. 실수로 잘못된 줄을 지웠을 때 되돌리기 쉬워집니다.
흔한 함정: 끊김, 로그인 루프, 지역 메시지
Zoom만 불안정: 자동 노드 그룹을 쓰는지, UDP가 막혔는지, 동시에 다른 VPN이 켜져 있는지 순서로 봅니다. 미디어 서버 대역이 GEOIP로 넓은 PROXY에만 묶여 있으면 특정 회선에서만 패킷 손실이 커질 수 있습니다.
학교 사이트만 로그인 루프: SSO 리다이렉트에 섞인 Microsoft·Google·Okta 호스트가 서로 다른 정책 그룹으로 갈라지면 쿠키 도메인이 꼬입니다. 인증 체인 전체를 한 그룹으로 묶거나, 공용 IdP는 별도 DIRECT 처리로 통일합니다.
OTT만 지역 오류: 스트리밍 전용 규칙이 너무 아래에 있거나 DNS가 원하지 않는 국가로 해석되면 카탈로그 판별이 틀어집니다. 규칙 순서를 올리고 DNS를 코어와 같은 값으로 맞춥니다.
공항 구독이 바뀔 때마다 커스텀 규칙이 덮이지 않는지, 오버라이드로 유지하는 방법도 함께 알아 두면 학기 중 업데이트가 편합니다.
FAQ
Q. Zoom만 자꾸 끊깁니다. 정책 그룹을 SELECT로 고정했는지, 자동 테스트 그룹이 세션 중 출구를 바꾸지 않는지, UDP·TUN·다른 VPN 충돌이 없는지 봅니다.
Q. 수강 포털은 직결이 맞나요? 학교 정책에 따릅니다. 본국 IP가 필요하면 캠퍼스 그룹으로 보내고, 캠퍼스 Wi-Fi 전용 앱은 DIRECT가 맞는 경우가 많습니다.
Q. 스트리밍과 수업을 한 프로필에서 쓰고 싶어요. 스트리밍 전용 정책 그룹을 분리하고 규칙 순서를 좁은 도메인이 위로 오게 유지합니다.
Q. 규칙이 너무 많아졌습니다. 주석 블록과 프로필 분리, 라우팅 전략 글을 참고해 우선순위를 다시 그립니다.
정리하며
유학생 환경에서 Clash의 이점은 “한 줄 글로벌”이 아니라 수업·행정·여가가 요구하는 출구가 다를 때 그 차이를 분류 규칙으로 코드화할 수 있다는 점입니다. 정책 그룹을 역할별로 나누고, 규칙을 위에서부터 좁게 쌓으며, DNS와 TUN을 한 축으로 맞추면 Zoom 끊김과 포털 오류를 동시에 줄일 수 있습니다.
다만 공개 저장소·포크마다 GUI가 달라 첫 설정에 시간이 걸리고, 노드 품질을 일일이 확인하기 번거로운 경우가 많습니다. 구독 URL만 넣었다가 빈 노드 목록에서 멈추거나, YAML을 손으로 고치다 실수로 문법을 깨는 일도 흔합니다. ClashFast는 이런 마찰을 덜기 위해 데스크톱·모바일에서 가져오기와 상태 점검에 무게를 둔 흐름을 지향합니다. 직접 비교해 보시고, 필요하면 Clash 무료 다운로드 페이지에서 클라이언트를 받아 같은 구독으로 분류 규칙을 검증해 보시면 됩니다.