Shadowrocket Trojan 설정 방법: 비밀번호, SNI, TLS 확인

Trojan 설정값을 각각 확인해야 하는 이유

Trojan은 TLS로 클라이언트와 서버 간 통신을 보호한 다음, 해당 연결을 통해 프로토콜 인증과 트래픽 전달을 수행합니다. 일반적인 Trojan은 TCP 위에서 동작합니다. TLS 연결에 성공했다고 해서 Password 인증까지 통과했거나 대상 웹사이트에 정상적으로 접속할 수 있다는 뜻은 아닙니다. 이 세 단계는 따로 확인해야 합니다.

서버 주소는 연결할 대상을, 포트는 서버에서 연결할 서비스를 지정합니다. SNI는 TLS 핸드셰이크에서 서버 이름을 알리고, Password는 Trojan 인증에 사용됩니다. 같은 설정표에서 받은 값이어도 서로 대신 사용할 수는 없습니다. 특히 구독 링크의 token, 계정 로그인 비밀번호, 다른 프로토콜의 UUID를 Trojan Password로 입력하지 마세요.

Add Server에서 항목별로 입력하기

아래는 Home에서 수동으로 추가하는 절차입니다. 플랫폼마다 양식 배치는 다를 수 있지만 각 필드의 역할은 같습니다. 구독에 필요한 설정값이 모두 포함되어 있다면 구독에서 받은 값을 우선 사용하세요. 서비스 제공업체가 특정 항목을 추가하거나 수정하라고 안내한 경우에만 해당 값을 직접 변경합니다.

1. 입력 화면 열기

   Home → 오른쪽 위 “+” → Add Server로 이동한 다음 Type에서 Trojan을 선택합니다. 노드 이름에 “TLS”가 들어 있다는 이유만으로 프로토콜을 추측하지 말고 먼저 유형을 확인하세요.

2. 주소 입력

   Address에는 서비스 제공업체가 안내한 호스트 이름이나 IP를, Port에는 지정된 포트를 입력합니다. 예를 들어 포트가 443이라면 Port에만 443을 입력하세요. Address에 https://, 경로, 끝의 슬래시는 붙이지 않습니다.

3. 비밀번호 입력

   해당 Trojan 노드의 비밀번호를 Password에 붙여 넣습니다. 대소문자와 앞뒤 공백, 줄바꿈을 확인하세요. 문자를 임의로 바꾸거나 원래 비밀번호를 미리 URL 인코딩하지 마세요.

4. TLS 설정 확인

   입력 화면에서 TLS 설정을 열고 서비스 제공업체의 안내에 따라 SNI와 인증서 검증 설정을 확인합니다. ALPN, 전송 방식, WebSocket 설정도 안내받았다면 각각 일치시켜야 합니다. 다른 노드의 값을 그대로 가져오지 마세요.

5. 저장 후 테스트

   저장한 뒤 Home으로 돌아가 방금 추가한 노드를 선택합니다. 규칙의 영향을 제외하려면 Global Routing을 잠시 Proxy로 설정하고 연결을 켠 다음, 정상 작동이 확인된 HTTPS 페이지에 접속해 보세요. 테스트를 마치면 평소 사용하는 라우팅 설정으로 되돌립니다.

Address, Password, SNI 입력 시 유의사항

아래 예시는 예약된 예시 도메인으로 필드 형식을 보여줍니다. gateway.example.com과 tls.example.com은 이 글에서 제공하는 서비스 주소가 아닙니다. 주소와 SNI가 서로 달라도 반드시 오류인 것은 아닙니다. 별도의 연결 주소를 사용하면서 TLS 핸드셰이크에는 인증서에 포함된 다른 이름을 지정하는 구성도 있습니다.

SNI와 HTTP Host는 서로 다른 필드입니다. 서비스 제공업체가 WebSocket 전송을 사용하는 경우 Host와 Path도 안내할 수 있습니다. Path는 /로 시작할 수 있지만 SNI에는 경로가 포함되지 않습니다. 일반 Trojan에 별도 전송 설정이 필요하지 않다면 WebSocket을 임의로 켜거나 추측한 Path를 추가하지 마세요.

