구독 주소, 응답 형식, 설정 파일을 구분하기
구독 주소는 콘텐츠를 가져오는 경로일 뿐입니다. https://로 시작하는 링크가 전체 Clash 설정을 반환할 수도 있고, Base64로 인코딩된 노드 목록을 반환할 수도 있습니다. 주소에 “clash”가 들어 있거나 파일명이 .yaml로 끝난다는 사실만으로는 실제 응답 내용을 확인한 것이 아닙니다.
일부 서비스는 요청 매개변수, 클라이언트 식별 정보 또는 계정 설정에 따라 서로 다른 형식으로 응답합니다. 따라서 같은 주소라도 브라우저와 클라이언트에서 가져오는 내용이 다를 수 있습니다. 문제를 진단할 때는 파일 확장자를 계속 바꾸기보다 실제로 가져온 경로, 응답 본문 유형, 클라이언트에서 사용하는 코어를 기록하세요.
| 형식 | 식별 가능한 구조 | 일반적인 구성 | 가져오기 위치 |
|---|---|---|---|
| 전체 Clash YAML | proxies:, proxy-groups:, rules: 등의 필드 | 노드, 프록시 그룹, 규칙 및 기타 설정 | 설정 파일 또는 원격 설정 가져오기 경로 |
| 노드 제공자 YAML | 주로 최상위 proxies: 목록 | 기본 설정에서 참조하는 노드 모음 | proxy-providers에 연결되는 리소스 |
| Base64 노드 목록 | 디코딩하면 보통 한 줄에 URI 하나가 표시됨 | 노드 연결 매개변수. 일반적으로 트래픽 분기 규칙은 없음 | 해당 형식을 지원하는 구독 가져오기 경로 또는 변환 도구 |
| 단일 노드 URI | ss://, trojan:// 등의 접두사 | 노드 하나와 해당 프로토콜 매개변수 | 해당 프로토콜을 지원하는 노드 가져오기 경로 |
Clash YAML에는 노드뿐 아니라 프록시 그룹과 규칙도 포함됩니다
전체 설정에서 proxies는 연결 매개변수를, proxy-groups는 노드 선택 방식을, rules는 트래픽 경로를 정의합니다. 변환기가 노드만 추출하면 나머지 두 항목은 사라집니다. DNS, 수신 포트, TUN 설정도 단일 노드 URI만으로는 온전히 표현할 수 없습니다.
최소 구성 예시
다음은 일반적인 Trojan 노드를 기본 설정에 추가하는 예입니다. 도메인과 비밀번호는 구조를 설명하기 위한 값이며 실제 연결에는 사용할 수 없습니다. 7890은 로컬 혼합 프록시 포트이고 443은 원격 노드 포트이므로 서로 바꿔 쓸 수 없습니다.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies:
- name: "demo-trojan"
type: trojan
server: edge.example.com
port: 443
password: "demo-password"
sni: edge.example.com
udp: true
proxy-groups:
- name: "수동 선택"
type: select
proxies:
- "demo-trojan"
- DIRECT
rules:
- MATCH,수동 선택여기서 MATCH,수동 선택은 최종 대체 규칙이며, 지역이나 도메인별로 나눈 트래픽 분기 정책을 뜻하지 않습니다. 프록시 그룹에서 DIRECT를 선택하면 해당 그룹과 일치하는 연결은 직접 접속하고, 예시 노드를 선택하면 그 노드를 통해 연결을 시도합니다.
name은 참조 식별자입니다. 노드 이름을 바꾸면 프록시 그룹에서 이전 이름을 사용하는 항목도 함께 수정해야 합니다.server는 연결 대상이고sni는 TLS 핸드셰이크에 사용하는 서버 이름입니다. 실제 환경에서는 두 값이 다를 수 있습니다.udp: true를 설정하면 해당 노드가 관련 UDP 전달에 참여할 수 있지만, 이것만으로 서버나 현재 접속 방식이 모든 UDP 트래픽을 지원한다고 볼 수는 없습니다.
Base64 디코딩은 텍스트를 복원할 뿐, Clash 필드를 만들어 주지 않습니다
Base64는 인코딩 방식이지 프록시 프로토콜이나 암호화가 아닙니다. 여러 줄의 노드 링크를 텍스트 한 덩어리로 묶을 수 있지만, 프록시 그룹이나 DNS, 규칙을 자동으로 추가하지는 않습니다. Base64 문자열을 디코딩해 config.yaml로 저장하더라도 내용이 URI 목록이라면 Clash 설정 파서가 이를 YAML 기본 설정으로 처리할 수 없습니다.
두 단계로 내용 확인하기
- 먼저 바깥쪽 응답 본문을 확인하세요.
proxies:와 같은 구조가 바로 보이면 우선 YAML로 검사하고, 억지로 디코딩하지 마세요. - 본문이 인코딩된 것처럼 보이는 문자열이라면 로컬 도구로 디코딩한 뒤, 결과가 읽을 수 있는 텍스트인지 확인하세요.
- 디코딩 결과의 각 줄이
ss://나trojan://등으로 시작한다면 대개 노드 목록입니다. 프로토콜을 파싱하고 필드를 매핑하는 작업이 추가로 필요합니다. - 결과가 HTML 오류 페이지, 로그인 안내 또는 JSON 오류라면 먼저 구독 접근 문제를 해결해야 합니다. 노드 변환을 계속 진행해서는 안 됩니다.
예를 들어 aGVsbG8=를 디코딩하면 hello가 됩니다. 이는 인코딩을 되돌릴 수 있다는 뜻일 뿐, 유효한 구독이라는 뜻은 아닙니다. 표준 Base64는 보통 +, /, 끝의 =를 사용합니다. URL 안전 변형은 -, _를 사용하며, 일부 구현은 패딩 문자를 생략하기도 합니다. 디코더는 실제 변형에 맞게 처리해야 하며 노드 원문을 임의로 바꾸면 안 됩니다.
구독 바깥쪽의 인코딩과 노드 내부의 인코딩도 구분해야 합니다. 예를 들어 일부 Shadowsocks URI는 사용자 정보 부분 자체에 Base64를 사용합니다. 바깥쪽을 디코딩해 ss://를 얻었더라도 해당 URI 규격에 따라 파싱해야 하며, URI 전체를 다시 기계적으로 디코딩해서는 안 됩니다.
단일 노드 URI를 YAML로 변환하기: 연결 매개변수 매핑
아래 URI는 앞서 든 Trojan 예시와 기본 연결 정보를 동일하게 나타냅니다. “수동 선택” 프록시 그룹이나 MATCH 규칙은 포함하지 않습니다. 끝부분은 노드 이름이며, 실제 이름에 공백이나 한글, 특수 문자가 들어 있다면 내보내기 도구가 URI 규칙에 맞게 인코딩해야 합니다.
trojan://[email protected]:443?security=tls&sni=edge.example.com#demo-trojan| URI 구성 요소 | YAML 대응 필드 | 확인 사항 |
|---|---|---|
trojan:// | type: trojan | 대상 코어가 해당 프로토콜을 지원해야 합니다 |
demo-password | password | 규격에 따라 퍼센트 인코딩을 처리하고 원래 자격 증명의 의미를 유지하세요 |
edge.example.com | server | SNI 값으로 연결 주소를 임의로 덮어쓰지 마세요 |
:443 | port: 443 | 정수로 입력하고 1~65535 범위인지 확인하세요 |
sni=edge.example.com | sni | 서버 인증서 및 배포 요구 사항과 일치하는지 확인하세요 |
#demo-trojan | name | 이름을 디코딩한 뒤 중복 항목과 프록시 그룹 참조를 확인하세요 |
프로토콜마다 서로 다른 매핑 표를 사용해야 합니다
Shadowsocks에는 보통 cipher와 password가 필요합니다. VMess에는 UUID, 전송 계층, TLS 매개변수가 자주 사용되며 VLESS, Hysteria2 등은 대상 코어의 지원 범위도 확인해야 합니다. 오리지널 Clash와 Clash Meta(mihomo)는 지원하는 프로토콜이 다르므로 변환 대상은 단순히 “Clash 호환”이라고 적지 말고 사용할 코어까지 지정해야 합니다.
WebSocket 경로와 Host 요청 헤더, gRPC 서비스 이름은 실제 연결에 필요한 매개변수입니다. 예를 들어 mihomo 설정에서는 network: ws, ws-opts.path, ws-opts.headers.Host를 자주 사용합니다. 변환 과정에서 서버, 포트, 비밀번호만 남기면 노드 목록에는 표시되더라도 핸드셰이크가 실패할 수 있습니다.
형식 간 변환: 노드만 옮길지 전체 설정을 옮길지 먼저 결정하세요
Base64 또는 URI 목록을 Clash YAML로 변환하기
- 원본 백업. 구독 원문과 현재 정상 작동하는 설정을 저장하세요. 토큰이 포함된 구독 주소는 민감한 인증 정보이므로 스크린샷, 공개 로그, 문의 첨부 파일에 넣지 마세요.
- 출력 대상 확인. 도구에서 실제로 제공하는 Clash 또는 mihomo 대상을 선택하고, 노드 프로토콜이 해당 대상에서 지원되는지 확인하세요.
- 노드 복원 및 파싱. 바깥쪽이 Base64로 인코딩된 경우에만 디코딩하세요. 각 URI에서 프로토콜, 주소, 자격 증명, TLS 및 전송 매개변수를 따로 확인하세요.
- 출력 형태 결정. 기존 설정의 노드만 교체한다면 노드 목록이나 제공자 리소스를 생성하세요. 별도로 가져와야 한다면 프록시 그룹과 규칙이 포함된 기본 설정을 만드세요.
- 템플릿 변경 사항 확인. 변환 템플릿에 DNS, 규칙 제공자, TUN 필드가 추가될 수 있습니다. 항목별로 검토하고 새로 추가된 설정을 구독 원본 설정으로 착각하지 마세요.
클라이언트의 ‘링크에서 가져오기’ 기능이 모든 응답 형식을 지원하는 것은 아닙니다. 어떤 경로는 전체 YAML을 요구하고, 어떤 경로는 노드 URI를 가져올 수 있으며, 추가 변환 서비스를 호출하는 경우도 있습니다. 현재 클라이언트의 안내에 맞춰 가져오기 경로를 선택하세요. 링크 이름만 바꿔서는 응답 본문이 달라지지 않습니다.
Clash YAML을 URI 또는 Base64로 변환하기
proxies에서 실제 노드를 추출하세요. 기본 설정이proxy-providers만 참조한다면 해당 제공자 리소스를 가져와야 합니다. 제공자 URL을 노드 주소로 사용하면 안 됩니다.- 각 프로토콜의 URI 규격에 맞춰 연결 매개변수를 직렬화하세요. 대상 클라이언트가 지원하지 않는 필드는 명확히 기록하고 조용히 버리지 마세요.
- 한 줄에 URI 하나씩 넣으세요. 수신 측에서 Base64 구독을 요구하는 경우에만 목록 전체를 정해진 방식으로 인코딩하세요.
- 수신 측에서 다시 가져온 뒤 노드 수와 주요 필드를 확인하고 연결을 테스트하세요.
이런 역방향 변환은 대개 정보가 손실됩니다. proxy-groups, rules, dns, tun, 로컬 수신 포트는 노드 URI를 내보내도 함께 옮겨지지 않습니다. 노드 연결에 성공하더라도 트래픽 처리 방식은 원래 설정과 달라질 수 있으므로 수신 측에서 분기 정책을 별도로 구성해야 합니다.
변환 후 확인하기: 문법부터 실제 트래픽까지
‘가져오기 성공’은 특정 경로에서 파일을 받아들였다는 뜻일 뿐, 모든 필드가 유지되었거나 모든 연결이 정상이라는 뜻은 아닙니다. 먼저 구조 문제를 확인한 다음 네트워크 문제를 진단하도록 아래 순서대로 검증하는 것이 좋습니다.
1단계: 대상 코어로 설정 검사하기
mihomo 명령줄 코어가 설치되어 있다면 설정 파일이 있는 디렉터리에서 아래 검사를 실행할 수 있습니다. 이 명령은 설정을 읽고 테스트할 뿐, 프록시 서비스를 계속 실행하지는 않습니다. 설정이 상대 경로 리소스에 의존한다면 해당 파일도 준비하고, 검사 결과에서 리소스 로드 오류가 있는지 확인하세요.
mihomo -t -f ./config.yamlYAML 들여쓰기, 중복 노드 이름, 프록시 그룹 참조, 지원되지 않는 프로토콜 필드를 중점적으로 확인하세요. 문자열 비밀번호는 따옴표로 감싸는 것이 좋습니다. 그렇지 않으면 #이 주석으로 처리되거나 일부 값이 다른 YAML 형식으로 해석될 수 있습니다. 들여쓰기에 탭을 사용하지 마세요.
2단계: 노드 이름만 보지 말고 항목별로 대조하기
- 개수: 원본 목록과 변환 결과의 항목 수를 비교하세요. 필터링되거나 중복 제거된 항목에는 명확한 이유가 있어야 합니다.
- 연결:
server,port, 자격 증명, 암호화 방식, TLS 매개변수를 비교하세요. - 전송: WebSocket 경로와 Host, gRPC 서비스 이름 등 프로토콜 관련 옵션을 확인하세요.
- 참조: 프록시 그룹이 실제로 존재하는 노드를 가리키고 규칙이 존재하는 그룹을 가리키는지 확인하세요. 그룹 이름의 공백과 대소문자도 일치해야 합니다.
- 로컬 연결 경로: 이 예시에서 앱은 원격 노드의
443포트가 아니라 로컬의127.0.0.1:7890에 연결해야 합니다.
3단계: TCP, DNS, UDP를 따로 확인하기
먼저 노드 하나를 선택하고 프록시를 사용하도록 명시적으로 설정한 앱으로 HTTPS 페이지에 접속한 다음 연결 로그에서 아웃바운드와 오류를 확인하세요. 지연 시간 테스트가 통과했다는 것은 해당 시점에 테스트 요청이 완료되었다는 뜻일 뿐, 동영상이나 게임 또는 모든 사이트에 접속할 수 있다는 보장은 아닙니다. 도메인 이름 확인에 실패하면 DNS 설정을 확인하세요. TLS 핸드셰이크 오류가 발생하면 인증서 검증을 끄기보다 SNI, 시스템 시간, 인증서를 확인하세요.
HTTP 프록시 접속은 정상인데 게임이 계속 직접 연결된다면 트래픽을 프록시로 전달하는 방식에 문제가 있을 수 있습니다. 노드 형식을 변환해도 TUN이 자동으로 켜지거나 모든 앱의 트래픽이 자동으로 프록시를 통과하지는 않습니다. 모든 트래픽을 처리하거나 UDP를 전달해야 한다면 TUN, 라우팅, 클라이언트 권한을 별도로 확인하세요. 이는 실행 설정의 문제이지 Base64 인코딩 계층의 문제가 아닙니다.
자주 묻는 질문과 형식 선택
변환 서비스는 성공이라고 응답했는데 클라이언트에서 사용 가능한 노드가 없다고 표시되는 이유는 무엇인가요?
먼저 출력 본문에 실제로 proxies 목록이 있는지 확인하세요. 필터 규칙으로 목록이 비워지지 않았는지, 대상 코어가 프로토콜을 지원하는지, 프록시 그룹이 변환 전의 이전 이름을 참조하는지도 살펴봐야 합니다. HTTP 요청 성공이 변환 결과의 유효성을 보장하지는 않습니다. 응답에 서비스 오류 안내가 들어 있을 수도 있습니다.
설정을 Base64로 변환해도 트래픽 분기 규칙이 유지되나요?
텍스트는 어떤 것이든 인코딩하면 바이트를 그대로 보존할 수 있지만, 수신 측은 디코딩 후 내용이 무엇인지 알아야 합니다. 일반적인 ‘Base64 구독’은 인코딩된 전체 YAML이 아니라 노드 URI 목록을 가리킵니다. 전체 YAML을 인코딩해도 URI 목록만 인식하는 클라이언트가 그 안의 트래픽 분기 규칙을 이해하게 되는 것은 아닙니다.
변환 후에도 자동으로 업데이트되나요?
로컬에서 내보낸 파일은 내보낸 시점의 스냅샷이므로 자동으로 동기화되지 않습니다. 원격 변환 주소의 업데이트 여부는 매번 원본을 다시 가져오는지, 어떤 방식으로 캐시하는지, 클라이언트가 어떻게 업데이트하는지에 따라 달라집니다. proxy-providers로 노드를 업데이트하더라도 기본 설정의 프록시 그룹과 규칙은 기본 설정에서 관리됩니다.
구독 변환은 로컬에서 할까요, 온라인 서비스에서 할까요?
중간 단계를 줄이려면 구독 제공자가 직접 제공하는 대상 형식을 우선 사용하세요. 변환이 꼭 필요하다면 자격 증명 흐름을 제어하기 쉬운 로컬 도구를 고려할 수 있습니다. 온라인 서비스를 이용하면 구독 주소나 노드 매개변수를 해당 서비스에 제공하게 됩니다. 주소를 Base64로 인코딩해도 수신 측에서 복원할 수 있으므로 먼저 신뢰할 수 있는 서비스인지 확인하세요.
선택 기준은 두 가지로 정리할 수 있습니다. 노드, 프록시 그룹, 트래픽 분기 규칙을 함께 옮겨야 한다면 대상 코어가 지원하는 전체 YAML을 우선 사용하세요. 노드만 교환하면 된다면 수신 측이 지원하는 URI 또는 노드 목록을 사용하세요. 필드별 자세한 내용은 설정 참고 자료에서, 클라이언트 선택은 선택 가이드에서 확인할 수 있습니다.