1. 무엇을 한 번에 해결하려는지

검색 의도를 한 문장으로 옮기면, “노트북과 폰에 똑같은 철학의 프록시를 깔되, 수업용 트래픽은 안정적으로, OTT·유튜브는 배터리와 노드 부담을 분리하고 싶다”에 가깝습니다. 블로그 전반이 특정 사이트 트러블슈팅에 치우쳐 있으면 독자는 증상별 글을 뒤지느라 시간을 쓰게 되고, 기기 간 정책이 달라져서 같은 증상이 반복됩니다. 그래서 여기서는 증상 하나가 아니라 일상 조합—수강 신청·LMS·화상 강의·Google Scholar·논문 다운로드·기숙사나 셔틀에서의 짧은 스트리밍—을 한 줄로 묶어 봅니다.

전제는 단순합니다. 코어는 Mihomo·Clash Meta 계열을 공유하고, 셸만 Windows·macOS 데스크톱과 iOS·Android로 바꿉니다. 구독 URL과 rule-providers 경로만 통일해 두면, “어제 노트북에서 고친 규칙”이 오늘 폰에도 그대로 내려갑니다. 구독을 다루는 기본 절차는 구독 가져오기를 먼저 확인하고 오면 흐름이 붙습니다.

2. 노트북: Clash Verge Rev와 시스템·TUN의 역할

노트북은 키보드·대화면 덕분에 학술 작업에 집중하기 좋고, Clash Verge Rev처럼 정책 그룹 지연 테스트·로그·트레이 전환이 잘 갖춘 앱과 궁합이 좋습니다. 처음에는 시스템 프록시만으로도 충분한 경우가 많지만, 터미널·IDE·일부 게임 런처까지 같은 분류를 타게 하려면 TUN이 필요합니다. TUN을 켤 때 가장 흔한 함정은 “노트북만 TUN + fake-ip, 폰은 예전 DNS”처럼 이중 불일치를 만드는 것입니다. 한쪽에서만 도메인이 가짜 IP로 풀리면 특정 앱만 TLS 핸드셰이크에서 막히거나, 학교 포털이 루프를 돕니다.

실무 팁으로는 노트북 프로필에서 DNS 모드와 fake-ip 사용 여부를 먼저 고정해 문서화해 두는 일입니다. 나중에 모바일로 복제할 때 “왜 폰에서만 scholar 결과가 이상한지” 같은 질문이 줄어듭니다. Windows라면 방화벽 허용, macOS라면 시스템 확장 승인까지 한 번에 끝내 두는 것이 시험 기간 스트레스를 줄입니다.

3. 스마트폰: Stash·안드로이드 클라이언트와 ‘같은 YAML’

iOS에서는 App Store 정책 때문에 항상 데스크톱과 완전 동일한 바이너리를 쓰지는 못하지만, Stash는 Mihomo 문법과 규칙 파일을 옮기기 쉬운 편입니다. Stash 구독 글에서 다루듯 프로필을 분리해 두면 “수업용 최소 규칙”과 “귀국 전후용 풀셋”을 전환하기도 좋습니다. Android는 제조사별 배터리 최적화가 VPN·프록시 앱을 백그라운드에서 죽이기도 하므로, 클라이언트를 예외 처리하고 자동 재연결 옵션을 확인해야 합니다.

모바일에서 TUN을 켤지 여부는 데이터 요금·발열·학교 정책에 따라 갈립니다. 끄더라도 DNS 질의 경로만 노트북과 맞추면 “같은 규칙 세트”라는 감각은 유지됩니다. Wi-Fi와 셀룰러를 자주 바꾸는 생활 패턴이라면 구독 자동 갱신 주기를 지나치게 짧게 두지 말고, 막힐 때만 수동 새로고침하는 편이 안정성과 배터리 모두에 이롭습니다.

4. 수업·연구 스택: Zoom·Teams·LMS·Google Scholar

화상 수업은 미디어 릴레이와 신호 채널이 갈라져 있어 규칙이 길고 복잡하면 지연부터 생깁니다. Zoom 글과 Teams 글에서 다룬 것처럼 CDN·WebRTC·M365 호스트를 미리 분류 목록에 넣어 두면, 노트북에서 잡힌 경로를 폰에 복사했을 때도 회의 품질이 크게 어긋나지 않습니다. 학교 LMS나 SSO 포털은 지역·학교마다 도메인이 제각각이므로, 템플릿 규칙만으로는 부족할 때가 많습니다. 이때는 실제 세션에서 연결 로그에 찍힌 호스트 이름을 보고 한두 줄씩 추가하는 방식이 현실적입니다.

