서비스 제공업체의 설정과 구독 링크를 보유하고 있으며, Shadowrocket에서 링크를 확인하고 가져오려는 사용자를 위한 안내입니다. 먼저 단일 연결 정보와 구독 주소를 구분한 다음 인코딩, 인증, 전송 필드를 확인하고, 가져오기 실패·구독 업데이트 실패·연결 실패를 각각 살펴봅니다. 글에 나오는 도메인, 비밀번호, UUID, token은 모두 예시용 가상 값이며 실제 연결에 사용할 수 없습니다.
1. 먼저 구분하기: 공유 링크는 연결 정보, 구독 링크는 업데이트 경로
Shadowrocket은 공유 링크의 매개변수를 연결 항목으로 변환할 수 있습니다. ss://, vmess://, vless://, trojan://으로 시작하는 텍스트에는 보통 서버의 프로토콜, 주소, 포트, 인증 정보가 담겨 있습니다. 형식에 따라 TLS, 전송 방식, 메모도 포함될 수 있습니다. 브라우저에서 여는 일반 웹 주소가 아닙니다.
구독 링크는 보통 HTTPS 주소입니다. 클라이언트가 해당 주소에 요청을 보내고, 응답에서 지원되는 연결 항목을 가져와 구독에 추가합니다. 구독 링크는 연결 정보를 주소에 모두 담는 대신 목록을 반복해서 가져올 수 있는 경로를 제공합니다. https://로 시작한다고 해서 구독 링크라고 단정할 수는 없습니다. 로그인 페이지, 오류 페이지 또는 일반 안내 페이지일 수도 있습니다.
| 비교 항목 | 단일 공유 링크 | 구독 링크 |
|---|---|---|
| 주요 내용 | 연결 항목 하나의 매개변수 | 연결 목록을 가져오는 원격 주소 |
| 가져오기 과정 | 주로 텍스트를 로컬에서 해석 | 주소에 요청을 보내고 응답을 해석 |
| 이후 변경 사항 | 원본 공유 텍스트는 자동으로 바뀌지 않음 | 업데이트하면 원격 목록의 변경 사항을 가져올 수 있음 |
| 민감 정보 | 비밀번호, UUID, 서버 정보 | 주소의 token 및 응답으로 받은 설정 |
단일 공유 링크가 완전한 .conf 설정 파일을 의미하는 것도 아닙니다. 서버 하나를 가져와도 Config의 [Rule], [Host] 등이 함께 바뀌지는 않습니다. 서버 설정은 연결할 대상을 정하고, 규칙은 요청별 처리 방식을 정하므로 각각 확인해야 합니다.
2. ss://: Shadowsocks 인증 정보의 인코딩 확인
ss://는 Shadowsocks 공유 링크에 흔히 사용되는 접두사입니다. 일반적인 SIP002 형식에서는 암호화 방식과 비밀번호를 method:password로 묶고 Base64URL로 인코딩해 @ 앞에 둡니다. 서버 주소와 포트는 그대로 확인할 수 있습니다. 아래 인증 부분을 디코딩하면 aes-128-gcm:password가 나오며, 비밀번호는 예시용입니다.
ss://[email protected]:8388#Demo-SSss://: Shadowsocks 공유 링크 형식으로 해석하라는 의미입니다.YWVzLTEyOC1nY206cGFzc3dvcmQ: 암호화 방식과 비밀번호를 인코딩한 값입니다. 예시에서는 끝의 Base64 패딩 문자를 생략했습니다.example.com:8388: 서버 주소와 포트입니다. 가져올 때 포트를 다른 일반적인 값으로 임의 변경하면 안 됩니다.#Demo-SS: 메모 부분입니다. 연결 비밀번호가 아니며 서버 위치를 바꾸지도 않습니다.
일부 구형 공유 형식은 서버 주소를 포함한 더 긴 문자열 전체를 Base64로 인코딩합니다. 따라서 @의 유무만으로 형식을 판단해서는 안 됩니다. 플러그인 매개변수가 포함된 링크에는 쿼리 문자열이 붙을 수도 있습니다. 원본 설정에 플러그인이나 추가 전송 매개변수가 필요하다면 링크를 짧게 만들려고 임의로 삭제하지 마세요.
3. vmess://: JSON을 디코딩한 뒤 필드 확인
일반적인 vmess:// 공유 형식은 JSON 텍스트를 Base64로 인코딩한 뒤 접두사에 연결합니다. 디코딩한 결과는 구조가 올바른 JSON이어야 하며 웹 페이지 HTML이어서는 안 됩니다. 아래는 필드 설명을 위한 디코딩 결과이며, 그대로 붙여 넣어 가져올 수 있는 완전한 링크가 아닙니다.
{
"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 | 서버 주소와 포트 | HTTP Host 또는 SNI와 혼동하지 마세요 |
id / aid | UUID 및 alterId | 인증 매개변수는 기존 서버 설정과 일치해야 합니다 |
net / path | WebSocket 전송 및 요청 경로 | /demo의 대소문자와 슬래시도 설정의 일부입니다 |
host / sni | HTTP Host 및 TLS Server Name | 두 값이 같을 수도 있지만 역할은 다릅니다 |
ps / v | 메모 및 공유 형식 식별자 | v는 Shadowrocket 버전 번호가 아닙니다 |
출처에 따라 VMess 공유 내용의 필드가 다를 수 있으므로, 특정 필드의 유무만으로 서비스 이용 가능 여부를 판단할 수 없습니다. 가져온 뒤 해당 항목의 편집 화면을 열어 인증, 전송 방식, TLS 매개변수가 올바르게 인식됐는지 확인하세요. 이름이 표시되는 것은 클라이언트가 일부 정보를 읽었다는 뜻일 뿐, 서버가 해당 매개변수를 받아들인다는 의미는 아닙니다.
4. vless://와 trojan://: URI 필드가 읽히는 것과 전송 내용이 평문인 것은 별개
이 두 링크는 보통 구조를 쉽게 알아볼 수 있는 URI 형식을 사용합니다. 인증 정보는 @ 앞에, 서버 정보는 뒤에 오며 쿼리 매개변수에는 전송 방식이나 보안 설정이 담깁니다. 링크 필드를 쉽게 읽을 수 있는지와 실제 연결에 TLS를 사용하는지는 서로 다른 문제입니다. 아래 두 예시 모두 가상 인증 정보와 예시용 예약 도메인을 사용합니다.
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&type=tcp&sni=example.com#Demo-Trojan- VLESS 예시는 UUID 인증을 사용합니다.
encryption=none은 프로토콜 계층의 필드이며, 쿼리 매개변수에서 지정한 TLS를 해제한다는 뜻이 아닙니다. - Trojan 예시에서
demo-password는 비밀번호이고,sni=example.com은 TLS Server Name을 지정합니다. type=ws와type=tcp는 서로 다른 전송 방식을 나타내므로 접두사만 바꿔서 서로 변환할 수 없습니다.path=%2Fdemo를 디코딩하면/demo입니다. 퍼센트 인코딩은 URI의 특수 문자를 표현하는 방식이지 비밀번호를 안전하게 암호화하는 방법이 아닙니다.
비밀번호에 @, #, ? 같은 구분 문자가 있으면 링크 생성 단계에서 올바르게 퍼센트 인코딩해야 합니다. 직접 링크를 조합하면서 인코딩을 빠뜨리면 클라이언트가 비밀번호 일부를 서버 정보, 쿼리 매개변수 또는 메모로 잘못 해석할 수 있습니다. 이미 인코딩된 %2F를 다시 인코딩해 %252F로 만들지 마세요. 경로가 원래 값과 달라질 수 있습니다.
확인 방법: 접두사만 보고 호환성을 추측하지 말고 가져온 뒤 필드를 대조하세요
먼저 서버, 포트, 인증 정보를 확인하고 다음으로 전송 방식과 TLS를 확인하세요. 링크에 추가 보안 매개변수나 특정 전송 옵션이 있다면 클라이언트의 실제 해석 결과와 서버 요구사항을 기준으로 판단해야 합니다. 알 수 없는 필드를 삭제하거나 인증서 검증을 끄는 방식으로 링크를 '수정'하지 마세요.
5. 구독 가져오기와 업데이트: 출처를 유지하고 로컬 수정 사항을 원격 설정으로 착각하지 않기
아래는 가상임을 분명히 한 구독 주소입니다. 주소의 형태를 보여 주는 예시일 뿐입니다. 경로는 구독 인터페이스를 가리키고, 쿼리 매개변수의 token은 접근 권한을 확인하는 데 쓰이는 경우가 많습니다. 실제 구독의 경로, 매개변수 이름, 응답 형식은 사용자가 보유한 서비스 제공업체 설정에 따라 달라집니다.
https://example.com/sub?token=xxxx구독 응답은 지원되는 공유 링크를 모은 텍스트 목록일 수도 있고, 해당 텍스트를 Base64로 인코딩한 형태일 수도 있습니다. 응답 상태가 정상이더라도 내용이 로그인 페이지라면 유효한 연결 목록으로 가져올 수 없습니다. QR 코드도 텍스트를 담는 또 다른 방식입니다. 스캔 결과가 단일 공유 링크인지 구독 주소인지는 실제로 인코딩된 내용을 확인해야 합니다.
- 보유한 구독 주소 전체를 복사하고, 대화 텍스트에 붙은 마침표·따옴표·줄바꿈이 섞이지 않도록 하세요. 원본 token을 그대로 유지하고 임의로 추가하거나 삭제하지 마세요.
- Home에서 오른쪽 위
+를 탭해 새 항목 화면으로 이동합니다.Type → Subscribe를 선택하고URL에 주소를 입력한 뒤,Remarks에 출처를 적고 저장하세요. - 처음 가져오기가 끝나면 Home으로 돌아가 해당 구독과 항목을 확인하세요. 항목의 편집 화면을 열어 유형, 주소, 포트, 인증 필드가 비어 있지 않은지 확인합니다.
- 새로 고치려면 Home에서 해당 구독의 업데이트 기능을 사용하세요. 업데이트 후 항목 목록이 바뀌었는지 먼저 확인하고 실제 연결을 테스트합니다. '업데이트 성공'이 목록의 모든 서버를 사용할 수 있다는 뜻은 아닙니다.
관리 방법: 원격 구독과 로컬 테스트용 복사본을 분리하세요
원격 구독 유지
- 원본 URL과 출처 메모를 보관합니다.
- 업데이트 기능으로 목록의 추가·삭제 및 매개변수 변경 사항을 가져옵니다.
- 업데이트 전에 유지해야 할 사용자 지정 변경 사항을 기록합니다.
테스트 항목은 별도로 관리
- 변경 사항을 시험해야 한다면 메모를 분명히 적은 항목을 별도로 만드세요.
- 결과를 비교하기 쉽도록 매개변수는 한 번에 하나씩만 변경합니다.
- 테스트가 끝나면 Home에서 현재 선택된 항목을 확인합니다.
구독 업데이트 과정에서 원본 항목이 덮어써지거나 다시 만들어질 수 있습니다. 구독 항목에 임시로 적용한 수정 사항이 계속 유지된다고 기대하지 마세요.
6. 가져온 뒤 Global Routing으로 연결 문제와 규칙 문제 구분하기
Home에서는 연결 항목과 현재 선택을 관리하고, Config에서는 설정 파일을 다루며, Settings에서는 클라이언트 설정을 변경합니다. 단일 링크를 가져온 뒤에도 웹 페이지가 열리지 않는다고 해서 링크 형식이 잘못됐다고 단정할 수는 없습니다. 요청에 방금 가져온 항목이 사용되지 않았거나 현재 규칙이 다른 정책을 적용했을 수 있습니다. 먼저 Home에서 현재 선택된 항목을 기록한 다음 Global Routing을 확인하세요.
Config
추천현재 설정된 규칙에 따라 정책을 결정합니다. 기존 규칙 설정을 일상적으로 사용할 때는 Home의 선택 항목만 볼 것이 아니라, 적용된 규칙과 해당 규칙이 참조하는 정책도 함께 확인해야 합니다.
적합한 경우: 규칙 설정을 준비했고 요청을 규칙에 따라 처리하려는 경우
Proxy
클라이언트가 처리하는 요청에 프록시 방식을 적용해 현재 연결을 임시로 비교할 수 있습니다. 기기의 모든 통신이 예외 없이 이 방식으로 처리된다는 보장은 아니므로 테스트 후에는 기존 방식으로 되돌리세요.
적합한 경우: 규칙에 따른 분기가 테스트 결과에 영향을 주는지 잠시 확인할 때
Direct
직접 연결 방식을 사용하므로 방금 가져온 프록시 서버를 검증하는 데 적합하지 않습니다. 이 상태에서 웹 페이지가 열려도 공유 링크의 인증 매개변수가 올바르다는 증거는 아닙니다.
적합한 경우: 현재 네트워크에서 직접 연결했을 때의 결과를 비교할 때
Global Routing에는 장면 전환에 사용하는 Scene도 포함됩니다. 관련 동작은 기존 Scene 설정과 함께 확인해야 합니다. Scene은 새로운 프로토콜이 아니며 서버 인증을 대신하지 않습니다. 자동 연결 조건을 설정했다면 Settings → On Demand도 확인해 자동 재연결 동작을 가져오기가 저장되지 않은 것으로 오해하지 않도록 하세요.
- 먼저 '해석'을 확인합니다. 항목 편집 화면에서 서버, 포트, 프로토콜이 올바르게 표시되는지 살펴보세요.
- 다음으로 '연결'을 확인합니다. 네트워크를 사용할 수 있는 상태에서 현재 선택된 항목으로 대상 요청을 테스트하세요.
- 마지막으로 '라우팅'을 확인합니다. Config로 되돌린 뒤 요청에 실제로 적용된 규칙과 정책을 살펴보세요.
7. 자주 묻는 질문: 실패한 단계에 맞게 확인하고 링크를 반복해서 고치지 않기
ss://를 복사했는데 왜 가져오기에 실패하나요?
먼저 텍스트가 ss://로 시작하는지, 채팅 앱이 줄바꿈·공백·줄임표를 끼워 넣지 않았는지 확인한 다음 인코딩된 내용이 온전한지 살펴보세요. 화면에서 잘린 미리보기만 복사하지 마세요. 가져온 항목은 있지만 연결에 실패한다면 인증과 네트워크를 확인해야 합니다. Base64를 여러 방식으로 반복해서 디코딩할 필요는 없습니다.
브라우저에서 구독 주소가 열리는데 목록은 왜 비어 있나요?
주소가 열린다는 것은 어떤 응답을 받았다는 뜻일 뿐입니다. 보유한 서비스 제공업체의 구독 경로인지 계정 관리 페이지인지 확인하고, token이 온전한지 또는 권한을 다시 받아야 하는지 점검하세요. 응답이 로그인 페이지나 오류 안내라면 먼저 주소와 권한 문제를 해결해야 합니다. 웹 페이지 내용을 공유 링크 접두사로 바꿔 억지로 가져오려 하지 마세요.
구독 업데이트 시간 초과가 표시되면 모든 항목을 다시 추가해야 하나요?
먼저 현재 설정을 보존하고 현재 네트워크에서 구독 주소에 접근할 수 있는지 확인하세요. 해당 주소에 기존의 사용 가능한 연결을 통해 접근해야 한다면 Settings → Subscribe에서 Update via Proxy를 확인한 뒤 Home으로 돌아가 업데이트를 다시 시도할 수 있습니다. 인증 오류나 token 만료는 네트워크 시간 초과와 다릅니다. 접근 경로를 바꿔도 유효한 권한을 다시 받는 일을 대신할 수는 없습니다.
vmess://를 vless://로 바꾸면 프로토콜이 변환되나요?
아니요. 일반적인 VMess 공유 내용은 JSON을 인코딩한 형식이고, VLESS 공유 형식에는 UUID, 서버, 쿼리 매개변수가 직접 포함됩니다. 인증 방식과 프로토콜 동작도 서로 다릅니다. 보유한 서비스 제공업체에서 해당 프로토콜에 맞는 전체 설정을 받아 Home에서 새 항목을 만든 뒤 매개변수를 확인하세요. 앞부분의 몇 글자만 바꿔서는 안 됩니다.
문제 확인을 위해 링크 스크린샷을 다른 사람에게 보내려는데 비밀번호만 가리면 되나요?
그렇지 않습니다. UUID, 구독 token, QR 코드, 인코딩된 인증 문자열도 접근 권한을 제공할 수 있습니다. 문제를 문의할 때는 프로토콜, 포트, 전송 방식, 실패 단계만 텍스트로 설명하고 전체 링크는 삭제하세요. 실제 인증 정보가 유출됐다면 원래 서비스의 관리 경로에서 해당 정보를 변경하거나 폐기한 뒤 클라이언트에 저장된 내용도 업데이트해야 합니다.
문제 해결 순서를 명확히 정하세요. 원본 텍스트가 온전한지, 형식이 올바르게 해석됐는지, 원격 요청이 성공했는지, 인증 정보가 일치하는지, 규칙이 예상한 정책을 적용하는지 확인합니다. 한 번에 조건 하나만 바꾸고 변경 전후의 증상을 기록하면 구독 재구성, 프로토콜 변경, 규칙 수정 작업을 동시에 하는 것보다 원인을 찾기 쉽습니다.