Clash Verge Rev에서 다중 프로필·구독 새로고침과 Rule·Global·Direct 모드 전환 실무

Clash Verge Rev와 mihomo 코어를 한 줄로 정리하면

화면에서 보는 프로필은 로컬에 저장된 하나의 실행 구성 이름이고, 그 안에는 여러 구독(원격 YAML 소스)이 묶여 있을 수 있습니다. mihomo 코어는 그 합쳐진 구성을 읽어 실제로 들어오는 연결마다 rules와 proxy-groups를 적용합니다. Verge Rev는 이 과정을 메뉴와 토글로 감싼 제어판입니다. 따라서 「연결이 이상하다」는 증상은 (A) 활성 프로필이 잘못됐거나 (B) 구독 YAML이 오래됐거나 (C) 모드가 Rule/Global/Direct 중 무엇을 기대하는지와 맞지 않거나 (D) DNS·TUN·시스템 프록시 변수가 겹친 경우로 나뉩니다. 여기서는 A~C를 UI 관점에서 빠르게 가르는 법에 집중합니다.

검색 사용자의 의도는 대개 네 가지입니다. 둘 이상의 공급자 URL을 한 클라이언트에 같이 두고 싶다, 바로 수동 새로고침으로 최신 노드를 받고 싶다, 업무용·개인용으로 프로필을 분리해 두고 하루에 몇 번 바꾸고 싶다, 특정 사이트만 열리지 않을 때 Rule과 Global을 어떻게 오가야 하는지 모르겠다는 질문입니다. 아래 절은 이 네 갈래를 직접적으로 따라갑니다.

다중 구독과 다중 프로필: 무엇이 다른가

한 프로필 안에 구독을 여러 개 넣는 패턴은 흔합니다. 원격에서 내려오는 노드 목록이 파일마다 다르므로, 화면의 Proxies 계열 목록에는 접두사·그룹 구조가 섞여 보일 수 있습니다. 이때 중요한 것은 「지금 코어가 읽는 파일」이 무엇인지입니다. Verge 계열에서는 목록에서 활성·선택된 프로필이 곧 그 파일입니다. 새 구독을 추가만 하고 선택을 바꾸지 않으면, 예전 파일이 계속 돌아가며 사용자는 「새 링크를 넣었는데 화면이 그대로」라고 느낍니다.

반대로 프로필을 여러 개 복제해 두는 패턴도 많습니다. 예를 들어 회사 VPN 앞에서만 쓰는 경량 룰, 집에서는 스트리밍 보강이 있는 풀세트, 실험용으로 규칙 공급자만 바꾼 사본 같은 식입니다. 전환은 파일 단위이므로 짧은 시간에 완전히 다른 세계로 바꿀 수 있지만, 전환 직후 시스템 프록시나 TUN이 꺼진 채이면 앱 트래픽이 코어에 안 들어올 수 있습니다. 프로필을 바꾼 뒤에는 한 번씩 연결 스위치와 노드 존재 여부를 확인하는 습관을 들이면 재현성이 좋아집니다.

구독 새로고침: 자동 간격과 수동 업데이트

대부분의 구독은 자동 업데이트 간격이 붙어 있습니다. GUI에 숫자로 보이거나 YAML 안의 subscription 메타데이터로만 존재하기도 합니다. 자동이 걸려 있어도 공급자 측 장애 직후에는 수동으로 한 번 당겨오는 것이 더 빠릅니다. Verge Rev에서는 프로필·구독 화면에서 행마다 새로고침·업데이트 아이콘이 있거나, 상단의 전체 업데이트 같은 항목이 있습니다. 빌드에 따라 레이블이 조금 다르지만 역할은 동일합니다.

「구독은 성공인데 화면이 안 바뀐다」면 대부분 활성 프로필 불일치입니다. 같은 창에서 현재 선택된 파일이 맞는지, 방금 고친 URL이 그 파일에 속해 있는지를 먼저 봅니다. 또 다른 흔한 이유는 복사한 문자열에 공백·줄바꿈이 섞인 것과 대시보드 웹 페이지 링크를 구독 엔드포인트로 착각한 것입니다. 브라우저에서 URL을 열었을 때 사람이 읽기 어려운 텍스트 베이스 구성이 내려와야 정상에 가깝습니다.

프로필 전환 절차: 클릭 한 번 뒤에 꼭 할 일

프로필을 바꾸면 코어는 새 YAML을 다시 읽어야 합니다. Verge 계열은 보통 이 과정을 자동으로 처리하지만, 오래된 프로세스가 남아 구버전 룰이 도는 경우가 있습니다. 전환 후 첫 동작으로 (1) 연결 로그나 상태 표시가 갱신되는지, (2) GLOBAL·주요 select 그룹에 노드가 있는지, (3) 시스템 프록시·TUN이 의도대로인지를 빠르게 훑습니다.