Google Scholar와 논문 리더 앱은 대부분 HTTPS 단일 스트림이라 DIRECT가 빠른 캠퍼스망도 있고, 반대로 출판사 리디렉트가 길어 전용 그룹이 필요한 경우도 있습니다. “무조건 교수 추천대로 DIRECT”보다는 본인 망에서 재생 속도와 인증 성공 여부를 보고 결정하는 편이 낫습니다. 도서관 프록시나 교내 VPN을 거치는 과제는 학교 안내를 최우선으로 두고, Clash는 그 바깥 트래픽만 조정하는 식으로 역할을 나누면 DNS·라우팅 충돌이 줄어듭니다.

5. 스트리밍·여가: 왜 규칙을 ‘아래쪽’으로 빼는가

기숙사나 통학 중 짧게 보는 스트리밍은 대역폭이 크고 CDN이 자주 바뀝니다. 수업 규칙과 한 덩어리로 묶으면 노드를 자주 바꾸게 되고, 그때마다 DNS 캐시가 흔들려 다른 앱까지 영향을 받을 수 있습니다. 그래서 OTT·동영상·음악 스트리밍을 별도 정책 그룹으로 내리고, 상단에는 학교·행정·Scholar 관련 직결·고정 노드를 두는 패턴이 체감상 깔끔합니다. YouTube만 따로 다루고 싶다면 googlevideo 분리 글의 호스트 목록을 참고해 rule-set에 합칠 수 있습니다.

배터리 관점에서는 “항상 최고 화질·항상 글로벌 노드” 대신, 와이파이에 묶였을 때만 고대역 프로필을 켜는 습관이 좋습니다. 프로필 두 벌을 Verge·Stash에 저장해 두고 전환만으로 끝낼 수 있습니다.

6. DNS·TUN 함정을 줄이는 체크리스트

  1. fake-ip를 쓰는지, 실제 IP를 쓰는지 노트북과 폰에서 동일하게 맞추거나, 다르게 둘 이유를 메모에 적어 둡니다.
  2. 운영체제의 비공식 DNS(DoH)와 Clash 로컬 DNS가 이중으로 가로채지 않는지 확인합니다.
  3. TUN을 켠 뒤 특정 앱만 빠져 나간다면 분할 앱 목록·방화벽 예외를 점검합니다.
  4. 캠퍼스·기숙사 공용 Wi-Fi에서 포털 인증이 필요한 경우, 인증 직후에만 프록시를 켜는 순서를 몸에 익힙니다.

이 중 두 번째는 Firefox 진단 글에서 말한 것처럼 브라우저 보안 DNS와 프록시 조합이 엇갈릴 때도 비슷한 증상이 납니다. 브라우저마다 예외를 두기보다, Clash 쪽 DNS 설계를 먼저 단일화하는 편이 유지 보수가 쉽습니다.

7. 다섯 단계로 다시 보는 일상 운영

아침 강의 전 준비를 습관화하려면 다음 순서를 추천합니다. (1) 노트북에서 프로필이 잘 뜨는지·정책 그룹이 의도한 노드를 고르는지 확인합니다. (2) Zoom·Teams 테스트 통화 30초로 패킷 드롭을 봅니다. (3) Scholar나 LMS에 로그인해 리디렉트가 끊기지 않는지 확인합니다. (4) 폰에서 같은 프로필을 불러왔다면 DNS 모드가 노트북과 충돌하지 않는지만 짧게 검증합니다. (5) 저녁 스트리밍 전에만 고대역 프로필로 바꿉니다. 이 루틴은 “증상별 글을 매번 검색”하는 시간을 줄여 줍니다.

8. 자주 묻는 질문

노트북만 TUN이고 폰은 프록시만 써도 되나요? 가능하지만 규칙 경로가 달라져 특정 앱만 끊길 수 있으니 DNS 모드는 가능한 맞추세요. 학교 VPN과 동시에? 지원 문서가 허용할 때만, 그렇지 않으면 수업 중 하나만 켜세요. Scholar는 DIRECT? 망 상태 보고 결정하세요. 배터리? 스트리밍 그룹을 분리하고 프로필 전환으로 해결하세요.

9. 정리: 단일 앱 VPN과 비교했을 때 Clash의 자리

상용 VPN 한 앱으로 모든 것을 때우는 방식은 처음 켜기는 쉽지만, 화상 회의·컨테이너·터미널까지 동일한 세밀한 분류를 기대하기 어렵고, 연결 로그로 “어느 호스트가 막혔는지”를 보기도 힘든 경우가 많습니다. 브라우저 확장만 쓰면 데스크톱 앱 트래픽은 그대로 노출되고, 기기마다 설정이 달라져 유학 생활처럼 장소와 네트워크가 자주 바뀌는 환경에서 반복 디버깅이 늘어납니다. 반면 Clash·Mihomo 스택은 같은 YAML을 노트북과 스마트폰에 옮기며 듀얼 기기 일관성을 유지할 수 있고, 수업·연구와 스트리밍을 정책으로 나눠 안정성과 전력 사이를 조절하기도 쉽습니다. 같은 흐름을 데스크톱에서도 맞춰 보고 싶다면 지금 무료로 Clash를 내려받아 노트북 쪽 규칙을 정교화해 보세요.