Shadowrocket 노드 링크 형식 안내: ss://, vmess://, vless://, trojan://와 구독 링크의 차이

ss://, vmess://, vless://, trojan:// 링크의 필드와 인코딩을 살펴보고, 단일 노드 링크와 구독 주소의 가져오기 및 업데이트 방식을 비교합니다.

이 글의 핵심

사용 중인 서비스와 구독 정보가 있다면 먼저 받은 항목이 단일 노드 공유 링크인지, 업데이트 가능한 구독 주소인지 확인한 다음 가져오기 메뉴를 선택하세요. 이 글에서는 네 가지 링크의 필드와 인코딩, 자주 있는 오해를 설명하고 Home에서 가져온 뒤 확인하는 방법을 안내합니다. 노드 매개변수, Config 규칙, Global Routing의 역할도 구분합니다. 예시는 형식 확인용이며 연결에 사용할 수 없습니다.

링크의 시작 부분 확인: 연결 매개변수와 구독 주소는 다릅니다

Shadowrocket에서 단일 노드 공유 링크는 일반적으로 하나의 연결 항목을 설명합니다. 어떤 프로토콜을 사용하고, 어느 서버에 연결하며, 어떤 인증 정보를 쓰는지, TLS 또는 특정 전송 방식을 사용하는지 등이 포함됩니다. ss://, vmess://, vless://, trojan://은 이 글에서 다루는 네 가지 scheme입니다. 시작 부분이 비슷해 보여도 내부 필드를 서로 바꿔 쓸 수 있다는 뜻은 아닙니다.

구독 링크는 보통 HTTPS 주소입니다. Shadowrocket이 해당 주소에 요청을 보내고 서버가 반환하는 노드 목록을 읽어 항목을 만들거나 업데이트합니다. 링크 자체에 서버 주소와 포트가 표시되지 않을 수도 있으며, 이 정보는 응답 본문에 들어 있는 경우가 많습니다. 모든 HTTPS 주소가 구독 주소로 쓰이는 것은 아닙니다. 계정 관리, 로그인, 안내 페이지는 구독 인터페이스와 다릅니다.

4가지
이 글에서 확인하는 scheme: ss / vmess / vless / trojan
1개
단일 노드 링크는 보통 연결 항목 하나를 설명합니다
443
뒤에서 사용하는 예시 포트이며 모든 노드의 기본값은 아닙니다

구독 주소 하나가 여러 노드를 반환할 수도 있고 하나만 반환할 수도 있으므로, 가져온 뒤 항목 수만으로 유형을 판단할 수는 없습니다. 더 확실한 기준은 가져올 때 Subscribe 유형을 사용했는지, 구독 출처가 저장되었는지, 해당 출처에 다시 요청해 업데이트할 수 있는지입니다. 앱의 일회성 구매와 연결 서비스 이용권은 별개입니다. 앱과 기존 서비스의 연결 인증 정보는 각각 관리됩니다.

ss://: Shadowsocks 인증 정보와 인코딩 경계

Shadowsocks 공유 링크는 인코딩된 인증 정보, 서버 주소, 포트, 선택적 쿼리 매개변수와 메모로 구성되는 경우가 많습니다. 인증 정보에는 보통 암호화 방식과 비밀번호가 포함됩니다. 아래의 BASE64URL은 인코딩 작업을 나타내며, 그대로 붙여 넣어 가져올 수 있는 실제 내용이 아닙니다.

ss://BASE64URL(method:password)@server.example:8388#Office
인증 정보 예시: aes-128-gcm:demo-password
서버 예시: server.example
포트 예시: 8388

이전 공유 형식에는 더 긴 연결 정보를 통째로 인코딩하는 방식도 있으므로, 눈에 보이는 @가 있는지만으로 판단할 수 없습니다. 기존 서비스에서 제공한 원본 링크를 보관하고 가져오기 기능으로 해석한 뒤 Home의 항목 편집 화면에서 결과를 확인하세요. 인증 정보를 디코딩했을 때 내용이 눈에 띄게 잘려 있다면 누락된 비밀번호를 추측하지 말고 원문을 다시 복사하는 것이 좋습니다.

vmess://: 일반적인 페이로드는 Base64로 인코딩된 JSON

일반적인 VMess 공유 링크는 vmess://로 시작하고 뒤에 Base64로 인코딩된 JSON이 옵니다. 흔히 쓰이는 VLESS URI처럼 사용자 정보@호스트:포트가 그대로 표시되는 형식은 아닙니다. 아래는 디코딩된 필드의 예시이며, 실제 서비스와 무관한 예시 도메인과 UUID를 사용합니다.

