구독 형식 정리: Clash 구독과 다른 링크 형식 간 변환 방법

먼저 구독 주소, 노드 링크, 설정 파일을 구분하기

“구독”은 하나의 파일 형식이 아닙니다. 클라이언트에 붙여 넣는 것은 보통 HTTPS 주소이며, 클라이언트가 해당 주소에 요청을 보내면 서버가 Base64 텍스트, Clash YAML, JSON 또는 다른 구조의 데이터를 반환합니다. 주소는 가져오기 위한 진입점일 뿐이고, 클라이언트가 해석할 수 있는지는 응답 본문의 형식에 달려 있습니다. 따라서 같은 구독 주소도 브라우저에서는 단순한 문자열처럼 보이지만, 클라이언트에 따라 “지원하지 않는 형식”, “설정 해석 실패”가 표시되거나 가져온 뒤 노드가 나타나지 않을 수 있습니다.

또 하나 혼동하기 쉬운 개념은 단일 노드 링크입니다. ss://, trojan://, vmess://, vless://로 시작하는 내용은 보통 하나의 프록시 노드만 설명합니다. 반면 구독 본문에는 수십 개의 노드 링크가 하나의 목록으로 묶여 있을 수 있습니다. Clash 네이티브 설정에는 프록시 그룹, 규칙, DNS, 수신 포트 등의 필드가 추가되므로 단순한 노드 모음이 아니라 프록시 코어를 직접 구동할 수 있는 완전한 설정 파일입니다.

콘텐츠 형태	주요 특징	주요 용도	규칙을 그대로 유지할 수 있는가
구독 주소	`https://` URL, 인증 매개변수가 포함될 수 있음	원격 콘텐츠를 정기적으로 가져오기	서버가 반환하는 형식에 따라 다름
단일 노드 URI	`ss://`, `trojan://` 등	하나의 노드 연결 매개변수 공유	불가능
Base64 노드 모음	디코딩하면 보통 한 줄에 하나의 URI가 들어 있음	노드 일괄 배포	대체로 불가능
Clash YAML	`proxies`, `proxy-groups`, `rules` 포함	Clash 또는 호환 코어에서 로드	가능
sing-box JSON	`inbounds`, `outbounds`, `route` 포함	sing-box 및 관련 클라이언트에서 로드	가능하지만 필드 체계가 다름

Clash YAML과 일반적인 노드 링크에 저장되는 정보

Clash 설정은 네 가지 정보로 구성됩니다

기본 Clash 설정에는 보통 수신 설정, 노드, 프록시 그룹, 라우팅 규칙이 함께 저장됩니다. 기존 Clash에서 흔히 사용하는 로컬 혼합 포트는 7890이고, 컨트롤 포트는 대개 9090입니다. 다만 이는 일반적인 기본값일 뿐이며 클라이언트에 따라 다른 포트를 사용할 수 있습니다. 노드는 proxies에, 선택·자동 지연 시간 측정·장애 조치 로직은 proxy-groups에, 도메인과 네트워크 대역의 처리 순서는 rules에 들어갑니다.

mixed-port: 7890
mode: rule
proxies:
  - name: "Tokyo-01"
    type: trojan
    server: edge.example.net
    port: 443
    password: "example-password"
    sni: edge.example.net
proxy-groups:
  - name: "노드 선택"
    type: select
    proxies:
      - "Tokyo-01"
      - DIRECT
rules:
  - DOMAIN-SUFFIX,example.org,노드 선택
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

이 예시는 “Clash를 노드 링크로 변환”할 때 정보가 손실되는 이유를 보여 줍니다. Trojan URI에는 서버, 포트, 비밀번호, SNI 등의 연결 매개변수를 담을 수 있지만, 완전한 proxy-groups와 rules를 저장할 표준 위치는 없습니다. 변환기가 단일 노드 URI만 출력하면 프록시 그룹의 선택 로직, 자동 지연 시간 측정 간격, 규칙 순서가 모두 버려집니다.

노드 URI도 서로 완전히 같은 것은 아닙니다

