Clash Verge Rev에서 구독 자동 갱신 간격(주기) 맞추기: 예약 동기·즉시 풀·실패 알림까지 (2026)

1. 자동 갱신 주기를 손대는 이유

구독 URL은 일종의 원격 설정 창고입니다. 운영자가 서버 주소를 바꾸거나 정책 그룹을 조정하면, 로컬에 캐시된 YAML만 오래 붙잡고 있으면 갑자기 연결이 끊기거나 빈 그룹이 보일 수 있습니다. 자동 갱신은 그 창고를 주기적으로 다시 열어 최신 내용을 mihomo 코어에 넘기는 절차입니다. 반대로 주기를 지나치게 짧게 하면 동일 URL에 대한 요청이 잦아져 구독 제공자 정책이나 CDN에서 비정상 트래픽으로 보일 여지도 있습니다. 「얼마나 자주 자동으로 당겨올지」는 네트워크 부하, 제공자 안내, 개인의 운영 습관 사이에서 균형을 잡는 단일 설정 항목에 가깝고, 라우팅 규칙 전체를 다시 짤 필요는 없습니다.

검색 의도가 이 글과 맞는 독자는 보통 세 가지를 동시에 원합니다. 첫째, 클라이언트 화면 어디에서 업데이트 간격을 바꾸는지. 둘째, 타이머로 도는 예약 동기와 내가 버튼으로 누르는 동작이 같은 API를 타는지. 셋째, 실패했을 때 알림만 보고 끝낼 것인지, 로그까지 내려가서 TLS나 DNS로 넘길 것인지입니다. 아래 절은 그 순서대로 짧게 이어집니다.

2. Verge Rev와 mihomo 코어가 구독을 풀할 때

Clash Verge Rev는 화면 단에서는 구독 목록·프로필 스위치·알림을 보여 주지만, 실제 HTTP(S) 요청으로 YAML을 내려받고 파싱해 코어에 넘기는 부분은 mihomo(또는 호환 코어) 쪽 규칙과 맞물립니다. 그래서 「브라우저에 붙여 넣으면 파일이 보이는데 앱만 실패한다」는 패턴이 나오면, 문제는 간격 숫자가 아니라 그 순간의 프록시 경로·DNS·TLS 신뢰 체인에 있는 경우가 많습니다. 간격 조절은 운영 편의용이고, 그런 실패는 연결 로그·트래픽 모니터 글에서 다루는 진단 루틴으로 이어집니다.

자동 갱신이 한 번 돌 때마다 앱은 보통 구독 메타데이터를 갱신하고, 활성 프로필에 반영할 파일을 다시 합칩니다. 프로필 머지나 오버라이드가 얹혀 있다면, 풀은 성공했는데 화면의 노드 구성이 기대와 다를 수 있으니 다중 구독·머지 글에서 우선순위를 함께 확인하는 편이 덜 헷갈립니다.

3. 앱에서 간격·자동 동기를 찾는 법

릴리스마다 메뉴 라벨이 조금씩 옮겨질 수 있으므로, 여기서는 위치보다 찾아야 할 키워드를 기준으로 짚겠습니다. 상단 메뉴 또는 햄버거 메뉴에서 설정·환경설정·Preferences 계열 항목을 연 뒤, 구독·Subscription·자동 업데이트·자동 갱신 같은 문구가 붙은 구역을 찾습니다. 그 안에 간격을 분 또는 시간으로 고르는 컨트롤, 혹은 숫자 입력칸이 함께 있는 경우가 많습니다. 비활성 스위치가 따로 있다면 「자동으로 주기적 갱신」이 꺼져 있을 때는 수동 새로고침만 동작하고 타이머는 돌지 않습니다.

설정을 바꾼 뒤에는 앱을 한 번 완전히 종료했다가 다시 켜서 백그라운드 스케줄이 기대대로 잡혔는지 확인하는 습관이 좋습니다. 특히 macOS는 절전·앱 nap 때문에 다음 실행 시점이 사용자가 상상하는 「정각」과 어긋나 보일 수 있어, 알림만 믿지 말고 로그에 실제 풀 시각이 찍히는지 대조합니다.

4. Windows와 macOS에서 달라지는 체감

Windows에서는 백그라운드에서 타이머가 도는 동안 시스템 프록시나 TUN이 이미 켜져 있다면, 풀 요청이 직접 연결이 아니라 특정 프록시 그룹을 타게 됩니다. 구독 도메인이 실수로 국내 직통이나 느린 노드로 빠지면 자동 갱신만 간헐적으로 실패하는 그림이 나올 수 있으니, 규칙 상단에 구독 호스트를 안정적인 정책에 두었는지 한 번만 확인합니다. 방화벽 팝업을 예전에 거절해 둔 경우에도 백그라운드 요청만 막히는 일이 있어, Win10·Win11 첫 설정 글에서 말한 허용 범위와 맞춰 둡니다.

