2026-09-27 · 프로토콜 · 약 10분

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

ss://, vmess://, vless://, trojan:// 링크의 구조와 인코딩을 살펴보고, 단일 연결 링크와 구독 링크의 가져오기·업데이트 차이 및 인식 오류 점검 방법을 안내합니다.

이 글의 핵심

Shadowrocket에서 단일 공유 링크는 하나의 연결 설정을 담고, 구독 링크는 업데이트 가능한 원격 목록을 가리킵니다. 서비스 제공업체에서 연결 정보를 받은 뒤 가져오거나 인식 문제를 해결하려는 사용자를 위해, 링크 접두사로 유형을 구분하고 인코딩, 주소, 인증 정보, 전송 설정을 확인하는 방법을 정리했습니다. 마지막으로 가져오기 성공과 연결 성공을 각각 확인하세요.

1. 단일 공유 링크와 구독 주소 구분하기

ss://, vmess://, vless://, trojan://은 단일 연결 정보에 흔히 사용되는 프로토콜 접두사입니다. 서버 주소와 포트, 인증 정보, 전송 설정 등이 포함될 수 있습니다. 텍스트를 QR 코드로 바꾸는 것은 전달 방식만 바꾸는 것이며, 단일 링크가 구독으로 바뀌는 것은 아닙니다.

구독은 보통 https:// 주소로 제공됩니다. Shadowrocket이 해당 주소에 요청을 보내 서버에서 목록을 받아 항목을 해석합니다. 목록은 업데이트될 수 있지만 주소 자체는 그대로일 수 있습니다. 주소가 HTTPS로 시작한다고 해서 반드시 구독 링크인 것은 아닙니다. 일반 웹페이지, 로그인 페이지, 오류 페이지는 연결 목록이 아닙니다.

4가지
이 글에서 다루는 접두사: ss / vmess / vless / trojan
1개
일반적인 단일 공유 링크에는 하나의 연결 설정이 담깁니다
443
뒤에 나오는 TLS 예시 포트이며 모든 서비스에 공통으로 적용되는 포트는 아닙니다

2. ss://: Base64가 적용된 범위부터 확인하기

Shadowsocks에서 흔히 사용하는 SIP002 공유 형식은 ss:// 뒤에 Base64로 인코딩한 method:password를 놓고, @로 서버 주소와 포트를 연결합니다. 아래 예시의 인코딩 문자열 YWVzLTEyOC1nY206dGVzdA를 디코딩하면 aes-128-gcm:test가 됩니다.

ss://[email protected]:8388#Demo%20SS

이전 방식의 링크는 method:password@host:port 전체를 인코딩하기도 합니다. 따라서 Base64가 보인다고 해서 @ 앞부분만 디코딩하면 안 됩니다. 일부 링크에는 plugin 쿼리 매개변수가 포함되며 플러그인 이름과 옵션도 연결 정보의 일부입니다. 복사할 때 물음표 뒤의 내용을 누락하지 마세요.

Base64와 URL 퍼센트 인코딩은 서로 다른 단계의 인코딩입니다. Base64에는 +, /, 끝부분의 =가 포함될 수 있고, URL-safe Base64는 사용하는 문자가 다릅니다. 모든 +를 공백으로 바꾸거나 모든 링크에 같은 수의 등호를 덧붙이지 마세요. 원본 전체를 받은 뒤 가져오기 기능에서 형식에 맞게 처리하도록 하세요.

3. vmess://: 인코딩된 내용은 대개 JSON

일반적인 VMess 공유 형식은 vmess:// 뒤에 Base64로 인코딩한 JSON을 붙입니다. 앞 절의 형식과 달리 디코딩 결과는 보통 '비밀번호와 주소' 한 줄이 아니라 필드 이름이 있는 데이터 묶음입니다. 아래는 형식 설명을 위한 디코딩 결과이며 공유 링크로 바로 붙여넣을 수 있는 텍스트가 아닙니다.

{
  "v": "2",
  "ps": "Demo VMess",
  "add": "example.com",
  "port": "443",
  "id": "11111111-1111-4111-8111-111111111111",
  "aid": "0",
  "scy": "auto",
  "net": "ws",
  "type": "none",
  "host": "example.com",
  "path": "/demo",
  "tls": "tls",
  "sni": "example.com"
}
필드확인할 내용
add / port실제 연결에 사용할 서버와 포트입니다. 포트는 유효한 숫자여야 하며 전각 콜론이 섞여 있으면 안 됩니다.
id / aidUUID와 Alter ID입니다. 서버에서 제공한 정보를 입력하고 UUID를 일반 비밀번호처럼 임의로 바꾸지 마세요.
net / host / path전송 방식과 추가 매개변수입니다. WebSocket 경로의 슬래시와 대소문자를 그대로 유지하세요.
tls / sniTLS 설정과 서버 이름입니다. 포트가 443이라는 이유만으로 모든 값을 추정하면 안 됩니다.