Windows와 macOS 모두에서 다른 프록시 앱이 같은 로컬 포트를 잡고 있으면 전환이 성공한 것처럼 보여도 브라우저는 엉뚱한 곳으로 나갑니다. 프로필을 자주 바꾸는 사용자일수록 백그라운드에 남은 구 클라이언트를 한 번씩 정리하는 편이 안전합니다. 원격 근무라면 회사 제로 트러스트 에이전트와 포트 충돌 가능성도 함께 염두에 둡니다.

Rule·Global·Direct: 의미와 실측 시나리오

세 모드는 mihomo 입장에서 「연결을 라우팅할 때 기본적으로 어떤 큰 그릇을 쓰느냐」의 차이로 이해하면 됩니다. UI 라벨은 클라이언트마다 표기만 다르고 개념은 같습니다.

모드	언제 쓰면 좋은지	실측에서 주의할 점
Rule(규칙)	국내 서비스는 직통·해외만 프록시처럼 평상시 기본값. 룰 품질이 좋을 때 가장 덜 피곤합니다.	특정 도메인만 실패하면 그 도메인이 어느 정책으로 갔는지 로그로 확인하는 편이 빠릅니다.
Global(전역)	「룰이 너무 복잡해서 원인을 못 찾겠다」, 「잠깐 모든 트래픽을 한 출구로 통일하고 싶다」 같은 대조 실험.	국내 금융·OTP 앱까지 프록시로 나가면 인증이 꼬일 수 있으니 목적을 짧게 잡습니다.
Direct(직접)	프록시 체인을 의도적으로 타지 않게 해 노드·프로필 문제인지 망 자체 문제인지 나눕니다.	시스템 프록시는 켜진 채인지, 브라우저만 예외로 돌아가는지 헷갈리기 쉬워 함께 봅니다.

실무에서 추천하는 순서는 다음과 같습니다. 평소에는 Rule 고정. 특정 서비스만 안 열리면 먼저 해당 전략 그룹 안에서 다른 노드를 고르고, 그래도 동일하면 잠깐 Global로 올려 같은 노드에서 열리는지 봅니다. Global에서는 되는데 Rule에서만 안 되면 룰 순서·도메인 항목·DNS 쪽으로 좁힙니다. 이 흐름은 PC 트래픽 로그를 함께 보면 더 빨라지므로 Windows 코어 로그 글과 병행해 보세요.

전략 그룹과 모드 스위치는 별개다

상단 모드가 Rule일 때도, 사용자가 Proxies에서 만지는 것은 대개 select 타입 전략 그룹의 현재 값입니다. Global 모드로 바꾸면 기대하는 것은 「대부분의 새 연결이 사용자가 고른 글로벌 출구 쪽으로 모인다」는 점이지만, 프로필 설계에 따라 예외 룰이 남아 있을 수 있습니다. 반대로 Rule에서 GLOBAL 그룹을 수동으로 특정 노드에 고정해 두었다면, 상단 모드가 Rule이어도 글로벌 버킷 안에서는 사용자 선택이 우선합니다. 헷갈릴 때는 연결 로그의 첫 policy 줄을 보면 어떤 그룹을 거쳤는지 빨리 정리됩니다.

url-test·fallback 그룹은 자동으로 출구를 바꿉니다. 방송·게임 같이 연속성이 중요한 날에는 자동 그룹 대신 select를 직접 고르는 편이 심리적으로도 안정적입니다. Verge Rev는 이런 전환을 마우스 클릭 몇 번으로 끝낼 수 있어, YAML을 직접 편집하는 부담이 줄어듭니다.

같은 노드 이름이 두 그룹에 동시에 보일 때가 있습니다. 하나는 구독이 풀어 준 원본 줄이고, 다른 하나는 상위 그룹이 가리키는 참조일 뿐입니다. 수동으로 고를 때는 어느 카드를 열었는지를 기억해 두는 것이 좋습니다. 잘못 열어 둔 카드에서 다른 노드를 탭하면 「내가 아까 고른 그 그룹이 아니다」라는 느낌만 들고 증상은 그대로일 수 있습니다. 화면이 복잡하면 상단 검색이나 접기 상태를 초기화하고 처음부터 펼쳐 보는 편이 오히려 시간을 아낍니다.

매일 쓸 때의 권장 루틴

아침에 PC를 켠 뒤에는 세 가지만 순서대로 해도 하루가 한결 편해집니다. 첫째, 어제 쓰던 프로필이 그대로 활성인지 제목 줄을 확인합니다. 둘째, 공급자 공지가 있었다면 구독 수동 새로고침을 한 번 누릅니다. 셋째, 상단 모드가 Rule인지 확인한 뒤 브라우저를 연습니다. 이 루틴이 습관이 되면 「어제는 됐는데 오늘은 왜」 같은 상황에서 변수를 빨리 줄일 수 있습니다. 자동 업데이트에만 맡기면 출근 시간대에 노드 대량 교체가 겹쳐 체감이 튈 때도 있으니, 중요한 회의가 있는 날에는 미리 수동으로 당겨 두는 것도 방법입니다.

