왜 “구독 변환” 이야기가 나오나

프록시 서비스(흔히 말하는 공항)는 대부분 하나의 구독 URL로 노드 목록을 내려줍니다. 그런데 그 원본이 Base64로 감싼 일반 리스트일 수도 있고, 특정 클라이언트 전용으로만 검증될 수도 있으며, 프로토콜 표기가 Clash 계열 코어가 기대하는 YAML과 다를 수 있습니다. 그 결과 클라이언트에 URL만 붙여 넣었는데 파싱 오류가 나거나, 구독은 받아졌는데 이름·타입이 꼬여 규칙에서 참조하기 어려운 경우가 생깁니다. 이때 필요한 것이 “원본 형식 → Clash 호환 proxies 목록”으로 정리하는 변환 파이프라인입니다.

변환은 “마법처럼 새 노드를 만드는” 과정이 아니라, **이미 제공된 서버 정보를 코어가 읽을 수 있는 문법으로 정렬**하는 작업입니다. 따라서 변환기를 쓰더라도, 최종적으로는 proxy-providers가 가리키는 URL이 안정적으로 갱신되는지, 그리고 그 뒤에 필터를 붙일 수 있는지가 운영에 더 중요합니다.

대시보드에서 복사하는 구독 주소는 보통 HTTPS로 끝나며, 쿼리에 토큰이나 사용자 식별자가 붙어 있습니다. 이 링크는 **비밀번호와 같이 취급**해야 합니다. 공개 채팅방에 올리거나, 스크린샷에 잡히게 두면 다른 사람이 노드를 소비하거나 계정이 남용될 수 있습니다. 브라우저 북마크나 메모 앱에 평문으로만 두지 말고, 가능하면 비밀번호 관리자나 암호화된 노트에 보관하세요.

구독은 갱신 주기가 정해져 있습니다. 너무 자주 새로고침하면 공항 측에서 빈도 제한을 걸거나, 동일한 목록을 반복 내려받느라 트래픽만 낭비할 수 있습니다. 반대로 너무 오래 두면 새로 추가된 노드나 교체된 서버를 놓칠 수 있습니다. 클라이언트의 interval 같은 설정과 공항 안내의 권장 주기를 맞추는 것이 좋습니다. 여러 클라이언트를 동시에 쓰지 않는 한, **한 프로필에서만** 구독을 갱신하도록 정리하면 혼선이 줄어듭니다.

팁

구독 URL을 외부 웹 변환기에 붙여 넣기 전에, 그 서비스가 링크를 서버에 저장하는지, 로그를 남기는지 확인하세요. 민감한 링크는 로컬에서만 처리하거나, 신뢰할 수 있는 오픈 소스 도구를 사용하는 편이 안전합니다.

형식 불일치와 변환 후 흐름

원격 구독이 SS, VMess, Trojan, Hysteria 등 여러 프로토콜을 섞어 제공하면, 코어 버전에 따라 일부 키가 무시되거나 이름이 중복될 수 있습니다. 변환 결과는 항상 **로그에서 한 번** 확인하세요. “이름 중복으로 무시됨” 같은 메시지가 있으면, 공항에서 제공하는 이름 규칙을 바꾸거나, 필터로 접두어가 붙은 노드만 남기는 식으로 정리할 수 있습니다.

변환 후에는 보통 두 가지 경로 중 하나로 갑니다. 첫째, 클라이언트가 구독 URL을 직접 proxy-providers에 넣고, 코어가 주기적으로 받아오게 하는 방식입니다. 둘째, 변환된 YAML을 파일로 저장해 로컬에 두고, 그 파일을 프로바이더의 path로 쓰는 방식입니다. 전자는 갱신이 자동이지만, 변환기에 의존하는 경우가 많고, 후자는 수동이지만 재현성이 높습니다. 팀 내부에서 동일한 프로필을 공유할 때는 후자에 스크립트로 갱신을 얹는 패턴도 흔합니다.

proxy-providers와 필터: 노드를 “덜” 쓰기

mihomo(Clash Meta) 계열에서는 proxy-providers가 원격 구독을 불러온 뒤, filter에 정규식을 넣어 **이름으로 노드를 거를 수** 있습니다. 예를 들어 “한국·일본만 남기고 싶다”면, 노드 이름에 붙는 지역 코드나 키워드를 정규식으로 매칭합니다. 이렇게 하면 UI에서 수십 개의 불필요한 노드가 사라지고, url-test가 측정해야 할 후보도 줄어들어 지연 측정이 빨라집니다.