예시의 v는 공유 형식의 필드이며 Shadowrocket 앱 버전이 아닙니다. 생성 도구에 따라 출력되는 필드 조합이 다를 수 있으므로 누락된 필드에 같은 기본값을 적용할 수 있다고 가정하지 마세요. 가져온 뒤 항목 상세 정보에서 원본과 비교해 UUID, 전송 방식, TLS, 경로를 확인하세요. 메모와 주소가 맞더라도 다른 설정까지 올바르다는 뜻은 아닙니다.

4. vless://와 trojan://: 비슷한 구조, 다른 인증 정보

이 두 가지 공유 형식은 모두 @ 뒤에서 주소와 포트를 확인할 수 있으며, 물음표 뒤의 쿼리 매개변수로 보안 계층이나 전송 설정을 지정합니다. 겉모양이 비슷해도 같은 프로토콜은 아닙니다. 특히 VLESS의 UUID와 Trojan의 비밀번호를 서로 바꿔 사용할 수 없습니다.

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

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

이 예시는 일반적인 형식만 다루며 모든 전송 조합을 포괄하는 템플릿은 아닙니다. 원본 링크에 추가 매개변수가 있으면 그대로 보관하고 현재 클라이언트가 해당 옵션으로 변환할 수 있는지 확인하세요. 가져오기 오류가 없다는 이유만으로 이해하지 못한 매개변수를 삭제하지 마세요. SNI, 시스템 시간, 인증서 설정을 확인하는 대신 인증서 검증을 끄는 것도 피하세요.

5. Home에서 가져온 뒤 목록과 규칙을 따로 관리하기

단일 링크와 구독은 관리 대상이 다릅니다. 단일 링크는 보통 독립 항목으로 추가되지만, 구독은 원격 목록과의 연결을 유지합니다. 구독을 업데이트하면 항목이 추가·삭제되거나 다시 생성될 수 있으므로 구독에 포함된 항목의 로컬 수정 사항이 서버 설정으로 영구 저장된다고 생각하면 안 됩니다.

  1. 서비스 제공업체에서 원본 전체를 받으세요. 먼저 단일 프로토콜 링크인지, QR 코드인지, 구독 주소인지 확인하고 안내 문구, 따옴표, 채팅 메시지의 생략 부호는 복사하지 마세요.
  2. 단일 링크는 클라이언트의 클립보드 가져오기 기능으로, QR 코드는 스캔 기능으로 가져오세요. 가져온 뒤 Home으로 돌아가 새 항목을 확인합니다.
  3. 구독 주소는 Home → + → Type → Subscribe에서 추가하고 전체 URL과 식별하기 쉬운 메모를 입력하세요. 플랫폼에 따라 메뉴 위치가 다를 수 있으므로 같은 이름의 구독 유형을 선택하면 됩니다.
  4. 구독을 업데이트한 뒤 항목 수와 오류 메시지를 확인하세요. 예시 주소 https://example.com/sub?token=xxxx는 URL 형식을 보여 주기 위한 것으로 실제 목록을 제공하지 않습니다.
  5. 항목 상세 정보에서 설정을 확인한 다음 사용할 항목을 선택하고 연결을 켜세요. 규칙 설정은 Config에서 별도로 관리합니다. 일반 연결 목록을 완전한 규칙 설정으로 오해하지 마세요.

연결을 테스트할 때는 Global Routing도 확인해야 합니다. 선택한 항목을 통해 요청을 보낼지에 영향을 주지만 잘못된 공유 링크의 설정을 바로잡아 주지는 않습니다. 아래는 Shadowrocket의 라우팅 모드를 비교한 내용이며, 권장 표시는 일상적으로 규칙을 설정해 사용하는 경우를 기준으로 합니다.

Config

권장

현재 설정된 규칙에 따라 트래픽 경로를 결정합니다. PROXY 규칙이 적용됐는지는 요청 기록에서 실제 매칭 결과를 확인하세요.

적합한 경우: 규칙을 설정해 일상적인 트래픽 분배를 확인하려는 사용자

Proxy

클라이언트가 처리하는 트래픽을 프록시 경로로 보냅니다. 규칙이 매칭되지 않아 생기는 영향을 임시로 배제할 때 유용합니다.