• 비밀번호에 특수 문자가 포함된 경우: Password 필드에 직접 입력할 때는 원래 값을 사용하세요. 공유 링크에서 가져오는 경우 인코딩은 가져오기 과정에서 처리되므로 다시 수동으로 인코딩하거나 디코딩하지 마세요.
• 주소에 IP를 사용하는 경우: 서버 인증서와 일치하도록 도메인 형식의 SNI가 필요할 수 있습니다. Address가 IP라는 이유로 SNI까지 IP로 바꾸지 마세요.
• SNI를 안내받지 못한 경우: 잘 알려진 웹사이트의 도메인을 임의로 입력하지 마세요. 구독의 전체 설정값을 확인하거나, 주소 도메인을 서버 이름으로 사용하는지 서비스 제공업체에 문의하세요.

TLS 검증 문제를 비밀번호 변경으로 해결할 수 없습니다

TLS 인증서 검증은 연결 상대의 신원을 확인하며, 일반적으로 인증서 신뢰 체인과 유효 기간, 이름 일치 여부를 확인합니다. 서버에 접속할 수 있더라도 제공된 인증서가 현재 SNI에 적합하다는 뜻은 아닙니다. 기기의 날짜나 시간대가 잘못되어 유효한 인증서가 아직 유효하지 않거나 이미 만료된 것으로 판정될 수도 있습니다.

SNI에 따라 서버가 제공할 인증서가 달라질 수 있으며, 클라이언트는 인증서가 예상한 이름을 포함하는지 확인해야 합니다. 두 항목은 관련이 있지만, 아무 도메인이나 입력하면 암호화된다는 뜻은 아닙니다. Password 오류는 그 이후의 인증 문제입니다. Password를 반복해서 바꿔도 인증서 이름 불일치는 해결되지 않습니다.

ALPN은 애플리케이션 계층 프로토콜을 협상하는 기능이지 속도를 높이는 범용 설정이 아닙니다. 서비스 제공업체가 지정하지 않았다면 기존 설정을 유지하고 h2나 http/1.1을 임의로 강제하지 마세요. 오류를 없애려고 TLS 설정을 낮추는 것도 피해야 합니다. 먼저 서버 측 요구 사항을 확인하세요.

연결에 성공한 뒤 규칙과 노드를 따로 확인하기

Home에서 연결 스위치를 켜면 클라이언트의 연결 절차가 시작되지만, 모든 요청이 현재 선택된 Trojan 노드를 통과한다는 뜻은 아닙니다. Global Routing에서 Direct를 선택하면 요청이 직접 연결됩니다. Config는 활성화된 구성의 규칙에 따라 정책을 선택합니다. Proxy는 규칙에 따른 라우팅의 영향을 잠시 제외할 때 사용할 수 있습니다. Scene은 관련 설정도 함께 확인해야 하므로 처음 문제를 해결할 때 변수를 추가하지 않는 편이 좋습니다.

1. 먼저 Home에서 테스트할 Trojan 노드를 선택한 뒤 Global Routing → Proxy를 잠시 선택합니다. 다시 연결하고 동일한 테스트 페이지에 접속하세요.
2. Proxy에서는 접속되지만 Config에서 결과가 다르면 Config로 이동해 현재 활성화된 구성과 [Rule]을 확인하세요. 바로 SNI를 바꾸지 마세요.
3. 규칙에 DIRECT가 적용되는지, PROXY로 지정된 요청이 실제로 어떤 노드나 정책 그룹을 선택하는지 확인하세요.
4. 자동 재연결의 영향을 확인하려면 Settings → On Demand에서 현재 설정을 살펴보세요. On Demand는 연결을 시작할 조건을 관리할 뿐 Trojan 인증 설정을 수정하지 않습니다.