macOS는 시스템 설정의 네트워크·방화벽·VPN 슬롯과 Clash의 TUN 스택이 같은 시점에 겹치면 라우팅이 꼬여 보일 수 있습니다. 자동 갱신 알림이 오지 않으면 알림 권한을 먼저 보고, 로그 뷰에 동일 오류 문자열이 찍히는지 확인합니다. Apple 플랫폼에서 백그라운드 작업이 제한되는 경우도 있어, 며칠 켜 두지 않은 뒤 첫 실행에서 짧은 간격으로 연속 풀이 몰리는 현상은 「누적된 지연이 한꺼번에 처리된다」는 식으로 이해해도 무방합니다.

5. 수동 새로고침·즉시 풀

예약 동기를 아무리 길게 잡아도, 제공자가 긴급 공지로 URL을 바꾼 날에는 즉시 새 구성을 받아야 합니다. 구독 카드나 목록에서 항목별로 제공되는 새로고침·갱신·업데이트 버튼은 타이머를 기다리지 않고 해당 URL에 대한 풀을 한 번 실행합니다. 전체 프로필을 한 번에 갱신하는 상단 액션이 따로 있다면, 여러 구독을 동시에 운용할 때 시간을 아낄 수 있습니다. 수동 풀 직후 코어가 자동으로 재시작되지 않는 빌드라면, 프로필 적용·서비스 재시작 메뉴가 별도로 있는지 확인합니다.

운영 팁으로는 「문제가 터진 직후」에만 수동 풀을 쓰고, 평소에는 긴 간격을 유지하는 방식이 로그와 서버 양쪽에 덜 부담입니다. 제공자 대시보드에서 권장 갱신 주기를 안내하는 경우가 있으니, 앱 기본값만 고집하지 말고 그 숫자를 참고해도 좋습니다.

# Example: profile snippet — per-subscription interval (if your merge preserves it)
proxy-providers:
  example:
    type: http
    url: "https://example.com/sub"
    interval: 3600

위 예시는 고급 편집으로 YAML을 볼 때의 필드 이름일 뿐, GUI에서 바꾼 글로벌 간격과 어떻게 합쳐지는지는 빌드와 템플릿에 따라 다릅니다. 숫자가 이중으로 얽혀 있다면 머지 결과 한 번만 검증합니다.

6. 실패 알림·로그로 원인 좁히기

실패 알림은 대개 다음 중 하나로 요약됩니다. HTTP 상태 오류(403·404·429), TLS 핸드셰이크 실패, 타임아웃, DNS가 빈 응답을 준 경우, 혹은 다운로드는 됐지만 YAML 파싱에 실패한 경우입니다. 알림 문구만으로는 한계가 있으므로, 로그에서 같은 타임스탬프의 스택을 찾습니다. TLS·DNS 전체 루틴은 앞서 링크한 Windows 전용 글에 맡기고, 여기서는 간격 설정과의 상관관계만 짚으면 됩니다.

간헐적 실패가 짧은 주기로 바꾼 뒤부터 늘었다면 rate limit을 의심합니다. 반대로 변경 없이 갑자기 전부 실패한다면 구독 URL 자체의 만료·차단·리다이렉트 문제일 가능성이 큽니다. 브라우저에서 같은 URL을 열었을 때는 되는데 앱만 안 되면, 앱이 타는 DNS와 프록시 경로가 브라우저와 다르다는 신호입니다. 한 번 성공한 뒤 증상이 사라지면 일시적 네트워크 이슈였을 수 있으니, 그때는 간격을 더 줄이기보다 로그 보존 기간만 늘려 두고 관찰해도 됩니다.

7. (선택) YAML의 interval과 GUI 값

고급 사용자는 생성된 프로필 안에 proxy-providers·rule-providers 각각에 interval 초 단위 필드가 들어 있는 것을 볼 수 있습니다. GUI의 글로벌 자동 갱신은 그중 일부를 덮어쓰거나, 앱이 별도 스케줄러로 동일 URL을 먼저 당겨온 뒤 코어에 주입하는 방식일 수 있습니다. 따라서 「GUI에서 60분으로 바꿨는데 YAML은 3600초가 아니다」처럼 보일 수 있고, 그게 곧바로 버그는 아닙니다. 궁금하면 편집 직후 파일을 한 번 저장해 두고 diff로 추적합니다.

rule-providers 갱신 주기는 구독과 별개인데, 지오·도메인 세트가 오래되면 규칙은 살아 있어도 매칭이 어긋납니다. 이 글의 범위를 넘어서는 주제이므로 rule-providers·GEOIP 갱신 글에서 이어가면 됩니다.

8. 자주 묻는 질문