구독 링크 형식 가이드: Clash YAML·Base64 노드 목록·sing-box 설정 변환

구독 주소와 설정 형식: 다운로드 주소와 응답 내용 구분하기

구독 링크는 설정을 가져오는 주소이지, 특정 파일 형식을 뜻하지 않습니다. 클라이언트가 같은 HTTPS 주소에 접속해도 Clash YAML, Base64로 인코딩된 노드 목록, sing-box JSON 등 서로 다른 내용을 받을 수 있습니다. 서비스에 따라 주소 매개변수, 계정 설정, 요청 헤더의 User-Agent를 기준으로 응답 형식을 바꾸기도 합니다. 따라서 링크가 브라우저에서 열린다고 해서 현재 클라이언트에 바로 가져올 수 있는 것은 아닙니다.

문제를 확인할 때는 세 가지를 살펴보세요. 요청이 성공했는지, 응답 내용이 어떤 형식인지, 대상 코어가 해당 프로토콜과 필드를 이해하는지 확인해야 합니다. HTTP 200은 요청에 응답이 왔다는 뜻일 뿐입니다. 실제 내용은 로그인 페이지, 트래픽 만료 안내 또는 오류 JSON일 수 있습니다. 이런 응답을 설정 파서에 넣으면 가져오기 실패, 노드 수 0개, 필드 누락 등의 문제가 생길 수 있습니다.

주요 세 가지 형식에 담기는 정보

형식	일반적인 구조	주로 포함되는 내용
Clash YAML	`proxies`、`proxy-groups`、`rules`	노드, 프록시 그룹, 라우팅 규칙. 전체 설정에는 DNS와 리스너 설정도 포함 가능
Base64 노드 목록	디코딩하면 한 줄에 하나씩 프로토콜 공유 링크가 나열됨	노드 연결 매개변수. 일반적으로 전체 DNS, 규칙, TUN 설정은 포함하지 않음
sing-box JSON	`inbounds`、`outbounds`、`route`	인바운드, 아웃바운드, 라우팅. 전체 설정에는 DNS 등의 모듈도 포함 가능

Clash YAML: 전체 설정과 노드 제공자는 다릅니다

전체 Clash 설정에는 노드, 프록시 그룹, 규칙을 정의할 수 있습니다. 아래는 직접 연결만 사용하는 구조 예시입니다. 혼합 프록시 포트는 7890이며 로컬에서만 수신합니다. 필드 위치를 보여 주기 위한 예시로, 원격 프록시 연결은 제공하지 않습니다. 해당 포트를 로컬의 다른 프로그램이 사용 중이라면 먼저 포트를 변경하세요.

mixed-port: 7890
allow-lan: false
mode: rule
proxies: []
proxy-groups:
  - name: 수동 선택
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,수동 선택

최상위에 proxies만 포함하는 YAML도 있습니다. 이 형식은 proxy-providers의 노드 소스로 사용됩니다. 전체 실행 설정과는 다르므로 기본 설정에서 제공자 이름으로 참조하고 프록시 그룹에서 사용해야 합니다. 마찬가지로 규칙 제공자 파일은 payload로 시작하는 경우가 많으며, 노드 구독으로 가져올 수 없습니다.

‘Clash 형식’도 코어에 따라 지원 범위가 다릅니다. mihomo는 Clash 설정 체계를 이어받으면서 프로토콜 지원과 확장 필드를 추가했습니다. mihomo에서 파싱되는 설정이라고 해서 원본 Clash에서도 파싱되는 것은 아닙니다. 호환 여부는 그래픽 클라이언트 이름이 아니라 실제 사용하는 코어를 기준으로 확인하세요.

Base64: 인코딩 방식일 뿐, 독립적인 프록시 프로토콜은 아닙니다

일반적인 Base64 구독은 여러 줄의 ss://, vmess://, trojan:// 등 공유 링크 전체를 인코딩합니다. 디코딩하면 텍스트가 복원될 뿐, 프록시 그룹이나 라우팅 규칙이 자동으로 만들어지지는 않습니다. 구독이 디코딩 없이 일반 URI 목록을 반환하는 경우도 있습니다. 개별 공유 링크 안에 Base64가 다시 사용되기도 하므로 구독의 외부 인코딩과 프로토콜 자체의 인코딩을 구분해야 합니다.

