Clash Verge Rev 구독 자동 새로고침 간격 설정: Mihomo Profile YAML과 실제 적용을 세 단계로 맞추기

검색 의도: 왜 GUI만 보거나 YAML만 보면 틀어지나요?

사용자가 검색창에 Clash Verge Rev와 구독 자동 업데이트를 함께 넣을 때의 진짜 목표는 단순히 “숫자 칸에 값 넣기”가 아니라, 구독 새로고침이 코어 스케줄러에 어떻게 예약되는지까지 포함해 신뢰할 수 있는 상태를 만드는 일입니다. Verge 계열은 원격 공항 링크를 로컬 메타데이터로 관리한 뒤 Mihomo가 소비할 수 있는 형태로 YAML을 조립합니다. 이 과정에서 화면의 한 줄과 디스크 위 최종 파일의 한 줄이 어긋나면, 사용자는 “방금 분명히 고쳤는데 왜 노드 타임스탬프가 안 움직이지?”처럼 증상만 보게 되고 원인 추적이 길어집니다.

또 다른 흔한 착시는 “편집기로 직접 연 파일이 곧 실행 파일”이라 가정하는 버릇입니다. mixin으로 원격 구독과 로컬 패치를 합치거나, 여러 Profile 중 하나만 활성화해 두었을 때 눈에 보이는 경로와 실제 로드 경로가 다를 수 있습니다. 그래서 이 주제의 정답 형태는 항상 세 줄기가 동시에 맞는지 확인하는 것입니다. 첫째, 구독 행에 저장된 의도 간격입니다. 둘째, 병합 결과물 속 proxy-providers에서 읽히는 주기입니다. 셋째, 지금 켜 둔 활성 프로필 이름과 로그에 찍히는 갱신 이벤트입니다. 이 세 가지가 같은 스토리를 말하면 설정은 정렬된 것이고, 하나라도 빗나가면 나머지 두 줄기를 의심해야 합니다.

1단계: Clash Verge Rev GUI에서 구독 자동 새로고침 간격 정하기

빌드마다 메뉴 라벨은 조금씩 바뀌지만 추상화는 안정적입니다. 프로필 또는 구독 관리 화면으로 들어가 각 원격 항목 옆의 속성을 열면 자동 업데이트 토글과 숫자 입력칸이 붙어 있습니다. 여기서의 숫자는 대개 현실 시간 기준으로 이해하기 쉬운 단위를 전제로 하므로, 사용자는 “몇 시간 혹은 몇 분마다 한 번 당길지”를 먼저 결정하면 됩니다. 다만 저장 버튼을 누른 직후에는 반드시 활성 프로필 이름이 바뀌지 않았는지 확인하세요. 비활성 프로필의 구독만 수정하고 활성 것은 그대로 두면, 체감상으로는 “간격 설정이 먹히지 않는다”와 동일한 패턴이 나옵니다.

Windows 노트북과 맥북을 번갈다 쓰는 경우에도 위 순서는 같습니다. 차이는 단축키와 파일 탐색기 대신 파인더를 연다는 정도이며, 핵심은 “어느 OS든 같은 논리 블록을 수정했는가”입니다. 설치 직후 디렉터리 구조가 헷갈리면 각각의 시작 가이드를 먼저 밟아 두는 편이 이후 YAML 대조 단계에서 시간을 아낍니다.

2단계: Mihomo Profile YAML에서 proxy-providers 주기 필드와 숫자 단위 맞추기

GUI 저장이 끝나면 Verge는 내부적으로 원격 구독을 proxy-providers 형태로 정리해 코어에 넘깁니다. 사용자가 확인해야 할 것은 이 블록 안의 주기 필드입니다. 문서와 버전에 따라 interval로 보이거나 관측 경험상 update-interval이라고 부르는 필드와 개념이 혼재할 수 있으니, 표제줄이 proxy-providers인지 rule-providers인지부터 구분하는 습관이 중요합니다. 규칙 세트 쪽 주기와 프록시 노드 공급자 쪽 주기는 이름도 의미도 다르므로 한쪽만 보고 결론 내리면 안 됩니다. 규칙 목록 전용 트러블슈팅은 rule-providers 경로·간격 글을 참고하면 됩니다.

