Mihomo(Clash Meta) 구독 자동 갱신
YAML의 interval과 lazy(지연 로딩)를 뜻대로 맞추기

1 왜 interval·lazy를 따로 공부할 가치가 있나

데스크톱·모바일 GUI는 «구독 새로고침» 버튼만 보여 줄 뿐, 백그라운드에서 몇 초마다 원격을 두드리는지는 config.yaml의 proxy-providers에 있습니다. Clash Meta 엔진을 쓰는 배포판이 Mihomo 이름으로 팔리는 경우가 많아 검색어가 섞이지만, 이 글에서 말하는 필드는 같은 계열 YAML에 붙습니다. 사용자가 원하는 것은 (1) 공항 쪽 요청 빈도를 존중하면서도 (2) 너무 느슨해 노드가 바뀌어도 모르는 상태를 피하고, (3) 가능하면 알림·로그 스팸을 줄이는 세 가지입니다. 이를 위해 자동 갱신 타이머 본체인 interval과, 트래픽 관점의 지연 로딩에 가까운 lazy를 분리해 이해하는 것이 중요합니다.

이미 믹스인으로 프로필을 덧씌우는 사용자라면,《mixin·구독 오버라이드》에서 말한 것처럼 최종 합쳐진 YAML에서 어느 층이 interval을 덮는지도 함께 봐야 합니다. 값이 예상과 다르면 «코어가 무시한다」기보다 나중에 로딩된 조각이 이긴 경우가 많습니다.

2 interval: 구독을 다시 내려받는 주기

proxy-providers 블록의 interval은 해당 url에서 원격 텍스트를 다시 받아와 로컬 path에 반영하는 폴링 주기입니다. 단위는 보통 초이며, 3600이면 한 시간에 한 번입니다. 숫자를 극단적으로 낮추면 체감상 «항상 새로고침되는 것 같다»고 느낄 수 있지만, 피크 시간에는 쓸데없는 대역·CPU·로그를 늘립니다. 반대로 며칠 단위로 밀면, 공항이 중간에 서버를 바꿔도 클라이언트 목록이 낡은 채로 남을 수 있습니다.

실무에서는 (a) 공항 공지의 권장 갱신 주기·rate limit을 먼저 보고, (b) 자신이 노드 이름을 수시로 바꾸는지, (c) 모바일·밧데리 환경인지를 곱해 기본값을 잡습니다. 데스크톱 전용이면 1800~7200초 대역이 흔하고, 여행·회전 IP가 잦으면 조금 짧게 잡되 차단 로그가 보이면 즉시 되돌리는 편이 안전합니다.

proxy-providers:
  airport:
    type: http
    url: "https://example.com/sub?token=REPLACE_ME"
    path: ./providers/airport.yaml
    interval: 3600
    # lazy: true   # optional: defer fetch until referenced
    header:
      User-Agent: "clash"  # follow your provider readme if 403

3 lazy: 지연 로딩과 «조용한» 의미

lazy: true는 provider를 코어가 뜨자마자 전부 당기지 않고, 선택·규칙·그룹이 실제로 그 provider를 참조할 때 가져오게 하려는 옵션으로 이해하면 실무 대화가 빨라집니다. 여러 백업 구독을 파일에 넣어 두었지만 평소에는 한두 개만 쓰는 경우, 불필요한 원격 요청을 줄여 배터리·로그를 아끼는 데 도움이 될 수 있습니다. 다만 «절대 자동으로 안 당긴다»는 뜻은 아니고, 참조가 발생하거나 내부 스케줄·버전에 따라 이후 주기적 갱신은 계속될 수 있습니다. 정확한 엣지 케이스는 사용 중인 Mihomo 빌드의 공식 문서·릴리스 노트를 따르세요.

사용자 입장에서 조용한 갱신은 두 층으로 나뉩니다. 첫째는 HTTP 요청 자체를 줄이는 것(lazy·긴 interval), 둘째는 GUI 배너·토스트가 코어 이벤트마다 뜨지 않게 앱 설정을 조정하는 것입니다. 후자는 YAML만으로 안 끊기는 경우가 많으니, «interval을 늘렸는데도 팝업이 많다»면 클라이언트의 자동 업데이트 알림 항목을 별도로 확인하세요.

4 헬스 체크 interval은 다른 타이머다

같은 YAML 안에도 이름이 interval인 필드가 두 종류 있습니다. proxy-providers 최상단의 interval은 «원격 구독 파일을 언제 다시 받나」이고, 그 아래 health-check 블록의 interval은 «이미 파싱된 노드들의 지연을 얼마나 자주 재측정하나」입니다. 전자를 늘려 HTTP를 줄였는데도 UI의 ms 숫자가 자주 바뀐다면, 후자가 여전히 짧게 남아 있을 수 있습니다. 반대로 헬스만 늘려도 노드 목록 자체는 낡을 수 있습니다.

proxy-providers:
  airport:
    type: http
    url: "https://example.com/sub?token=REPLACE_ME"
    path: ./providers/airport.yaml
    interval: 3600        # remote snapshot refresh
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600       # latency re-measure for loaded nodes