Shadowsocks:ss://는 주로 암호화 방식, 비밀번호, 호스트, 포트를 설명하며 플러그인 매개변수는 보통 쿼리 문자열에 넣습니다.
Trojan:trojan://은 주로 비밀번호, 서버, 포트, TLS 호스트 이름과 선택적 전송 매개변수를 설명합니다.
VMess:일반적인 공유 형식은 JSON을 인코딩한 뒤 vmess:// 뒤에 넣습니다. 생성기마다 필드 이름과 기본값을 다르게 처리할 수 있습니다.
VLESS:vless://는 쿼리 매개변수로 security, type, sni, flow 등의 정보를 전달하는 경우가 많습니다.
Hysteria2 및 TUIC:클라이언트 코어 버전과 필드 지원 여부에 따라 달라집니다. 구형 Clash 코어는 대체로 완전하게 인식하지 못하지만 mihomo는 더 폭넓게 지원합니다.

변환할 때는 프로토콜 이름만 볼 것이 아니라 전송 계층, TLS, Reality, WebSocket 경로, gRPC 서비스 이름, UDP, 클라이언트 핑거프린트 등의 매개변수도 대조해야 합니다. 프로토콜이 같아도 확장 필드가 다르면 변환 결과가 “가져오기는 성공”하지만 실제 연결은 시간 초과될 수 있습니다.

구독 변환 서비스의 실제 처리 과정

구독 변환은 단순히 확장자를 바꾸는 작업이 아닙니다. 변환 프로그램은 먼저 원본 구독을 가져온 뒤 콘텐츠가 YAML, JSON, Base64 노드 목록 또는 여러 개의 일반 텍스트 URI인지 판별합니다. 그런 다음 입력을 내부 노드 객체로 통일해 파싱하고, 필터링·이름 변경·정렬을 수행한 후 대상 클라이언트의 필드 규칙에 맞춰 다시 직렬화합니다. 대상이 완전한 Clash 설정이라면 프록시 그룹과 규칙 템플릿도 적용해야 합니다.

원본 콘텐츠 가져오기:구독 주소에 HTTP 요청을 보내 리디렉션, 압축 응답, 문자 인코딩을 처리합니다.
입력 형식 식별:URL의 파일명만으로 판단하지 않고 응답 헤더, 텍스트 구조, 프로토콜 접두사를 확인합니다.
노드 매개변수 파싱:서버, 포트, 인증, TLS, 전송 계층 필드를 통일된 구조로 정리합니다.
필터 적용:노드 이름, 지역 키워드 또는 정규 표현식에 따라 항목을 남기거나 제외합니다.
템플릿 적용:프록시 그룹, 지연 시간 측정 그룹, 규칙 제공자, 기본 최종 규칙을 생성합니다.
대상 형식 출력:Clash YAML, 단일 링크 모음 또는 다른 클라이언트가 읽을 수 있는 구조를 생성합니다.

변환 후 노드 수가 달라지는 이유

노드 수가 줄었다고 해서 반드시 네트워크 장애인 것은 아닙니다. 변환기가 인식할 수 없는 프로토콜, 필수 필드가 없는 노드, 이름이 중복된 항목을 의도적으로 건너뛸 수 있습니다. 예를 들어 원본 구독에 86개 노드가 있고 그중 8개는 대상 코어가 지원하지 않는 프로토콜, 3개는 포트 누락, 2개는 중복 제거 과정에서 병합되었다면 최종 73개가 출력되는 것은 설명 가능한 결과입니다. 가장 안전한 확인 방법은 변환 로그의 “읽음, 건너뜀, 출력” 세 숫자를 비교하는 것입니다.

노드 수가 늘어나는 경우는 템플릿 확장이나 구독 병합 때문인 경우가 많습니다. 두 원본 구독에 각각 40개와 35개의 노드가 있다면 병합 후 75개가 될 수 있습니다. 다만 프록시 그룹의 참조 수는 더 많아질 수 있습니다. 같은 노드가 “수동 선택”, “자동 지연 시간 측정”, “장애 조치” 세 그룹에 동시에 포함될 수 있기 때문입니다. 프록시 그룹의 참조 수를 실제 노드 수로 볼 수는 없습니다.

클라이언트 User-Agent가 반환 콘텐츠에 미치는 영향

일부 구독 서비스는 요청의 User-Agent에 따라 서로 다른 형식을 반환합니다. 클라이언트가 Clash라고 선언하면 YAML을 받고, 일반 브라우저로 접속하면 Base64 텍스트나 관리 페이지가 표시될 수 있습니다. 따라서 브라우저에서 본 내용과 클라이언트가 실제로 다운로드한 내용이 다른 것은 드문 일이 아닙니다. 문제를 확인할 때는 브라우저 화면만으로 판단하지 말고 클라이언트 로그에서 응답 상태 코드와 파싱 오류를 확인해야 합니다.

다른 형식에서 Clash 설정으로 변환

