1. 구독 주소, 인코딩, 설정 형식
‘구독 링크’는 콘텐츠를 가져오는 경로일 뿐, 고정된 파일 형식을 뜻하지 않습니다. 같은 HTTPS 주소라도 요청 매개변수나 클라이언트 식별 정보에 따라 노드 공유 링크 목록, Clash YAML 설정 또는 다른 클라이언트 전용 설정을 반환할 수 있습니다. 주소 끝에 .yaml이 붙어 있는지만으로 바로 가져올 수 있는지 판단할 수는 없습니다.
구독을 판단할 때는 세 가지를 구분해야 합니다. 주소는 콘텐츠를 가져오고, Base64는 바이트를 텍스트로 인코딩하며, 설정 형식은 노드와 프록시 그룹, 규칙을 정의합니다. Base64는 암호화도 프록시 프로토콜도 아닙니다. 구독을 디코딩해도 원래 텍스트만 복원될 뿐, 라우팅 규칙이 새로 생기지는 않습니다.
| 일반적인 콘텐츠 | 판별 기준 | 주로 포함하는 항목 | 가져올 때 유의할 점 |
|---|---|---|---|
| 노드 URI 목록 | 여러 줄의 ss://, vmess://, trojan:// 링크 | 노드 주소, 인증 정보, 일부 전송 매개변수 | 클라이언트 가져오기 기능이나 변환 도구로 파싱 |
| Base64 노드 구독 | 겉으로는 긴 인코딩 문자열이며, 디코딩하면 URI 목록이 나옵니다 | 보통 노드 정보만 포함 | 완성된 YAML 설정으로 바로 사용할 수 없음 |
| Clash YAML 설정 | proxies, proxy-groups, rules 등의 키 | 노드, 프록시 그룹, 규칙 및 선택적 런타임 매개변수 | 커널 호환성은 별도로 확인해야 함 |
| 프록시 제공자 파일 | 최상위에는 주로 proxies 목록이 있음 | proxy-providers에서 참조하는 노드 모음 | 대개 기본 설정 파일과 함께 사용 |
| 다른 클라이언트 설정 | 전용 섹션이나 JSON 구조 | 해당 클라이언트의 노드 및 라우팅 설정 | 확장자만 바꿔서는 가져올 수 없음 |
2. Base64 노드 링크에 포함되는 정보
일반적인 노드 구독은 여러 공유 링크를 줄바꿈으로 이어 붙인 뒤, 전체 텍스트를 Base64로 인코딩합니다. 일부 프로토콜은 공유 링크 내부에서도 Base64를 사용하므로 구독 인코딩과 프로토콜 인코딩이 겹칠 수 있습니다. 한 번 디코딩한 결과에 vmess://나 ss://가 보인다고 해서 노드 매개변수가 모두 풀린 것은 아닙니다.
공유 링크에 자주 포함되는 항목
- 연결 인증 정보: 서버, 포트, 비밀번호 또는 UUID, 프로토콜에 필요한 암호화 방식.
- 전송 정보: TLS, SNI, WebSocket 경로와 Host, gRPC 서비스 이름 등. 포함 여부는 프로토콜과 공유 링크 형식에 따라 다릅니다.
- 표시 정보: 노드 메모는 URI 조각에 포함되는 경우가 많으며, 퍼센트 인코딩되어 저장됩니다.
예를 들어 두 노드가 모두 443 포트에 연결하더라도 하나는 일반 TLS를 사용하고, 다른 하나는 특정 WebSocket 경로까지 요구할 수 있습니다. 변환기가 서버, 포트, 비밀번호만 남기면 두 번째 노드는 핸드셰이크에 실패할 수 있습니다. 포트가 같아도 연결 매개변수는 다를 수 있으며, 443만으로 TLS가 활성화된다고 단정할 수 없습니다.
노드 공유 링크에는 보통 전체 DNS 정책, 규칙 순서, TUN 라우팅, 자동 프록시 그룹이 들어 있지 않습니다. 이런 구독을 Clash 설정으로 변환할 때 변환기는 별도의 템플릿을 적용하는 경우가 많습니다. 따라서 새 설정에 표시되는 ‘자동 선택’이나 ‘지역 그룹’은 원본 구독이 아니라 템플릿에서 추가됐을 수 있습니다.
안전하게 콘텐츠 확인하기
신뢰할 수 있는 클라이언트의 설정 미리보기나 로컬 편집기에서 응답을 확인하는 것이 좋습니다. 디코딩이 필요하다면 로컬 도구를 사용하고, 전체 내용을 공개 터미널 기록에 남기지 마세요. 디코딩한 뒤 확인할 수 있는 비밀번호, UUID, 구독 토큰도 민감 정보입니다. 문제를 점검할 때는 인증 정보를 제거한 구조와 오류가 난 줄 번호만 공유하세요.
3. 전체 YAML과 노드 제공자 구분하기
YAML은 데이터를 표현하는 방식일 뿐, 파일이 반드시 완전한 설정이라는 뜻은 아닙니다. Clash 계열 설정은 보통 proxies로 노드를 정의하고, proxy-groups로 선택 방식을 구성한 뒤, rules로 연결 경로를 정합니다. 아래 예시는 이 세 항목의 참조 관계를 보여 줍니다. 예시 도메인과 비밀번호는 실제 연결에 사용할 수 없습니다.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies:
- name: 예시 노드
type: trojan
server: edge.example.com
port: 443
password: example-password
sni: edge.example.com
skip-cert-verify: false
proxy-groups:
- name: 수동 선택
type: select
proxies:
- 예시 노드
- DIRECT
rules:
- DOMAIN-SUFFIX,example.org,DIRECT
- MATCH,수동 선택여기서 7890은 로컬 HTTP/SOCKS 혼합 프록시의 수신 포트이며, 원격 노드의 포트가 아닙니다. 마지막 규칙인 MATCH는 앞선 규칙에 일치하지 않은 연결을 ‘수동 선택’으로 보냅니다. 변환 과정에서 그룹 이름을 바꾸면서 규칙의 참조 이름을 함께 수정하지 않으면 설정을 불러오지 못할 수 있습니다.
proxy-providers에는 기본 설정이 필요합니다
프록시 제공자를 사용하면 노드 업데이트와 기본 설정을 분리할 수 있습니다. mihomo에서 일반적인 YAML 제공자 파일의 최상위에는 보통 proxies:가 있습니다. 기본 설정의 proxy-providers에 파일을 선언하고, 프록시 그룹에서 use로 참조합니다. 노드 목록만 있는 파일은 규칙과 프록시 그룹을 갖춘 기본 설정과 다릅니다.
일부 클라이언트는 노드만 있는 콘텐츠를 가져올 때 기본 그룹을 자동으로 추가할 수 있습니다. 하지만 이는 가져오기 기능일 뿐, 모든 클라이언트가 지원한다고 볼 수는 없습니다. 원격 설정을 선택하기 전에 해당 링크가 ‘전체 설정’을 요구하는지 ‘노드 제공자’를 요구하는지 확인하세요. 사용자 지정 규칙을 유지해야 한다면 기본 설정과 제공자를 함께 사용하거나 클라이언트의 오버라이드 기능을 활용하는 편이 좋습니다. 구독 갱신 때마다 덮어써지는 파일을 계속 수동으로 수정하지 마세요.
4. 구독 변환 중 누락되기 쉬운 항목
변환은 보통 ‘원본 콘텐츠 파싱 → 중간 노드 데이터 생성 → 대상 형식으로 출력’ 순서로 진행됩니다. 어느 단계에서든 인식하지 못하는 항목은 무시되거나 이름이 바뀌거나 기본값으로 대체될 수 있습니다. YAML이 생성됐다는 것은 텍스트가 출력됐다는 뜻일 뿐, 대상 커널이 원래 매개변수대로 연결할 수 있다는 의미는 아닙니다.
| 확인할 항목 | 자주 발생하는 변경 | 확인 방법 |
|---|---|---|
| TLS 및 전송 매개변수 | SNI, ALPN, WS Host 또는 경로 누락 | 원본 노드를 항목별로 대조하고, 인증서 검증을 끄는 것으로 문제를 대신 해결하지 마세요 |
| 새 프로토콜 및 확장 | 변환기가 인식하지 못하거나 대상 커널이 지원하지 않음 | 원본 파서, 출력 대상, 실행 커널을 모두 확인 |
| 프록시 그룹 및 규칙 | 대상 템플릿으로 다시 생성되어 그룹 이름과 순서가 변경됨 | 규칙 대상이 존재하는지, MATCH가 올바른 위치에 있는지 확인 |
| DNS 및 TUN | 원본 설정의 런타임 옵션이 반영되지 않음 | 구독 원문만 보지 말고 최종 적용된 설정 확인 |
| 구독 부가 정보 | 트래픽 사용량, 만료일 등의 응답 헤더 정보가 전달되지 않음 | 대시보드 표시 정보와 노드 연결 매개변수를 구분 |
Clash, Clash Premium, Clash Meta(현 mihomo)는 지원하는 필드 범위가 완전히 같지 않습니다. 변환기의 ‘Clash’ 대상은 구형 커널에 맞춘 출력일 수도 있습니다. mihomo를 사용한다면 필요한 프로토콜과 필드를 지원한다고 명시된 출력 대상을 선택하세요. 파일 이름에 Meta가 들어 있다고 호환성을 판단할 수 없으며, 그래픽 클라이언트 버전만으로 커널 기능을 추측하는 것도 적절하지 않습니다.
5. 구독 변환 및 가져오기 순서
- 가능하면 클라이언트용 기본 출력을 선택하세요. 제공업체가 현재 커널에 맞는 Clash 또는 mihomo 설정을 제공한다면 먼저 그대로 사용하세요. 중간 파싱 단계를 줄일 수 있습니다. 정상적인 YAML을 다시 변환기에 넣지 마세요.
- 다운로드 결과를 확인하세요. 응답이 노드 텍스트인지 YAML인지, 아니면 로그인 페이지나 오류 페이지인지 확인합니다. HTTP 요청이 성공했다고 해서 응답이 설정 파일이라는 보장은 없습니다.
<!DOCTYPE html>로 시작하는 콘텐츠는 일반적으로 구독 설정으로 불러올 수 없습니다. - 신뢰할 수 있는 변환 환경을 선택하세요. 변환이 필요하다면 로컬에서 실행하는 도구나 신뢰할 수 있는 제공업체의 변환 링크를 우선 사용하세요. 온라인 변환 서비스가 원본 구독 토큰과 노드 인증 정보를 볼 수 있습니다.
- 대상 커널과 템플릿을 정하세요. 먼저 필요한 프로토콜을 출력할 수 있는지 확인한 뒤 규칙 템플릿을 선택합니다. 노드 목록만 필요한 경우에는 기본 설정을 통째로 교체하는 대신 출력이 프록시 제공자에 맞는지 확인하세요.
- 새 설정으로 테스트하세요. 기존에 작동하는 설정은 보관하고 변환 결과를 별도 설정으로 가져오세요. 설정 검사 결과를 확인한 뒤 커널을 실행합니다. 오류가 나면 로그를 보고 원인을 찾고, 유일하게 사용할 수 있는 설정 파일을 바로 덮어쓰지 마세요.
- 최종 적용된 설정을 확인하세요. 클라이언트가 전역 오버라이드, 병합 또는 스크립트를 적용할 수 있습니다. 다운로드한 원본 YAML만 보지 말고 처리 후의 그룹 이름, 규칙, DNS, 포트를 확인하세요.
변환 URL에 원본 구독 주소를 넣을 때는 보통 매개변수 인코딩이 필요합니다. 원본 주소에 &나 #이 있으면 그대로 이어 붙일 경우 토큰이 잘리거나 일부가 별도 매개변수로 처리될 수 있습니다. 도구의 입력란이나 표준 URL 인코딩 기능을 사용하세요. 주소 전체를 여러 번 직접 인코딩하지 말고, 생성된 주소를 공개 게시판에 올리지 마세요.
6. 가져온 뒤 확인할 네 가지
1. 노드 수와 주요 매개변수
원본 구독에 노드가 12개인데 변환 결과가 9개뿐이라면 먼저 프로토콜 지원, 지역 필터, 중복 제거 설정을 확인하세요. 다음으로 작동하는 노드 하나 이상을 골라 서버, 원격 포트, SNI, 전송 매개변수를 대조합니다. 개수가 같아도 필드가 모두 보존됐다는 뜻은 아닙니다. 노드 이름을 바꾸면 이름 기준 규칙에도 영향을 줄 수 있습니다.
2. 설정 문법과 참조
YAML 계층 구분에는 Tab이 아니라 공백을 사용합니다. proxy not found 같은 오류가 나면 그룹 내부 참조와 규칙 대상을 확인하세요. 파싱 오류라면 로그에 표시된 줄과 바로 윗줄부터 들여쓰기, 콜론, 따옴표를 점검합니다. 노드 이름에 특수 문자가 있으면 올바른 YAML 따옴표를 사용해 모호성을 줄일 수 있습니다.
3. 지연 시간, 실제 요청, 규칙 적용
지연 시간 테스트가 성공했다는 것은 해당 테스트 요청에 응답이 왔다는 뜻일 뿐, 모든 사이트에 접속할 수 있다는 의미는 아닙니다. 먼저 시스템 프록시를 사용해 브라우저 요청을 확인한 다음 연결 패널에서 규칙, 프록시 그룹, 최종 노드를 살펴보세요. 기본 연결이 정상임을 확인한 뒤 시스템 프록시를 따르지 않는 앱까지 처리해야 한다면 TUN을 설정하세요. 라우팅, DNS, 형식 문제를 한꺼번에 점검하지 않도록 주의합니다.
4. 구독 갱신 후 수정 사항 유지 여부
구독을 한 번 수동으로 갱신한 뒤 사용자 지정 규칙이 남아 있는지, 노드 제공자가 업데이트됐는지, 프록시 그룹에서 노드를 선택할 수 있는지 확인하세요. HTTP 제공자의 interval: 3600은 갱신 간격을 초 단위로 설정한다는 뜻이며, 1시간입니다. 그래픽 클라이언트의 구독 갱신 주기는 별도 설정일 수 있으므로 노드 상태 검사 간격과 혼동하지 마세요.
7. 형식 선택과 자주 묻는 질문
Base64를 디코딩했는데도 바로 가져올 수 없는 이유는 무엇인가요?
디코딩은 콘텐츠를 복원할 뿐 Clash 설정을 구성하지 않습니다. 노드 URI 목록이 나왔다면 클라이언트가 공유 링크 가져오기를 지원해야 하며, 그렇지 않으면 대상 커널에서 읽을 수 있는 노드 정의로 변환해야 합니다. 파일 확장자를 .yaml로 바꿔도 내부 구조는 달라지지 않습니다.
다른 클라이언트의 JSON을 Clash 형식으로 바로 변환할 수 있나요?
변환기가 해당 구조를 구체적으로 지원하는지에 따라 다릅니다. 예를 들어 sing-box JSON에는 아웃바운드뿐 아니라 자체 DNS 및 라우팅 로직도 포함될 수 있습니다. 노드 매개변수를 변환할 수 있더라도 라우팅 의미가 그대로 옮겨지지 않을 수 있습니다. 노드 이전과 규칙 재구성을 따로 확인하고, ‘JSON 지원’을 모든 클라이언트 설정 지원으로 해석하지 마세요.
장기간 사용할 때는 전체 설정과 노드 제공자 중 무엇을 선택해야 하나요?
제공업체가 설정한 규칙을 그대로 사용하려면 기본 전체 설정이 간편합니다. 사용자 지정 라우팅을 장기간 관리하려면 기본 설정과 노드 제공자를 함께 사용하는 편이 업데이트를 분리하기 좋습니다. Base64 노드 구독만 있다면 목표 형식을 명확히 정한 뒤 변환하세요. 어떤 방식을 선택하든 원본 링크를 보관하고 커널 지원 범위를 확인한 다음, 실제 연결과 규칙 적용으로 최종 검증해야 합니다.