{
  "v": "2",
  "ps": "Office",
  "add": "server.example",
  "port": "443",
  "id": "00000000-0000-4000-8000-000000000000",
  "aid": "0",
  "scy": "auto",
  "net": "ws",
  "type": "none",
  "host": "edge.example",
  "path": "/demo",
  "tls": "tls",
  "sni": "edge.example"
}
필드용도확인할 사항
add / port연결 주소와 포트연결 대상 네트워크 종점을 결정합니다
id / aid사용자 식별자와 이전 버전 호환 매개변수출처의 값을 유지하고 임의로 바꾸지 마세요
net / path전송 방식과 관련 경로ws 환경에서는 경로를 확인해야 합니다
host / sni전송 Host와 TLS 서버 이름역할이 다르며 연결 주소와 다를 수 있습니다
ps / v메모와 공유 형식 식별자v는 앱 버전 번호가 아닙니다

add, host, sni를 서로 바꿔 쓸 수 있는 세 가지 서버 주소로 보면 안 됩니다. add는 연결 대상 주소입니다. 이 예시의 WebSocket 환경에서 host는 요청 Host에, sni는 TLS 이름 협상에 사용됩니다. 실제 서비스에서는 세 값이 같을 수도, 다를 수도 있습니다. 가져온 뒤 주소와 UUID만 남고 전송 경로나 TLS 설정이 빠지면 항목을 저장할 수는 있어도 연결이 완료되지 않을 수 있습니다.

vless://와 trojan://: 비슷한 모양, 다른 인증 필드

일반적인 VLESS와 Trojan 공유 형식은 표준 URI와 비슷합니다. 인증 정보는 @ 앞에, 서버와 포트는 뒤에 오며 물음표 뒤에는 확장 매개변수, 해시 기호 뒤에는 메모가 붙습니다. 모양이 비슷하다고 해서 접두사만 바꿔 프로토콜을 변환할 수 있는 것은 아닙니다.

vless://[email protected]:443?encryption=none&security=tls&type=ws&host=edge.example&path=%2Fdemo&sni=edge.example#Office

trojan://[email protected]:443?security=tls&type=tcp&sni=edge.example#Office

필드 확인 방법: 인증 방식에 따라 각각 확인

VLESS 공유 링크
  • @ 앞에는 보통 UUID가 옵니다.
  • encryption=none은 TLS를 끈다는 뜻이 아닙니다.
  • security, type, flow 등의 매개변수는 출처의 값과 대조해야 합니다.
  • WebSocket 환경에서는 host와 path도 확인하세요.
Trojan 공유 링크
  • @ 앞에는 보통 비밀번호가 옵니다.
  • 일반적인 구성에서는 TLS를 사용하므로 서버 이름과 인증서를 확인해야 합니다.
  • 특수 문자가 포함된 비밀번호는 URI 인코딩을 올바르게 해야 합니다.
  • 전송 확장은 출처의 매개변수와 실제 지원 여부를 기준으로 확인하세요.

프로토콜, 인증 정보, 전송 방식, TLS 매개변수는 함께 맞춰야 합니다. scheme이나 포트만 바꿔 변환하려고 하지 마세요.

예시의 %2Fdemo를 디코딩하면 /demo가 됩니다. 퍼센트 인코딩은 예약 문자가 URI 구조를 바꾸지 않도록 사용합니다. 예를 들어 비밀번호에 포함된 #을 그대로 쓰면 메모의 시작으로 인식될 수 있습니다. 복사할 때 원래 인코딩을 유지하면 가져오기 기능이 대개 필드별로 처리합니다. 직접 여러 번 디코딩해 다시 붙여 넣으면 구분 관계가 깨질 수 있습니다.

포트 443은 서버가 선택할 수 있는 수신 포트 중 하나일 뿐입니다. 포트 번호로 프로토콜을 추정할 수 없으며, 모든 TLS 연결을 443으로 바꿔서도 안 됩니다. 인증서 확인 오류가 발생하면 기기 시간, SNI, 출처 매개변수를 먼저 확인하세요. 인증서 확인을 끄는 것은 일반적인 해결 방법이 아닙니다.

단일 노드와 구독: 가져오기 메뉴와 업데이트 동작을 각각 확인

단일 노드 링크를 가져오면 보통 로컬 연결 매개변수 사본이 만들어집니다. 이후 서버에서 비밀번호, 주소 또는 전송 매개변수를 바꾸더라도 이름이 같다는 이유만으로 기존 항목에 새 값이 자동 반영되지는 않습니다. 구독은 다시 요청할 수 있는 출처를 저장하므로 업데이트 시 목록을 새로 가져올 수 있습니다. 다만 매번 요청이 성공한다고 보장하지 않으며, 서비스 유효 기간이나 계정 상태를 대신 확인해 주지도 않습니다.