릴리스 채널이 다른 Verge 빌드를 섞어 쓰면 설정 키 이름이 달라져 문서와 어긋날 수 있습니다. 가능하면 한 기기에는 안정 채널 하나만 두고, 베타 기능이 꼭 필요할 때만 별도 폴더에 실험용을 깔습니다. 여러 EXE·APP을 왕복하면 시스템 프록시 핸들이 꼬여 「켰는데 안 켜진 것처럼」 보이는 경우가 생깁니다. 제거 후 재부팅까지 포함해 한 번 깨끗이 정리하는 것이 장기적으로는 더 빠릅니다.

내장 지연 테스트와 실사이트 검증을 같이 쓰기

노드 옆의 지연(ms) 표시는 보통 구성된 헬스 체크 URL 기준입니다. 실제 방문하려는 CDN edge와 다를 수 있으니, 수치가 예쁘다고 해서 체감이 항상 좋은 것은 아닙니다. 그래도 같은 시각·같은 망에서 상대 비교하는 지표로는 유효합니다. 전부 타임아웃이면 먼저 기본 헬스 URL이 막혔는지, 시스템 시각이 어긋나지 않았는지, 구독이 방금 갱신됐는지를 보고, 그다음 DNS를 의심합니다.

측정 URL이 특정 클라우드 벤더 한 곳만 본다면, 그 벤더 장애 순간에 모든 노드가 동시에 빨간색으로 물들 수 있습니다. 반대로 측정은 실패인데 브라우저만 정상인 경우는 ICMP나 측정 포트가 막힌 공용 와이파이, 사내 보안 프록시가 중간에서 끊는 경우가 흔합니다. 이럴 때는 지연 숫자보다 실제 업무 도메인 두세 개를 고정 테스트 대상으로 두고, 하루에 한 번씩 Rule 상태에서 연결해 보는 편이 신뢰도가 더 높습니다. 노트 앱에 테스트 URL을 적어 두면 가족 구성원과 증상을 공유할 때도 말이 맞습니다.

Verge Rev는 로그 뷰어를 내장한 경우가 많아 정책 이름과 체인이 한 줄로 붙습니다. 여기서 DIRECT가 의도치 않게 보이면 상단 모드가 Direct인지, 아니면 룰 끝의 MATCH가 직접 연결로 떨어지는지부터 확인합니다. 반대로 특정 호스트만 계속 Reject에 걸린다면 공급자의 광고·추적 차단 룰이 과하게 잡았을 수 있으니, 그 도메인을 정책 일람에서 검색해 보는 것이 빠릅니다. GUI에서 한 번에 다 보이지 않으면 임시로 텍스트 편집기로 다운로드된 YAML을 열어 rules: 블록 근처만 스크롤해도 단서가 나옵니다.

1. 문제 재현 도메인을 Rule 상태에서 연다.
2. 동일 노드로 Global을 잠깐 켜 같은 페이지를 연다.
3. 직접 연결 모드에서 ISP 경로로 열리는지 확인해 망 단절 여부를 걸러낸다.
4. 아이콘은 연결인데 페이지만 도는 패턴이면 DNS·fake-ip 점검으로 넘어간다.

자주 묻는 질문

부팅할 때마다 다른 프로필이 활성화돼요

클라이언트가 마지막 선택을 저장하지 못했거나, 동기화·백업 도구가 설정 폴더를 되돌리는 경우가 있습니다. Verge 계열 설정에서 시작 시 프로필 옵션이 있는지 확인하고, 클라우드 동기화 대상에서 런타임 캐시만 제외할 수 있는지 봅니다.

한 프로필에 구독을 추가했더니 이름이 충돌해요

원격 파일이 같은 proxies.name을 쓰면 뒤에서 로드된 항목이 앞을 덮어쓸 수 있습니다. 공급자가 제공하는 prefix·rename 옵션을 켜거나, 충돌이 심하면 프로필을 둘로 나누는 편이 안전합니다.

실무 체크리스트

일상 조작을 덜 지치게 만드는 선택

그래픽 클라이언트가 많을수록 설정 화면이 갈라지고, 프로필·구독·모드 스위치가 서로 다른 깊이에 숨으면 매일 쓰는 사람도 매번 헤맵니다. 특히 포크가 잦은 계열은 업데이트 한 번에 메뉴 이름이 바뀌기도 해 문서를 따라가기 어렵습니다.

Clash / mihomo 계열은 같은 YAML 규칙 모델을 공유하므로, 프로필 전환과 구독 갱신·모드 스위치를 한 화면 흐름에 가깝게 배치한 호환 클라이언트를 고르면 반복 작업이 줄어듭니다. 무엇보다 활성 파일이 무엇인지 항상 보이고, 수동 새로고침이 손닿는 곳에 있어야 일상 사용이 편해집니다.

여러 구독을 오가며 Rule과 Global을 실측하는 패턴을 덜 피곤하게 유지하고 싶다면, 검증된 패키지를 내려받아 같은 워크플로를 이어 가 보세요. 무료 빌드는 다운로드 페이지에서 받을 수 있습니다.