Base64는 기밀성을 제공하지 않습니다. 디코딩하면 서버 주소, 포트, 인증 정보가 그대로 드러날 수 있습니다. 구독 주소의 토큰과 다운로드한 설정은 모두 인증 정보처럼 안전하게 보관하고, 공개 스크린샷이나 채팅 기록, 지원 요청 첨부 파일에 포함하지 마세요.

sing-box JSON: 대상 버전에 맞는 설정 구조가 필요합니다

sing-box는 일반적으로 JSON으로 설정을 작성하지만, 노드 배열이 들어 있는 JSON이라고 모두 완전한 sing-box 설정인 것은 아닙니다. 아래도 직접 연결만 사용하는 구조 예시입니다. 로컬 7890 포트에서 수신하고, 혼합 인바운드로 들어온 연결을 direct 아웃바운드로 전달합니다.

{
  "inbounds": [
    {
      "type": "mixed",
      "tag": "local-mixed",
      "listen": "127.0.0.1",
      "listen_port": 7890
    }
  ],
  "outbounds": [
    {
      "type": "direct",
      "tag": "direct"
    }
  ],
  "route": {
    "final": "direct"
  }
}

이 예시와 앞의 YAML은 각각 따로 테스트하세요. 두 설정을 동시에 실행해 포트를 서로 점유하게 하지 마세요. 실제 구독에는 TLS, DNS, 라우팅 규칙, 선택기 등이 포함되는 경우가 많으며 각 모듈마다 버전 요구 사항이 다릅니다. 변환 대상은 막연히 ‘JSON’을 선택하지 말고 클라이언트에서 사용하는 sing-box 버전으로 지정하는 것이 좋습니다.

구독 변환 과정: 파싱, 매핑, 구조 보완

변환기는 보통 원본 내용을 읽어 내부 노드 객체로 파싱한 다음 대상 설정 형식에 맞춰 출력합니다. 노드 목록에 없는 프록시 그룹, 규칙, DNS, 리스너 항목은 변환 템플릿이 보완하는 경우가 많습니다. 따라서 변환 결과는 구독 원본뿐 아니라 선택한 템플릿과 변환기가 지원하는 프로토콜 버전에도 좌우됩니다.

원본 형식 확인. 전체 설정인지, 노드 제공자인지, 일반 URI 목록인지, 아니면 먼저 디코딩해야 하는 Base64 텍스트인지 확인합니다.
프로토콜 매개변수 파싱. 서버, 포트, 인증, 전송 계층, TLS 및 프로토콜별 옵션을 추출합니다.
대상 필드에 매핑. 노드를 Clash의 proxies 또는 sing-box의 outbounds에 기록하고 이름 참조를 처리합니다.
실행 구조 생성. 템플릿에 따라 프록시 그룹, 라우팅, DNS를 구성한 다음 대상 코어로 설정을 검사합니다.

예를 들어 Clash 노드의 server와 port는 sing-box에서 일반적으로 server와 server_port에 대응합니다. 하지만 키 이름만 바꾼다고 변환이 끝나는 것은 아닙니다. 프록시 그룹 참조, TLS 객체, 전송 설정, 규칙 동작의 구조가 서로 다릅니다.

형식 변환 시 누락되기 쉬운 필드와 의미

노드를 가져왔더라도 연결 매개변수가 모두 맞는 것은 아닙니다

서버와 포트가 맞는 것은 첫 단계일 뿐입니다. TLS 서버 이름, 인증서 검증 설정, ALPN, WebSocket 경로와 Host 요청 헤더도 핸드셰이크에 영향을 줄 수 있습니다. Reality의 공개 키와 short ID, 프로토콜별 UDP 옵션도 변환기가 명시적으로 지원해야 합니다. 인식하지 못하는 필드를 조용히 삭제하면 구문 검사는 통과해도 연결되지 않을 수 있습니다.