구독 주소 구조 예시:
https://example.com/sub?token=xxxx

명백한 가짜 값이며 “주소 + 쿼리 인증 정보” 구조만 보여 줍니다.
  1. 단일 노드 가져오기: 신뢰할 수 있는 출처에서 링크 전체를 복사한 뒤 Home으로 돌아가 앱의 클립보드 가져오기 기능을 사용하세요. 클립보드 접근 요청이 표시되면 이번 가져오기에 필요한 경우에만 허용하세요. 가져오기 메뉴가 나타나지 않으면 Home 오른쪽 상단의 추가 메뉴로 이동해 기존 매개변수에 따라 항목을 만드세요.
  2. 구독 가져오기: Home → 오른쪽 상단 +로 이동한 뒤 Type에서 Subscribe를 선택하세요. 본인의 구독 주소를 URL에 입력하고 메모를 추가한 다음 저장합니다. 계정 로그인 페이지를 URL에 입력하지 마세요.
  3. 결과 확인: 구독 그룹, 노드 유형, 항목 수가 기존 서비스 안내와 일치하는지 확인하세요. 메모 이름만 보지 말고 항목 편집 화면에서 주소, 포트, 전송 설정도 확인하세요.
  4. 이후 업데이트: Home의 구독 항목 메뉴에서 업데이트를 실행하세요. 자동 업데이트가 필요하면 Settings → Subscribe에서 업데이트 설정을 확인하세요. 앱을 열 때 업데이트하는 동작은 시스템이 계속 정기적으로 가져오는 것과 다릅니다. 단일 노드 항목이 구독으로 바뀌는 것도 아닙니다.
출처를 보존한 뒤 로컬 항목을 조정하세요

구독을 업데이트하면 구독에서 관리하는 노드 정보가 바뀌거나 목록 순서와 이름이 달라질 수 있습니다. 구독 노드를 로컬에서 수정하기 전에는 수정 이유를 기록하고 원래 매개변수를 보관하세요. 중요한 사용자 지정 항목은 별도로 관리하여 업데이트를 수동 설정의 손실로 오해하지 않도록 합니다.

HTTPS는 전송에 해당 보호 방식이 사용된다는 뜻일 뿐, 반환 내용이 반드시 노드 목록이라는 뜻은 아닙니다. 업데이트 후 로그인 페이지, 오류 페이지 또는 호환되지 않는 형식의 텍스트가 표시되면 원래 구독 주소, 유효 기간, 반환 내용을 확인하세요. 구독 token은 접근 인증 정보와 같으므로 문제 해결을 위해 전체 URL을 공개 채팅이나 스크린샷에 올리지 마세요.

가져온 다음에는 노드를 확인하고 Global Routing과 Config를 점검

“링크를 해석할 수 있음”, “항목을 저장할 수 있음”, “연결을 설정할 수 있음”, “대상 요청에 올바른 정책을 적용함”은 서로 다른 결과입니다. 노드 공유 링크는 주로 연결 매개변수를 제공합니다. 가져오기에 성공했다고 해서 개인의 필요에 맞는 Config가 자동으로 만들어지는 것은 아닙니다. Home에서는 연결 항목과 연결 상태를 관리하고, Config에서는 규칙 구성을 관리하며, Settings에서는 앱 동작을 조정합니다.

Global Routing → Config

권장

규칙 구성을 확인한 경우 현재 Config의 규칙에 따라 요청 정책을 결정합니다. 어떤 요청이 프록시를 사용하고 직접 연결되는지는 규칙의 내용과 순서에 따라 달라집니다.

적합한 경우: 노드 확인을 마쳤고 명확한 분기 규칙을 사용 중인 경우

Global Routing → Proxy

분기 규칙 때문에 대상 요청이 프록시를 사용하지 않는지 확인할 때 프록시 방식으로 점검합니다. 문제 범위를 좁히는 데 사용하는 기능이며 누락된 UUID, 비밀번호, SNI, 전송 경로를 보완하지는 않습니다.

적합한 경우: 노드 연결과 규칙의 영향을 잠시 점검하는 경우

Global Routing → Direct

대상에 직접 연결해 현재 네트워크에서의 접근 결과를 관찰할 때 사용합니다. 이 상태의 결과만으로 선택한 프록시 노드가 정상이라고 입증할 수는 없습니다.

적합한 경우: 현재 네트워크와 프록시 경로의 차이를 비교하는 경우

