Shadowrocket 공유 링크 형식과 구독 링크 차이: ss://, vmess://, vless://, trojan://

1. 단일 공유 링크, 구독 주소, 규칙 구성 구분하기

Shadowrocket의 서버 설정, 구독 소스, 라우팅 규칙은 서로 다른 개념입니다. 공유 링크에는 서버 하나의 접속 정보가 담기고, 구독 주소는 다시 요청할 수 있는 원격 콘텐츠를 가리키며, 규칙 구성은 연결 요청을 라우팅하는 방식을 정합니다. 모두 텍스트나 URL 형태로 표시될 수 있지만 서로 대체할 수는 없습니다.

https:// 주소라고 해서 반드시 서버 구독인 것은 아닙니다. 로그인 페이지, 도움말 페이지 또는 규칙 구성을 가리킬 수도 있습니다. 주소가 길어 보이는지가 아니라 기존 서비스에서 안내한 용도와 응답 내용을 기준으로 판단하세요. 서버 목록 구독에 DNS나 라우팅 규칙 설정이 포함된다고 보장할 수도 없습니다. 가져온 뒤 현재 Global Routing을 확인하세요.

2. ss://와 vmess://: Base64로 감싼 내용은 서로 다릅니다

ss://: 암호화 방식과 비밀번호, 주소와 포트 확인하기

ss://는 Shadowsocks 공유 링크입니다. 일반적인 SIP002 형식에서는 ‘암호화 방식:비밀번호’를 Base64로 인코딩한 userinfo에 넣고, 서버 주소와 포트는 바깥에 둡니다. 이전 형식은 연결 정보 전체를 인코딩하기도 합니다. 따라서 모든 ss:// 링크를 같은 위치에서 기계적으로 잘라내면 안 됩니다.

디코딩한 userinfo 예시:
aes-256-gcm:demo-password

해당 서버 정보 예시:
Server: example.com
Port: 8388
Method: aes-256-gcm
Password: demo-password

여기서 8388은 설명용 포트일 뿐, Shadowsocks에서 반드시 사용하는 포트가 아닙니다. 실제 포트는 기존 서비스 정보와 일치해야 합니다. 링크에 plugin 쿼리 매개변수와 # 뒤의 메모가 포함될 수도 있습니다. 메모는 항목을 구분하기 위한 것으로 주소를 대신하지 않습니다. 서비스에 추가 플러그인 매개변수가 필요하다면 주소, 비밀번호, 포트만으로는 연결되지 않을 수 있습니다.

vmess://: 흔히 Base64로 인코딩된 JSON 구조

일반적인 vmess:// 공유 형식은 JSON 객체를 인코딩해 접두사 뒤에 붙입니다. 아래는 디코딩한 내용을 읽는 예시이며, 가져오기 입력란에 그대로 붙여 넣을 수 있는 완전한 링크가 아닙니다. 공유 형식에는 변형이 있을 수 있으므로 가져온 뒤 표시되는 필드를 기준으로 확인하세요.

{
  "v": "2",
  "ps": "Demo VMess",
  "add": "example.com",
  "port": "443",
  "id": "00000000-0000-4000-8000-000000000001",
  "aid": "0",
  "scy": "auto",
  "net": "ws",
  "type": "none",
  "host": "example.com",
  "path": "/demo",
  "tls": "tls",
  "sni": "example.com"
}

• add와 port는 서버 주소와 포트이고, id는 인증에 사용하는 UUID입니다.
• net이 ws이면 WebSocket 전송을 사용한다는 뜻이며, path와 host는 해당 전송의 매개변수입니다.
• tls와 sni는 TLS 연결에 영향을 줍니다. 포트가 443이라고 해서 TLS 설정이 모두 갖춰졌다고 단정할 수 없습니다.
• v는 이 유형의 공유 JSON에서 형식을 나타내는 필드이지 Shadowrocket 버전 번호가 아닙니다. ps는 일반적으로 표시용 메모입니다.

3. vless://와 trojan://: URI에서 생략하면 안 되는 필드

vless://와 trojan://은 비교적 읽기 쉬운 URI 구조를 사용하는 경우가 많습니다. 접두사 다음에는 인증 정보가, @ 뒤에는 서버 주소와 포트가, ? 뒤에는 쿼리 매개변수가, # 뒤에는 메모가 옵니다. 읽기 쉽더라도 민감한 정보일 수 있으므로 인증 부분은 비밀번호처럼 다루세요.

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

trojan://[email protected]:443?security=tls&sni=example.com#Demo-Trojan

VLESS 예시의 encryption=none은 프로토콜 관련 매개변수입니다. 이 값만으로 연결 전체에 TLS가 적용되지 않는다고 판단할 수는 없습니다. TLS 사용 여부는 security와 가져온 뒤의 실제 설정을 확인해야 합니다. 마찬가지로 443은 포트 번호만 알려줄 뿐, 인증서 검증, SNI 또는 WebSocket 경로가 올바르다는 뜻은 아닙니다.

URL의 특수 문자는 퍼센트 인코딩이 필요할 수 있습니다. 예시의 %2Fdemo를 디코딩하면 /demo가 됩니다. 직접 처리할 때는 여러 번 디코딩한 뒤 링크에 다시 조합하지 마세요. 비밀번호에 포함된 @나 #을 구조를 나누는 문자로 잘못 취급해서도 안 됩니다. IPv6 주소가 URI의 호스트 위치에 들어가는 경우에는 주소의 콜론과 포트 구분자가 혼동되지 않도록 대괄호로 감싸는 것이 일반적입니다.

4. 구독 주소: 원격 소스를 유지하고 목록을 업데이트