숫자만 다르게 보일 때는 성급히 “버그”라 부르기보다 단위 변환부터 의심합니다. Mihomo 계열 설정에서는 프록시 프로바이더 주기가 초 단위로 기록되는 관행이 흔해서, GUI에서 120분을 입력했는데 파일에는 7200처럼 보이는 형태가 나올 수 있습니다. 반대로 어떤 빌드에서는 분 단위 입력을 그대로 문자열로 넘기는 UX도 있어 버전별 릴리스 노트를 한 줄이라도 읽어 두면 혼선이 줄어듭니다. 핵심은 표면 숫자가 같지 않아도 wall-clock 의미가 같으면 정상이라는 점과, 같아 보여도 단위가 다르면 실제 주기가 한 자릿수에서 어긋날 수 있다는 점입니다.

# Illustrative proxy-providers excerpt — keys vary by export path
proxy-providers:
  airport-example:
    type: http
    url: "https://example.com/subscription-token"
    interval: 3600
    path: ./providers/airport-example.yaml

위 예시는 교육용으로 단순화한 형태이며 실제 환경에서는 헤더·프록시 이름·경로가 더 길게 펼쳐집니다. 중요한 것은 interval 같은 주기 키가 존재한다면 GUI에서 의도한 간격과 같은 시간축으로 환산되는지 확인한다는 점입니다. 파일을 직접 고친 뒤에는 앱이 다음 저장 때 값을 되돌릴 수 있으므로, 장기적으로는 GUI 메타를 진실 소스로 두고 mixin으로 안전하게 덧대는 패턴을 검토하는 것이 좋습니다. 자가 노드와 공항 구독을 섞는 경우 mixin 병합 글의 순서를 함께 읽으면 덮어쓰기 충돌을 줄일 수 있습니다.

GUI 숫자와 YAML 숫자를 헷갈리지 않기 위한 관점 정리

관측 지점	확인할 질문
구독 행 메타	자동 새로고침이 켜져 있고 분·시간 입력이 의도와 같은가?
proxy-providers	주기 필드가 초 단위인지 분 단위인지 문맥으로 구분했는가?
rule-providers	규칙 세트 간격을 프록시 공급 간격과 혼동하지 않았는가?
활성 Profile	방금 편집한 파일이 지금 코어가 로드한 파일과 같은가?

표는 방향 나침반일 뿐 절대 규칙이 아닙니다. 실제 값은 릴리스와 사용자가 켠 실험 기능에 따라 조금씩 달라질 수 있어, 최종 판단은 항상 “수동 새로고침 한 번 통과 → 자동 간격 한두 주기 관측”으로 마무리하는 편이 안전합니다.

3단계: 활성 프로필·수동 갱신·로그로 실제 적용 검증하기

YAML 숫자가 예쁘게 맞아도 코어가 다른 파일을 읽고 있으면 의미가 없습니다. Verge 상단이나 설정 패널에서 현재 선택된 Profile 이름을 메모한 뒤, 방금 대조한 파일 경로와 일치하는지 다시 확인합니다. 그다음 각 구독에 대해 한 번씩 수동 업데이트를 실행해 HTTP 오류나 TLS 문제가 없는지 걸러 냅니다. 수동이 안 되면 자동 간격을 아무리 줄여도 소용이 없으니, 이 단계에서 실패하면 URL·인증서·캡티브 포털부터 분리합니다.

수동이 성공했다면 이제 시간축 검증으로 넘어갑니다. 클라이언트가 제공하는 마지막 갱신 시각이나 로그 패널에서 provider 관련 메시지를 찾아 간격이 지난 뒤에도 갱신 이벤트가 재등장하는지 봅니다. 코어가 완전히 내려갔다가 다시 올라오면 타이머 기준점이 초기화될 수 있으니, 테스트 중에는 불필요한 반복 재시작을 피하는 편이 재현성을 높입니다. 장시간 검증이 부담스러우면 테스트 기간에만 간격을 크게 줄였다가 검증 후 제공자 권장 값으로 되돌리세요.

mixin·다중 Profile·외부 편집이 간격을 어긋나게 만드는 패턴