인증 및 인코딩: 비밀번호나 사용자 이름의 특수 문자는 URI 퍼센트 인코딩이 필요할 수 있습니다. 중복 디코딩하면 원래 값이 달라집니다.
전송 계층: WebSocket, gRPC 등의 전송 매개변수를 항목별로 매핑해야 합니다. 노드 유형만 남겨서는 안 됩니다.
TLS: 서버 이름과 검증 정책을 유지하세요. 인증서 오류가 발생하면 원인을 확인해야 하며, 검증 비활성화를 일반적인 변환 해결책으로 사용해서는 안 됩니다.
UDP: 노드 프로토콜, 서버 측, 대상 코어 모두 해당 기능을 지원해야 합니다. 형식 변환만으로 UDP 지원이 추가되지는 않습니다.

규칙, DNS, TUN은 이름만 바꿔 그대로 옮길 수 없습니다

Clash의 proxy-groups와 sing-box의 선택기 및 URL 테스트 아웃바운드는 완전히 같은 기능이 아닙니다. 둘 다 ‘자동 선택’을 지원하더라도 테스트 URL, 검사 간격, 전환 동작은 다를 수 있습니다. 노드 이름을 바꾼 경우 모든 프록시 그룹과 규칙의 참조도 함께 수정해야 합니다. 그렇지 않으면 아웃바운드를 찾지 못하거나 프록시 그룹이 비는 문제가 생깁니다.

Clash의 rules 및 규칙 제공자와 sing-box의 라우팅 규칙 및 규칙 세트도 그대로 복사해 사용할 수 없습니다. 규칙 순서, 도메인 매칭 의미, 최종 폴백 대상을 확인해야 합니다. DNS의 Fake-IP 범위, 도메인 필터, DNS 질의에 사용할 아웃바운드도 실제 접속 방식에 영향을 줍니다. 노드 수만 비교해서는 이런 차이를 찾을 수 없습니다.

TUN은 노드 속성보다 실행 환경 설정에 가깝습니다. macOS의 가상 네트워크 인터페이스 권한, 라우팅 적용, 클라이언트 서비스 구성 요소는 각 클라이언트가 관리합니다. 전체 설정에서 변환한 TUN 필드의 구문이 올바르더라도 대상 Mac 클라이언트의 권한 설정이 완료됐다는 뜻은 아닙니다. 먼저 로컬 프록시 인바운드가 작동하는지 확인하고, 그다음 클라이언트 안내에 따라 TUN을 활성화하세요.

Mac에서 설정을 가져오고 확인하는 순서

먼저 코어를 확인한 뒤 구독 형식을 선택하세요

클라이언트의 ‘정보’ 또는 코어 정보 화면에서 코어 이름과 버전을 확인해 기록합니다. 클라이언트 버전과 코어 버전은 따로 기록하고, 메뉴 경로는 실제 사용 중인 클라이언트에서 확인하세요.
서비스의 구독 관리 페이지에서 알맞은 형식을 선택합니다. mihomo 기반 클라이언트라면 Clash Meta 또는 mihomo라고 명확히 표시된 항목을 우선 선택하세요.
클라이언트의 구독 또는 설정 메뉴에서 원격 주소를 추가하고 업데이트한 다음, 방금 가져온 설정을 선택합니다. 클라이언트마다 메뉴 이름이 다를 수 있습니다.
업데이트 로그와 설정 검사 결과를 확인합니다. 노드 수, 실패한 필드, 오류 줄 번호를 기록한 뒤 변환이 필요한지 판단하세요.

파일 확장자 대신 코어로 설정을 검사하세요

Mac에 해당 명령줄 코어가 설치되어 있다면 터미널에서 아래 검사를 실행할 수 있습니다. 이 명령은 현재 디렉터리의 파일 이름이 각각 config.yaml과 config.json이고, 실행 파일이 PATH에 포함되어 있다고 가정합니다. 그래픽 클라이언트에 내장된 검사 기능으로도 같은 작업을 할 수 있으므로, 확인을 위해 코어 파일을 교체할 필요는 없습니다.

mihomo -t -f config.yaml
sing-box check -c config.json