노드 링크만 있다면 프록시 그룹과 규칙을 보완해야 합니다

ss://, trojan://, vless:// 링크 모음을 Clash YAML로 변환할 때 첫 단계는 proxies를 생성하는 것뿐입니다. 설정에 proxy-groups가 없으면 사용자가 화면에서 그룹별로 선택할 수 없고, rules가 없으면 규칙 모드에서 트래픽의 경로도 정해지지 않습니다. 최소한의 사용 가능한 템플릿에는 보통 수동 선택 그룹 하나, LAN 직접 연결 규칙 하나, 최종 MATCH 규칙 하나가 포함되어야 합니다.

규칙 순서는 구체적인 항목에서 포괄적인 항목으로 유지해야 합니다. DOMAIN,api.example.com,DIRECT는 DOMAIN-SUFFIX,example.com,노드 선택보다 앞에 와야 하며, MATCH는 반드시 마지막에 있어야 합니다. 변환 도구가 규칙을 다시 정렬하면 원래 직접 연결해야 하는 도메인이 접미사 규칙에 먼저 걸릴 수 있습니다.

대상 코어가 기존 Clash인지 mihomo인지 확인하기

“Clash 형식”에도 기능 차이가 있습니다. 기존 Clash 설정에서 흔히 보이는 필드가 mihomo의 모든 기능을 의미하지는 않습니다. mihomo는 규칙 제공자, DNS, TUN, Sniffer, 신규 프로토콜 관련 필드를 추가하거나 확장했습니다. mihomo 설정을 구형 코어에 가져오면 인식하지 못하는 프록시 유형이나 필드에서 바로 오류가 발생할 수 있고, 일부 선택 항목이 무시될 수도 있습니다.

확인 항목	변환 후 확인할 내용	일반적인 증상
프로토콜 지원	대상 코어가 노드 `type`을 인식하는가	가져오기 실패 또는 노드가 표시되지 않음
TLS 매개변수	`sni`, 인증서 검증, 핑거프린트가 유지되었는가	핸드셰이크 실패, 연결 시간 초과
전송 계층	WebSocket 경로, 요청 헤더, gRPC 서비스 이름	포트에는 연결되지만 프록시를 사용할 수 없음
프록시 그룹 참조	그룹 내 이름이 노드 이름과 완전히 일치하는가	설정 검증에서 프록시를 찾을 수 없다고 표시됨
규칙 제공자	원격 주소, 동작 유형, 업데이트 간격	규칙 세트 다운로드 실패
DNS 및 TUN	주소 대역, 수신 포트, 네트워크 인터페이스 설정이 충돌하지 않는가	TUN 활성화 후 도메인을 해석할 수 없음

Clash YAML을 다른 형식으로 내보낼 때 손실되는 정보

완전한 YAML을 단일 링크 모음으로 내보내면 가장 먼저 손실되는 것은 전역 설정입니다. mixed-port: 7890, LAN 접근 허용 여부, 실행 모드, 외부 컨트롤러, DNS 및 TUN 설정은 단일 노드 URI에 포함할 수 없습니다. 그다음에는 선택 그룹, 로드 밸런싱 그룹, 자동 지연 시간 측정 그룹과 테스트 URL·간격·허용 오차 등 노드 간 조직 관계가 사라집니다.

규칙도 노드 URI에 자연스럽게 연결할 수 없습니다. 도메인 라우팅, IP 대역, 프로세스 이름 규칙, 규칙 제공자, 최종 기본 정책은 대상 클라이언트에서 다시 설정해야 합니다. 변환 대상이 sing-box JSON처럼 또 다른 완전한 설정 형식이라면 변환기가 이러한 구조를 매핑할 수 있지만, 양쪽의 라우팅 의미가 항목별로 일치하지 않으므로 수동 검토가 필요합니다.

이름과 문자 인코딩도 달라질 수 있습니다

URL 조각의 공백, 한글, 기호는 퍼센트 인코딩이 필요하며 잘못 인코딩하면 이름이 잘릴 수 있습니다.
Base64는 표준 문자 집합이나 URL 안전 문자 집합을 사용할 수 있습니다. 패딩 문자를 잘못 처리하면 전체 레코드를 디코딩하지 못할 수 있습니다.
Clash 프록시 그룹에서는 이름이 같은 노드를 구분하기 어렵기 때문에 변환기가 보통 번호를 덧붙이며, 이로 인해 그룹 내 참조도 함께 바뀝니다.
YAML에서 콜론, 샵 또는 앞뒤 공백이 포함된 이름은 따옴표로 감싸야 합니다. 그렇지 않으면 문법으로 해석될 수 있습니다.