숙련 사용자일수록 mixin 파일에 커스텀 헤더나 로컬 패치를 추가합니다. 이때 원격 구독만 덮어쓰는 레이어와 GUI 메타 레이어가 서로 다른 시간 정보를 가질 수 있습니다. 해결책은 단순합니다. 한 시점에 하나의 진실 소스만 두고 나머지는 그 소스를 존중하게 만드는 것입니다. 예를 들어 간격은 항상 Verge 구독 화면에서만 바꾸고 mixin에는 노드 이름 매핑만 넣는 식으로 역할을 분리하면 충돌이 줄어듭니다.

다중 Profile을 운영할 때는 이름 표기가 비슷한 항목을 실수로 활성화하는 일이 생깁니다. 여행용 경량 프로필과 집에서 쓰는 풀 규칙 프로필을 번갈다 쓰는 경우 특히 그렇습니다. 활성 이름과 실제 로드 YAML 경로를 동시에 확인하지 않으면 “방금 고친 간격이 반영 안 된다”는 착시가 반복됩니다. 프로필 전환 UX와 수동 갱신 버튼 위치는 이미 정리된 프로필·구독·모드 글을 같이 보세요.

Windows와 macOS에서 달라지는 것과 달라지지 않는 것

달라지는 쪽은 파일 브라우저 경로, 메뉴 언어, 가끔의 샌드박스 권한 입니다. 달라지지 않는 쪽은 Mihomo가 이해하는 YAML 스키마와 provider 스케줄러 모델입니다. 따라서 크로스 플랫폼 사용자는 OS별 설치 글을 통해 데이터 루트만 정확히 짚어 두면 나머지 절차는 복붙 수준으로 재사용할 수 있습니다. 회사 노트북과 개인 맥을 동시에 쓸 때도 “활성 Profile 이름 + proxy-providers 숫자 + 로그 타임스탬프” 삼각 검증은 동일하게 적용됩니다.

또 한 가지, 노트북 절전과 데스크톱 상시 가동은 타이머 체감에 차이를 줍니다. 코어 프로세스가 슬립 동안 완전히 멈추면 다음 깨어남 시점에 스케줄 기준점이 바뀔 수 있어, 사용자는 “간격이 지켜지지 않는다”고 느낄 수 있습니다. 이는 운영체제 전원 정책 이슈에 가깝고 YAML 오류와 구분하는 편이 빠릅니다.

자주 묻는 질문

GUI에서 바꾼 값이 YAML에 안 보입니다.

다른 Profile이 활성인지, 저장 후 재생성 단계가 남았는지 확인하세요. mixin으로 경로가 갈라졌다면 편집기에서 연 파일이 실행 파일이 아닐 수 있습니다.

숫자가 GUI와 파일에서 다릅니다.

초와 분 환산 여부를 먼저 의심하세요. rule-providers와 proxy-providers 블록을 혼동하지 않았는지도 함께 봅니다.

간격을 매우 짧게 두면 더 안전한가요?

아니요. 레이트 리밋과 로컬 I/O 부하가 늘고 증상만 복잡해질 수 있습니다. 제공자 가이드를 우선합니다.

마무리 체크리스트

정리와 다음 단계

일부 범용 프록시 클라이언트는 화면에서 간격을 바꿔도 내부 캐시나 보조 프로세스가 오래된 값을 붙잡아 사용자에게 투명한 로그를 주지 않는 경우가 있습니다. 제공자 패널과 클라이언트 간 불일치가 생겨도 어느 층에서 어긋났는지 추적하기 어렵다면 운영 피로도만 누적됩니다.

Clash 생태계와 Mihomo 계열 구성은 통상적으로 구독 공급자 블록과 주기가 텍스트 설정에 명시적으로 드러나므로, GUI 조정과 YAML 검증을 같은 루틴에 넣기 좋습니다. 여러 기기에서 같은 프로필을 재사용할 때도 숫자 의미를 공유하기 쉬워 교육 비용이 줄어듭니다.

공항 규칙과 노드를 시간에 맞춰 받아 오면서도 데스크톱 설정을 한눈에 추적하고 싶다면, 아래 링크에서 플랫폼에 맞는 Clash 빌드를 받아 실제 흐름을 비교해 보시길 권합니다. Clash 다운로드 페이지 바로 가기