검사를 통과했다는 것은 대상 코어가 설정을 받아들였다는 뜻일 뿐, 원격 노드 접속 가능 여부나 계정 유효성, 규칙의 적절성까지 보장하지는 않습니다. 검사에 실패하면 원본 설정을 보관하고, 가장 먼저 확인되는 오류부터 수정하세요. 노드, DNS, 규칙을 한꺼번에 바꾸면 비교 기준을 잃을 수 있습니다.

클라이언트에 표시된 실제 혼합 포트가 7890이라면 아래 명령으로 HTTP 프록시를 지정해 로컬 인바운드와 HTTPS 접속을 확인할 수 있습니다. 터미널이 macOS 시스템 프록시 설정을 읽는지 여부와는 관계없이 실행됩니다.

curl --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com

테스트 중에는 클라이언트 연결 기록도 확인해 적용된 규칙과 최종 아웃바운드를 살펴보세요. HTTP 응답을 받았다고 해서 원격 노드를 거친 것은 아닙니다. DIRECT 규칙이 적용되면 트래픽은 직접 연결됩니다. 이 명령은 프록시를 명시적으로 지정하므로 TUN이 터미널 트래픽을 처리한다는 점도 증명하지 못합니다.

가져오기 문제 해결 및 변환 후 확인 목록

‘파싱 실패’ 또는 ‘가져온 뒤 노드가 없음’

먼저 응답 내용이 HTML 로그인 페이지나 오류 안내인지 확인한 다음 설정의 계층 구조를 점검하세요. 전체 설정을 가져오는 곳에 payload만 있는 규칙 파일을 넣거나, 노드 제공자용 입력란에 전체 설정을 넣으면 실패할 수 있습니다. YAML은 들여쓰기를 확인하고 탭 문자는 사용하지 마세요. JSON은 끝에 붙은 쉼표와 문자열의 따옴표를 확인합니다. YAML 텍스트의 파일 이름만 .json으로 바꿔 다시 가져오지 마세요.

‘노드 수는 맞지만 일부 노드에 연결할 수 없음’

연결에 실패한 노드 하나를 골라 변환 전후의 프로토콜, 포트, TLS, 전송 필드를 비교하세요. 특정 프로토콜에서만 오류가 발생한다면 대상 코어와 변환기가 해당 프로토콜을 지원하는지 먼저 확인합니다. 모든 노드에서 동시에 실패한다면 계정 상태, 로컬 네트워크, 시스템 시간, DNS를 점검하세요. 모든 문제를 형식 탓으로 돌리지 않는 것이 중요합니다.

‘수동으로 고쳐도 다음 업데이트 후 원래대로 돌아옴’

원격 구독을 업데이트하면 설정이 다시 생성되거나 덮어써지는 경우가 많습니다. 규칙, 프록시 그룹, DNS 변경을 계속 유지하려면 클라이언트의 오버라이드, 병합 또는 확장 기능을 사용하거나 통제 가능한 변환 템플릿에서 관리하세요. 수정하기 전에 병합 순서와 배열 처리 방식을 확인해야 합니다. 사용자 규칙이 최종 폴백 규칙 뒤에 추가되어 적용되지 않는 문제를 방지할 수 있습니다.

원본 구독 주소와 응답을 보관하고, 변환한 파일은 별도로 저장해 문제가 생기면 되돌릴 수 있게 합니다.
노드 수와 이름, 프록시 그룹 참조를 확인해 의도적인 필터링과 예상치 못한 누락을 구분합니다.
리스너 주소, 실제 포트, LAN 접근 허용 여부, 컨트롤 인터페이스 설정을 확인합니다.
일반 HTTPS, 필요한 UDP 환경, 프록시 및 직접 연결 규칙을 각각 테스트합니다.
구독을 한 번 업데이트해 사용자 설정이 계속 적용되는지 확인합니다.

형식을 선택할 때는 ‘원본 내용, 변환기, 대상 코어’가 서로 맞는지가 핵심입니다. 전체 Clash YAML과 전체 sing-box JSON에는 실행 정책을 담을 수 있지만, Base64 노드 목록은 보통 연결 정보만 제공합니다. 변환이 필요하다면 노드 매핑과 정책 재구성을 따로 점검한 뒤 macOS 시스템 프록시 또는 TUN 적용을 설정하세요.