예를 들어 아래 규칙은 예시 도메인과 그 하위 도메인만 PROXY로 보내고, 일치하는 규칙이 없는 요청은 DIRECT로 처리합니다. 이는 규칙 문법의 예시일 뿐 연결 설정값이나 완전한 구성은 아닙니다. 규칙은 순서대로 적용되므로 FINAL은 맨 끝에 배치해야 합니다. 사용하기 전에 현재 구성에서 프록시 정책이 예상대로 선택되는지도 확인하세요.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

이 구성에서는 다른 웹사이트에 접속할 때 Trojan 트래픽이 관찰되지 않는 것이 정상입니다. 인증서 오류는 TLS 설정을 중심으로 확인하고, 특정 웹사이트가 프록시를 거치지 않는 문제는 규칙 일치를 확인해야 합니다. 두 문제를 혼동하면 올바른 노드 설정까지 반복해서 잘못 바꿀 수 있습니다.

자주 발생하는 오류와 구독 설정 덮어쓰기

문제를 확인할 때 오류가 발생한 시간, 현재 네트워크, 선택한 노드, Global Routing 상태를 기록한 뒤 확인 가능한 연결 진단 정보를 살펴보세요. 아래 내용은 문제를 나누어 확인하기 위한 기준이며, 오류 메시지 하나만으로 원인을 단정할 수는 없습니다. 같은 “시간 초과” 메시지도 서로 다른 단계에서 나타날 수 있습니다.

서비스 제공업체가 개별 노드가 아닌 구독을 제공한다면 Home → “+” → Type → Subscribe에서 본인의 링크를 가져온 다음 Home으로 돌아가 구독을 업데이트하세요. 예시 링크 https://example.com/sub?token=xxxx는 형식을 설명하기 위한 것으로 연결에 사용할 수 없습니다. 문제 해결을 위해 화면을 공유할 때는 Password, 구독 token, 전체 구독 주소를 가리세요. 문의를 제출할 때는 필드 이름, 오류 유형, 필요한 비식별 정보만 남기면 됩니다.

문제를 문의하기 전 확인할 항목

한 번의 통제된 테스트를 마친 뒤 서비스 제공업체의 지원이 필요한지 판단하세요. 네트워크, 노드, SNI, 규칙을 동시에 바꾸면 문제를 재현하기 어렵습니다. 비교 테스트에서는 같은 대상 페이지를 사용하고 이름이 비슷한 다른 구독 노드를 선택하지 않았는지 확인하세요.

• 연결 지점: Address와 Port를 원본 정보와 대조했으며, 웹페이지 URL을 주소 필드에 붙여 넣지 않았습니다.
• 인증 정보: Type이 Trojan이고 해당 노드의 Password를 사용했으며, 공백이나 줄바꿈이 포함되지 않았습니다.
• TLS 정보: SNI와 인증서 검증 설정이 서비스 제공업체의 안내와 일치하고, 기기 날짜가 올바르며, ALPN을 임의로 추가하지 않았습니다.
• 전송 정보: 원래 설정에서 명확히 요구하는 경우에만 WebSocket, Host, Path를 구성했습니다.
• 테스트 환경: Proxy와 Config에서 실제로 어떤 차이가 있는지 기록하고, 요청이 예상한 정책에 일치하는지 확인했습니다.
• 업데이트 출처: 수동 항목과 구독 항목을 구분하고, 다음 구독 업데이트가 로컬 변경 사항을 덮어쓸지 확인했습니다.

설정값을 확인한 뒤 Global Routing을 평소 사용하는 상태로 되돌리고 Config에서 활성화된 구성을 다시 확인하세요. 필드 구성을 알아보려면 설정 필드 안내를, 라우팅 모드를 구분하려면 프록시 모드 안내를 참조하세요. 프로토콜 설정이 올바른지, 인증서가 신뢰할 수 있는지, 요청이 예상한 규칙에 일치하는지는 각각 따로 충족해야 합니다.