적합한 경우: 가져온 항목의 연결 가능 여부만 따로 확인하려는 사용자

Direct

직접 연결 경로를 사용합니다. 이 상태에서 웹페이지가 열린다고 해서 가져온 항목의 프록시 연결까지 사용할 수 있다는 뜻은 아닙니다.

적합한 경우: 현재 네트워크의 직접 연결 상태와 비교하려는 사용자

정리: 한 번에 한 단계씩 확인하기

먼저 항목 설정이 완전한지 확인한 뒤 Proxy를 임시로 사용해 연결을 테스트하고, 마지막으로 Config로 돌아가 규칙이 매칭되는지 확인하세요. 이렇게 하면 파싱 오류, 연결 오류, 트래픽 분배 결과를 구분할 수 있어 여러 설정을 동시에 바꿔 원인을 찾기 어려워지는 상황을 피할 수 있습니다.

6. 인식 오류는 텍스트, 인코딩, 응답 순서로 확인하기

'링크를 인식할 수 없음'과 '연결 시간 초과'는 서로 다른 단계에서 발생합니다. 전자는 텍스트나 구독 내용을 파싱할 때, 후자는 보통 설정을 가져온 뒤 연결을 시작했을 때 발생합니다. 먼저 오류가 어느 단계에서 발생했는지 기록하고, 자료를 다시 복사할지 네트워크와 서버 설정을 확인할지 결정하세요.

링크를 복사했는데 가져올 항목이 표시되지 않는 이유는 무엇인가요?

원본을 로컬 텍스트 편집기에 붙여넣고 전체 프로토콜 접두사로 시작하는지, 끝에 채팅 문장부호가 붙지 않았는지, 본문이 줄바꿈이나 공백 때문에 잘리지 않았는지 확인하세요. QR 코드 스크린샷만 있다면 이미지 파일명을 복사하지 말고 QR 코드를 스캔하세요.

vmess://를 디코딩했더니 글자가 깨져 보입니다. 어디를 수정해야 하나요?

먼저 Base64 문자열 전체를 복사했는지 확인하고 표준 Base64와 URL-safe Base64를 구분하세요. 문자열 전체를 반복해서 URL 디코딩하지 마세요. 일반적인 JSON 형식은 디코딩 후 add, port, id 등의 필드가 보여야 합니다. 내용이 불완전하면 UUID를 추측해 채우지 말고 원본 링크를 다시 받으세요.

구독 주소가 브라우저에서 열리는데 업데이트는 왜 실패하나요?

브라우저에서 로그인 페이지, 인증 페이지, 오류 페이지가 열릴 수 있으며 목록이 반환됐다는 뜻은 아닙니다. 쿼리 매개변수가 모두 유지됐는지 확인하세요. 응답에 401 또는 403이 표시되면 서비스 제공업체에 접근 인증 정보와 권한을 확인하고, 404가 표시되면 경로가 유효한지 확인하세요. 웹페이지 본문을 연결 목록으로 붙여넣지 마세요.

가져오기는 성공했는데 연결에 실패했습니다. 인코딩 문제인가요?

먼저 서버 주소, 포트, 비밀번호 또는 UUID를 확인한 뒤 TLS의 SNI, WebSocket의 Host와 경로를 점검하세요. 인증서 오류가 표시되면 시스템 시간과 인증서 이름을 확인하고, 시간 초과가 발생하면 네트워크 연결 가능 여부와 서비스 상태를 확인하세요. 인코딩이 파싱되더라도 서버가 해당 설정을 받아들인다는 뜻은 아닙니다.

구독을 업데이트한 뒤 수동으로 수정한 메모나 설정이 바뀌는 이유는 무엇인가요?

업데이트 과정에서 서버 목록을 기준으로 항목이 다시 생성될 수 있습니다. 먼저 서비스 제공업체가 안내한 최신 설정과 비교해 원격 목록의 변경인지 확인하세요. 로컬 수정 사항을 유지해야 한다면 독립 항목과 구독 항목을 구분하고 여러 복사본 중 오래된 정보를 잘못 선택하지 않도록 주의하세요.

점검을 마친 뒤 문제를 알릴 때는 프로토콜 이름, 실패 단계, 민감 정보를 가린 오류 내용만 제공하세요. 서버 주소, UUID, 비밀번호, 구독 token, QR 코드는 접근 권한과 연결될 수 있습니다. 구조를 보여 줘야 한다면 이 글처럼 필드 이름은 유지하고 실제 값만 바꿔서 공유하세요. 전체 정보는 필요한 경우에만 안전한 채널로 전달하세요.

Shadowrocket 다운로드