직접 구독 변환 서비스를 구축하는 방법

직접 구축의 주요 목적은 통제된 환경에서 구독 콘텐츠를 파싱하는 것입니다. 본인 컴퓨터, 홈 서버, 프라이빗 클라우드 서버 중 어디에 배포해도 됩니다. 어떤 구현을 사용하든 “변환 API”와 “관리 화면”은 분리해서 생각해야 합니다. 전자는 원본 주소와 출력 형식을 처리하고, 후자는 템플릿·필터 규칙·실행 로그를 관리합니다.

개인 컴퓨터 실행은 1인 관리에 적합합니다

로컬 서비스는 127.0.0.1:25500처럼 루프백 주소에만 바인딩해 같은 LAN의 다른 기기가 직접 접근하지 못하게 할 수 있습니다. 클라이언트의 구독 주소는 로컬 인터페이스를 가리키고, 변환 프로그램이 원격 구독을 가져옵니다. 이 방식은 원본 구독을 공개 웹사이트에 제출할 필요가 없지만 컴퓨터가 절전 상태에 들어가거나 서비스가 중지되면 클라이언트의 자동 업데이트가 실패합니다.

서버 배포에서는 접근 범위를 제한해야 합니다

서버 방식은 여러 기기에서 업데이트하기 편리하지만 HTTPS, API 인증, 요청 크기 제한, 접근 로그 순환을 활성화해야 합니다. 변환 API가 임의의 사용자가 제출한 URL을 허용한다면 내부 네트워크 주소에 접근하는 데 악용되지 않도록 막아야 합니다. 최소한 루프백 주소, 링크 로컬 주소, 사설 네트워크 대역을 거부하고 리디렉션 후 최종 주소도 제한해야 합니다.

캐시 정책도 신중해야 합니다. 상위 구독이 6시간마다 업데이트된다고 가정하면 변환 캐시를 15~60분으로 설정해 클라이언트가 실행될 때마다 반복 요청하는 일을 줄일 수 있습니다. 단, 캐시 파일에는 전체 노드 인증 정보가 포함되므로 저장 권한과 만료 후 삭제를 함께 설정해야 합니다. 로그에는 완전한 쿼리 문자열을 기록하지 말고 요청 시간, 출력 유형, 상태 코드, 비식별화된 작업 ID만 남기는 것이 좋습니다.

템플릿은 버전 관리에 포함해야 합니다

변환 서비스가 업그레이드되면 기본 프록시 그룹 이름이나 필드 동작이 바뀔 수 있습니다. clash-template-2026-05.yaml처럼 템플릿에 명확한 버전을 부여하고, 수정할 때마다 테스트 설정에서 검증한 뒤 운영 템플릿을 교체하는 것이 좋습니다. 노드 구독과 규칙 템플릿을 분리해 보관하면 상위 구독이 업데이트될 때 로컬 라우팅 로직이 덮어써지는 일을 막을 수 있습니다.

변환 완료 후 확인하는 5단계

문법 검증 실행:먼저 클라이언트에 가져오기만 하고 바로 활성화하지 마세요. YAML 들여쓰기, 중복 이름, 프록시 그룹 참조에 오류가 없는지 확인합니다.
노드 수 대조:원본 노드 수, 건너뛴 수, 출력 수를 기록하고 지원하지 않는 프로토콜과 필수 필드 누락을 중점적으로 확인합니다.
단일 노드 테스트:정상 작동이 확인된 노드 하나를 선택해 지연 시간을 측정한 다음 HTTPS 페이지에 접속해 TLS와 전송 매개변수가 정상인지 확인합니다. 80 ms 또는 200 ms라는 지연 시간만으로는 실제 연결 테스트를 대신할 수 없습니다.
규칙 적용 확인:클라이언트 연결 기록을 열고 직접 연결해야 하는 도메인과 프록시를 사용해야 하는 도메인에 각각 접속해 적용된 규칙과 프록시 그룹이 템플릿 설계와 일치하는지 확인합니다.
DNS 및 TUN 검증:먼저 시스템 프록시를 테스트한 뒤 필요할 때 TUN을 활성화합니다. 시스템 프록시는 정상인데 TUN만 이상하다면 DNS 하이재킹, 가상 네트워크 인터페이스 권한, 라우팅 충돌을 확인하고 문제를 곧바로 노드 변환 탓으로 돌리지 마세요.