Global Routing에는 Scene도 포함됩니다. 설정된 장면 조건에 따라 해당 정책을 적용하므로 고정된 Proxy 또는 Config로 간주하면 안 됩니다. Settings → On Demand는 요청 시 연결 동작을 제어하는 설정이며, 노드 프로토콜이나 구독 업데이트 스위치가 아닙니다. 점검 중에는 연결을 시작하는 조건과 테스트 대상을 일치시키고, 네트워크 전환과 자동 실행이 테스트 조건을 동시에 바꾸지 않도록 하세요.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,DIRECT

위 내용은 규칙 문법의 예시이며 완전한 구성이 아닙니다. DOMAIN-SUFFIX는 도메인 접미사를 일치시키고, IP-CIDR은 주소 대역을 일치시킵니다. GEOIP는 IP 지리 데이터베이스에 따라 분류하고, FINAL은 앞선 규칙과 일치하지 않은 요청을 처리합니다. 규칙 순서가 결과에 영향을 줍니다. 노드 매개변수가 올바르더라도 대상 요청이 DIRECT와 일치하면 해당 프록시 경로를 사용하지 않습니다. 동일한 링크를 반복해서 다시 가져오기보다 요청 기록의 일치 규칙과 최종 정책을 확인하는 편이 효과적입니다.

자주 묻는 질문: 해석, 인증, 전송, 업데이트를 나눠 점검

ss://를 복사했는데 노드가 가져와지지 않는 이유는 무엇인가요?

접두사, 인코딩 문자열, 서버, 포트가 모두 포함되었는지 확인하세요. 링크 바깥의 따옴표나 설명은 제거하되 링크 안의 문자는 바꾸지 마세요. 채팅 앱의 서식 처리 과정에서 공백, 줄바꿈, 생략된 내용이 삽입될 수 있습니다. 원래 출처에서 전체 텍스트를 다시 복사한 다음 Home에서 가져오세요. 그래도 안 되면 출처의 공유 형식과 확장 기능이 지원되는지 확인하세요.

VMess 가져오기는 성공했지만 계속 연결에 실패합니다. UUID가 잘못된 건가요?

반드시 그렇지는 않습니다. 주소와 포트, UUID, 전송 방식, WebSocket Host와 Path, TLS와 SNI, 기기의 날짜와 시간을 차례로 확인하세요. 항목이 저장된 것은 입력이 받아들여졌다는 뜻일 뿐 서버 인증과 전송 핸드셰이크가 성공했다는 뜻은 아닙니다. 확인된 차이 한 가지만 수정하여 여러 항목을 동시에 바꾼 뒤 원인을 파악하기 어려워지는 상황을 피하세요.

VLESS의 encryption=none은 TLS를 사용하지 않는다는 뜻인가요?

아닙니다. 두 매개변수는 서로 다른 설정을 설명합니다. 같은 링크의 security를 확인하고 가져온 항목에서 TLS 관련 옵션을 점검하세요. encryption=none만 보고 TLS를 끄지 마세요. 전송 및 보안 매개변수는 본인의 서비스 설정과 일치해야 합니다.

구독 업데이트는 성공했는데 선택한 노드를 사용할 수 없는 이유는 무엇인가요?

업데이트 성공은 구독 내용을 가져와 처리했다는 뜻이지, 목록의 모든 노드에 연결할 수 있다는 뜻은 아닙니다. 먼저 Home에서 현재 선택된 항목과 연결 상태를 확인한 다음 기존 서비스의 유효 기간, 노드 매개변수, Global Routing을 살펴보세요. 업데이트 자체가 실패했다면 URL, 접근 인증 정보, 네트워크 연결, 응답 형식을 먼저 점검하세요. 두 상황을 혼동하지 마세요.

링크 스크린샷을 다른 사람에게 보내 확인을 부탁해도 되나요?

먼저 비밀번호, UUID, 구독 token, 전체 QR 코드를 가리세요. QR 코드는 원래 링크를 다른 형태로 표시한 것일 뿐 인증 정보를 숨기지 않습니다. 점검을 요청할 때는 프로토콜 이름, 민감 정보를 지운 매개변수 이름, 오류 메시지, 이미 시도한 단계를 공유할 수 있습니다. 실제 인증 정보를 확인해야 한다면 본인의 서비스 제공업체가 운영하는 신뢰할 수 있는 경로를 이용하세요.

최종 확인 순서: 링크 유형 구분 → 원문 전체 보존 → 해당하는 가져오기 메뉴 선택 → 인증 및 전송 필드 확인 → 연결 테스트 → 규칙과 업데이트 동작 점검. 이 글의 네 가지 scheme은 Shadowrocket이 지원하는 기능 전체 목록이 아니며, 다른 프로토콜도 같은 URI 필드를 사용한다고 추정할 수 없습니다. 기존 매개변수와 실제 지원 여부를 각각 확인해야 합니다.

App Store 정품 확인