url-test·fallback 그룹에도 비슷한 주기 필드가 있어 검색 결과와 혼동되기 쉽습니다. «구독을 덜 당기고 싶다»는 목표라면 proxy-providers.interval을 먼저 만지고, 그다음에 헬스·그룹 쪽이 과하게 짧지 않은지 봅니다. 그룹 타입별 차이는《URL-Test·Fallback》에 정리되어 있습니다.

5 rule-providers도 같은 실수가 난다

규칙 세트를 외부에서 당기는 rule-providers 역시 interval·lazy 비슷한 패턴을 가질 수 있습니다. 사용자가 «구독만 느리게»라고 생각했는데 실제로는 대형 Rule Provider가 매 시간 GitHub raw를 긁고 있어 트래픽이 새는 경우가 있습니다. 하나의 프로필을 의심할 때는 providers 디렉터리 전체의 크기·수정 시각을 훑어, 어느 파일이 과도하게 자주 갱신되는지부터 역추적하는 편이 빠릅니다. GEO/GEOIP 데이터 수동 관리가 필요하면《GeoIP·GeoSite 수동 갱신》도 참고하세요.

6 바꾼 뒤 실제로 먹었는지 확인하는 순서

(1) 편집 전 백업을 만들고, (2) log-level: info 이상에서 코어를 재시작하거나 프로필을 다시 로드합니다. (3) 몇 분 기다린 뒤 로그에서 provider 이름·HTTP 코드·다운로드 시각을 찾습니다. (4) path에 저장된 파일의 mtime을 보고, 기대한 주기보다 훨씬 자주 바뀌면 다른 블록·외부 스케줄러·GUI의 별도 타이머가 겹친 것입니다. (5) external-controller와 yacd 같은 패널을 켜 두었다면, 리스트 화면에 보이는 갱신 시각이 로그·파일과 맞는지 교차 확인합니다.

Android·Termux처럼 절전과 백그라운드 제한이 심한 환경에서는 interval을 짧게 잡아도 실제로는 배터리 정책 때문에 한꺼번에 몰아서 갱신되는 것처럼 보일 수 있습니다. 이때는 OS 측의 «백그라운드 허용」과 별개로, YAML상 설정이 맞는지부터 분리해 생각해야 합니다. 구체 절차는《Termux·Mihomo 구독》 맥락과 맞닿습니다.

자주 묻는 질문

interval에 0이나 음수를 넣으면 어떻게 되나요?

구현·버전에 따라 무시되거나 기본값으로 돌아갈 수 있습니다. «가능한 한 자주»가 목적이라면 공식 문서에서 지원하는 최소 간격과 공항 정책을 동시에 확인하세요. 비정상 값은 오히려 CPU 루프나 예외 로그를 부를 수 있습니다.

lazy를 켰는데도 첫 부팅 직후 트래픽이 잠깐 튄다면?

일부 그룹·규칙이 부팅 직후 모든 provider를 훑도록 작성돼 있을 수 있습니다. rules와 proxy-groups의 use: 목록을 다시 보고, 불필요한 provider 참조를 줄이면 첫 웨이브 HTTP가 줄어듭니다.

Windows 패키지에서 YAML을 바꿨는데 반영이 안 됩니다.

GUI가 다른 경로의 프로필을 보고 있거나, 편집기가 임시 파일만 저장했을 수 있습니다. 실제 로드 경로는 클라이언트 설정 화면·로그 첫머리에 찍히는 디렉터리를 기준으로 삼으세요. 1회성 검증은《Windows·Mihomo 설치》 흐름과 같이 보는 편이 수월합니다.

7 정리

Mihomo·Clash Meta에서 구독 자동 갱신의 중심은 proxy-providers의 interval이고, lazy는 지연 로딩으로 불필요한 초기 당김을 줄이는 보조 스위치입니다. 헬스 체크 interval·rule-providers·GUI 전용 타이머와 섞이면 체감이 엇나가므로, 로그·파일·대시보드를 한 세트로 묶어 검증하세요. 이 주제는 mixin으로 덮어쓰기하는《구독 오버라이드》·갱신 실패 HTTP 점검 글과 겹치지 않게 역할을 나눕니다.

일부 범용 프록시 앱은 구독 주기를 숫자로 손대기 어렵거나, 내부 스케줄과 중복 요청이 나도 원인 로그가 잘 안 보입니다. 반면 Clash Verge Rev처럼 Mihomo 코어를 전제로 한 클라이언트는 YAML을 그대로 열어 interval·lazy를 명시하고, 로그·외부 컨트롤러와 맞춰 보면서 같은 설정을 데스크톱·노트북에 옮기기 쉽습니다. 앱마다 다른 «자동 새로고침» UX에 지친 경우, 한 번이라도 텍스트 프로필로 원리를 잡아 두면 이후 트러블슈팅이 훨씬 가벼워집니다. 같은 목적이라면 다운로드 허브에서 본인 OS용 빌드를 골라 보는 것도 부담이 크지 않습니다.

→ Clash를 내려받아 Mihomo 구독 간격을 클라이언트에서 바로 검증하기