데스크톱 클라이언트에서는 버전에 따라 설정 메뉴 이름이 달라질 수 있습니다. 일반적인 경로는 「설정」→「구독」에서 원격 파일을 업데이트한 뒤 「프록시」에서 프록시 그룹을 선택하는 방식입니다. 일부 클라이언트는 업데이트 주기를 「설정」→「매개변수 설정」에 둡니다. 업데이트 후 현재 활성화된 설정이 실제로 새 파일로 전환되었는지 확인해 테스트 대상이 이전 캐시로 남아 있지 않도록 하세요.

자주 발생하는 변환 실패 증상과 확인 순서

구독 주소는 열리지만 클라이언트에서 파싱 실패가 표시됨

먼저 응답이 클라이언트에 필요한 형식인지 확인하세요. 브라우저에 정상적인 웹페이지가 표시된다는 것은 HTTP 요청이 성공했다는 뜻일 뿐입니다. 로그인 페이지, 사용량 안내, HTML 오류 페이지가 반환되면 Clash는 파싱할 수 없습니다. 이어서 응답 상태 코드, 리디렉션 후 도메인, 콘텐츠 시작 부분을 확인하세요. YAML에 탭 문자가 섞였거나 들여쓰기 단계가 잘못되었거나 닫히지 않은 따옴표가 있어도 전체 설정 로드가 실패할 수 있습니다.

가져오기는 되지만 모든 노드가 시간 초과됨

모든 노드가 시간 초과되면 노드를 하나씩 바꾸기보다 먼저 변환 매개변수를 확인하세요. 서버 주소, 포트, TLS의 sni, WebSocket 경로, gRPC 서비스 이름, Reality 공개 키 등의 필드를 대조해야 합니다. 원본 형식의 확장 매개변수를 대상 형식으로 표현할 수 없다면 변환기가 겉보기에는 완전하지만 연결할 수 없는 노드를 출력할 수 있습니다.

업데이트 후 기존 규칙과 그룹이 사라짐

대개 “노드 구독”을 “완전한 설정”으로 착각해 로컬 파일을 덮어쓴 경우입니다. 올바른 방법은 원격 노드를 프록시 제공자를 통해 로드하거나 변환 단계에서 로컬 템플릿을 고정 적용하는 것입니다. 노드 데이터는 변경을 담당하고 규칙과 그룹은 템플릿이 관리하도록 분리하면 상위 구독 업데이트가 로컬 라우팅 구조를 직접 덮어쓰지 않습니다.

노드 이름은 정상인데 프록시 그룹이 비어 있음

프록시 그룹이 노드 이름을 정적으로 나열하는지, 제공자를 통해 참조하는지 확인하세요. 정적 이름은 공백, 대소문자, 변환기가 추가한 번호까지 포함해 한 글자도 다르지 않게 일치해야 합니다. 정규 표현식으로 필터링한다면 이름 변경 단계에서 지역명이 바뀌었는지도 확인해야 합니다. 예를 들어 먼저 “Hong Kong”을 “홍콩”으로 바꾸면 Hong Kong만 일치시키는 기존 필터 표현식은 빈 결과를 반환합니다.

변환 방식을 선택할 때의 실용적인 권장 사항

구독 제공업체가 Clash 또는 mihomo 전용 주소를 제공한다면 중간 매핑을 줄이기 위해 해당 형식을 우선 사용하세요. 원본 형식이 대상 클라이언트와 호환되지 않거나, 여러 출처를 병합해야 하거나, 사용자 지정 그룹과 규칙이 꼭 필요할 때만 변환 단계를 추가하는 것이 좋습니다. 변환 단계가 길어질수록 문제를 해결할 때 확인해야 할 캐시, 템플릿, 필드 매핑도 늘어납니다.

소수의 노드를 임시로 옮길 때는 로컬에서 단일 링크 변환을 수행하면 됩니다. 여러 구독을 장기간 사용할 경우 고정 템플릿을 만들고 변환기 버전을 기록하는 편이 적합합니다. 여러 기기에서 자동 업데이트가 필요하다면 인증 기능이 있는 프라이빗 서비스를 배포할 수 있습니다. 어떤 방식을 선택하든 최종 기준은 “파일 생성 성공”이 아니라 문법 로드 가능 여부, 노드 매개변수의 완전성, 규칙 적용의 정확성, 업데이트 과정의 반복 검증 가능성입니다.