서버 구독은 보통 HTTPS 주소이며, 아래 예시는 명백한 가짜 주소입니다. 가져올 때 Shadowrocket은 해당 주소에 요청을 보내 응답을 해석한 뒤 선택할 수 있는 서버 항목을 만듭니다. 응답은 여러 공유 링크가 담긴 텍스트일 수도 있고 전체가 인코딩되어 있을 수도 있습니다. 구독 URL만 보고 내부에서 Shadowsocks, VMess, VLESS, Trojan 중 어떤 프로토콜을 사용하는지 알 수는 없습니다.

https://example.com/sub?token=xxxx

구독을 업데이트하면 원격 소스를 다시 가져오므로 항목 수, 이름, 주소, 자격 증명이 바뀔 수 있습니다. 업데이트에 성공해도 현재 선택한 서버에 연결할 수 있다는 뜻은 아니며, 트래픽 규칙이 올바르다는 뜻도 아닙니다. 업데이트 전에 현재 사용하는 항목을 기록해 두세요. 구독에 포함된 항목을 직접 수정해도 계속 유지된다고 가정하지 마세요. 다음 업데이트에서 관련 필드가 다시 생성될 수 있습니다.

• 응답이 로그인 페이지라면 HTTP 요청에 응답이 있더라도 유효한 서버 목록으로 처리할 수 없습니다.
• 소스에서 token을 폐기한 경우 기존 주소를 반복해서 붙여 넣어도 접근 권한이 복구되지 않습니다. 현재 사용하는 서비스에서 유효한 주소를 확인하세요.
• 링크에 &가 포함되어 있다면 실제 주소를 복사했는지 확인하세요. 웹페이지 소스에서 해당 문자를 나타내는 엔티티 텍스트를 복사한 것은 아닌지 살펴보세요.
• 전체 구독 URL은 접근 자격 증명 역할을 하는 경우가 많습니다. 스크린샷을 공유할 때는 도메인뿐 아니라 경로와 쿼리 매개변수도 가리세요.

5. 가져온 뒤 Home, Config, Settings에서 확인할 항목

Home에서는 서버를 확인하고 선택하므로 가져오기 결과를 점검하는 데서 출발합니다. Config에서는 규칙 구성을 관리하고, Settings에는 앱 설정이 있습니다. 공유 링크에 type=ws가 있다고 해서 Config의 라우팅 규칙으로 간주하지 마세요. 프로토콜 전송은 서버에 연결하는 방식을 정하고, 규칙은 각 요청에 적용할 정책을 정합니다. 두 항목은 서로 다른 계층입니다.

1. 먼저 Home에서 새로 추가한 항목의 편집 화면을 열어 Type이 원본 접두사와 일치하는지 확인한 다음 서버 주소, 포트, 인증 정보, TLS 및 전송 매개변수를 점검합니다.
2. 구독을 가져왔다면 해당 항목이 이전에 추가한 이름만 같은 독립 항목이 아니라 예상한 소스에 속하는지 확인합니다.
3. Global Routing을 확인합니다. 일상적으로 규칙에 따라 사용할 때는 Config가 선택되어 있는지, Config 페이지에서 예상한 구성이 선택되어 있는지 점검하세요.
4. 사용 권한이 있는 서버를 선택하고 연결을 켠 뒤 시스템 VPN 구성 권한을 허용하고 실제 요청을 테스트합니다.
5. 자동 재연결 동작을 확인하려면 Settings → On Demand를 살펴보세요. 이 설정은 구독 업데이트 스위치가 아니며 누락된 서버 매개변수를 채워 주지도 않습니다.

규칙 구성에서 DOMAIN-SUFFIX는 도메인 접미사를 일치시키고, GEOIP와 IP-CIDR은 해당 IP 조건에 사용됩니다. FINAL은 앞선 규칙에 일치하지 않을 때 기본 처리를 담당합니다. 이는 네 가지 공유 링크의 쿼리 매개변수가 아니며 서버를 가져온다고 사용 목적에 맞춰 자동으로 생성되지도 않습니다. 규칙 구성에 관해 더 알아보려면 사용 안내 또는 문제 해결 매뉴얼을 확인하세요.

6. 가져오기 및 업데이트 관련 자주 묻는 질문

7. 최종 확인: 형식, 소스 유효성, 실제 요청 결과

가져오기를 마친 뒤 ‘텍스트를 인식했는지’, ‘서버 설정이 올바른지’, ‘요청이 예상한 경로로 실제 처리되는지’를 각각 확인해야 합니다. 어느 하나도 다른 확인을 대신할 수 없습니다. 가져오기 성공은 로컬 기록이 만들어졌다는 뜻일 뿐입니다. 새로고침 성공은 원격 콘텐츠를 가져왔다는 뜻일 뿐이며, 실제 접속 결과는 서버 상태, 현재 네트워크, DNS, 라우팅 설정에 따라 달라집니다.

• 링크 유형: 단일 서버 공유 링크, 새로고침할 수 있는 구독, 규칙 구성 주소 중 무엇인지 확인합니다.
• 인증 및 전송: 프로토콜, 주소, 포트, 비밀번호 또는 UUID와 TLS, SNI, Host, path 등 필요한 항목을 확인합니다.
• 소스 및 업데이트: 구독 소스가 유효한지, 독립 항목을 자동 업데이트되는 구독 항목으로 잘못 알고 있지 않은지 확인합니다.
• 라우팅 및 테스트: Global Routing이 현재 구성과 일치하는지 확인하고 실제 웹 요청으로 점검합니다. 지연 시간만 확인해서는 안 됩니다.
• 자격 증명 보호: 전체 공유 링크, QR 코드, token이 포함된 구독 주소를 공개하지 마세요. 유출되었다면 현재 사용하는 서비스에서 해당 자격 증명을 조치하세요.