필터는 “완벽한 정책”이 아니라 **이름 규칙에 의존**합니다. 공항이 노드 이름을 바꾸면 필터가 빈 결과를 낼 수 있으므로, 구독이 갱신된 뒤에는 프로바이더 로그를 확인하는 습관이 필요합니다. YAML 구조 규칙 분기를 이미 읽었다면, 필터로 줄인 노드가 proxy-groups에서 어떤 이름으로 참조되는지까지 연결해서 생각하면 설정이 훨씬 읽기 쉬워집니다.

proxy-providers:
  provider1:
    type: http
    url: "https://example.com/subscribe"
    path: ./providers/provider1.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
    filter: "(?i)(KR|JP|Korea|Japan)"

위 예시는 개념 설명용입니다. 실제로는 공항이 붙이는 이름 규칙에 맞춰 정규식을 조정해야 하며, 대소문자 구분은 (?i) 같은 플래그로 완화할 수 있습니다.

노드 선별 이후: url-test·fallback·tolerance

필터로 후보를 줄인 뒤에는 url-test 그룹으로 “그중에서 가장 빠른 노드”를 고르거나, fallback으로 순서대로 살아 있는 첫 노드를 쓰는 흐름이 일반적입니다. url-test의 url은 실제로 자주 쓰는 사이트와 가까운 엔드포인트를 고르는 것이 좋습니다. 글로벌 CDN 앞단만 재면 모든 노드가 비슷하게 나와 선택이 의미 없어질 수 있습니다.

tolerance는 지연이 조금만 달라도 노드를 바꾸지 않도록 완충하는 값입니다. 너무 작으면 자주 전환되어 세션이 끊기고, 너무 크면 느린 노드에 오래 머물 수 있습니다. 네트워크가 불안정한 환경에서는 tolerance를 넉넉히 잡고, 안정적인 유선 환경에서는 좁게 잡는 식으로 조절해 보세요.

주의

구독에 노드가 매우 많을 때는 health-check와 url-test가 동시에 돌면 CPU·배터리 부담이 커질 수 있습니다. 불필요한 노드는 필터로 먼저 제거하고, 측정 주기는 필요한 만큼만 설정하세요.

규칙과 연동할 때의 습관

노드를 줄였다고 해서 규칙이 자동으로 좋아지지는 않습니다. rules에서 특정 그룹 이름을 가리키고 있다면, 필터로 인해 그 그룹이 참조하는 프로바이더 이름이 바뀌지 않았는지 확인해야 합니다. 또한 국내 트래픽은 DIRECT, 해외만 프록시로 보내는 분할 터널을 쓸 때는, GEOIP·rule-set과 프록시 그룹을 함께 점검하세요. 블로그의 다른 글에서 다루는 DNS·Fake-IP 설정과 맞물리면, “규칙은 맞는데 실제로는 직접 나간다”는 증상이 줄어듭니다.

실전 체크리스트

구독을 새로 넣거나 변환한 뒤에는 다음을 순서대로 확인해 보세요.

  1. 파싱: 코어 로그에 에러 없이 구독이 로드됐는가.
  2. 필터: 의도한 노드만 남았는가, 빈 결과는 아닌가.
  3. 헬스: health-check URL이 타임아웃 나지 않는가.
  4. 그룹: proxy-groups 이름이 규칙·UI와 일치하는가.
  5. 갱신: interval이 공항 정책과 충돌하지 않는가.

한 번에 변환·필터·규칙을 모두 바꾸기보다, 구독만 먼저 안정화하고 필터를 추가한 뒤, 마지막에 규칙을 손대는 식으로 단계를 나누면 되돌리기도 쉽습니다.

정리

구독 변환은 “공항 링크를 Clash에 맞게 한 번 정리하는 과정”이고, 노드 필터링은 “그중에서 실제로 쓸 후보만 남기는 과정”입니다. 둘 다 잘해도 규칙과 DNS가 어긋나면 체감 품질은 나빠질 수 있으므로, 전체 설정을 한 흐름으로 보는 것이 중요합니다.

직접 YAML을 만지지 않아도, 어떤 값이 화면의 구독·프로바이더·전략 그룹과 연결되는지 알면 문제가 났을 때 로그를 훨씬 빨리 이해할 수 있습니다. 최신 클라이언트와 공식 다운로드 페이지에서 안내하는 빌드를 함께 쓰면, 구독 갱신과 필터를 시각적으로 관리하기도 쉬워집니다. → Clash를 무료로 내려받고, 구독 변환과 노드 필터링을 한 번에 정리해 보세요.