Shadowrocket에서 연결 시간이 초과되더라도 비밀번호가 반드시 잘못된 것은 아니며, 원격 서버가 반드시 중단된 것도 아닙니다. 이미 자체 서비스 제공업체와 구독을 이용 중인 사용자를 위한 안내입니다. iPhone, iPad, Mac(Apple 실리콘 및 Intel), Windows, Android, Linux에서 사용할 수 있으며, 화면 경로는 iPhone/iPad를 기준으로 설명합니다. 다른 플랫폼에서는 해당 설정 항목을 확인하세요. 기존 설정과 테스트 결과를 보존하고 테스트 방식, 프로토콜 설정, 시스템 시간, 네트워크 출구 순으로 점검하며 한 번에 하나씩만 변경하세요.
1. 지연 시간 테스트 실패와 실제 연결 실패 구분하기
지연 시간 수치는 특정 시점의 네트워크에서 특정 테스트가 완료됐다는 사실만 보여 줍니다. 모든 앱에 정상적으로 접속할 수 있다는 뜻은 아닙니다. TCP 테스트는 주로 포트 연결을 확인하고, 프록시를 통한 HTTP 테스트는 프로토콜 핸드셰이크와 테스트 대상의 응답도 확인합니다. ICMP Ping은 원격 서버나 중간 네트워크에서 차단될 수 있습니다. 각 테스트가 측정하는 대상은 서로 다르므로 하나의 결과를 다른 테스트의 결과처럼 해석하지 마세요.
Home에서 현재 선택된 항목을 확인하고 사용한 테스트 방식을 기록한 다음, 같은 항목을 연속으로 세 번 테스트하세요. 한 번만 성공하거나 수치 변동이 크다면 결과를 보존하고 프로토콜을 바로 바꾸지 마세요. 그런 다음 연결을 켜고 브라우저에서 평소 안정적으로 접속되며 접근 권한이 있는 HTTPS 페이지를 열어 특정 대상만 실패하는지 확인하세요. 항목 전환, DNS 변경, 네트워크 변경을 동시에 하면 어떤 변경이 효과가 있었는지 알 수 없습니다.
| 확인된 현상 | 판단할 수 있는 내용 | 다음 단계 |
|---|---|---|
| TCP 테스트는 성공했지만 실제 접속은 실패 | 포트는 연결될 수 있지만 인증, TLS 또는 대상 요청은 실패할 수 있습니다. | 프로토콜 항목을 확인하고 요청이 선택한 항목을 거치는지 점검합니다. |
| ICMP 응답은 없지만 실제 접속은 정상 | ICMP 결과만으로 프록시 프로토콜을 사용할 수 없다고 판단할 수 없습니다. | 설정을 유지하고 실제 접속 및 프로토콜 테스트 결과를 기준으로 판단합니다. |
| 같은 구독의 모든 항목에서 시간 초과 발생 | 공통 원인이 있을 수 있으며 모든 서버의 장애라고 단정할 수 없습니다. | 네트워크, 구독 상태, 도메인 조회 및 기기 시간을 확인합니다. |
| 특정 항목 하나만 계속 실패 | 해당 항목 또는 원격 서비스 쪽에 문제가 있을 가능성이 높습니다. | 해당 항목의 주소와 포트, 서비스 상태를 확인합니다. |
결론: 테스트 대상을 먼저 고정하세요
항목 하나, 테스트 방식 하나, 대상 페이지 하나를 정해 기준을 세우세요. 기준이 고정되어야 네트워크 전환이나 설정 수정 결과를 비교할 수 있습니다.
2. 주소, 포트 및 구독 내용을 순서대로 확인하기
설정은 가장 기본적인 연결 정보부터 확인하세요. 주소의 글자 하나가 빠지거나 포트에 다른 서비스의 수신 포트를 입력해도 시간 초과가 발생할 수 있습니다. 포트는 프로토콜 이름에 따라 정해지는 값이 아닙니다. TLS를 사용한다고 포트가 반드시 443인 것은 아니며, 443이 흔히 쓰인다는 이유만으로 기존 포트를 임의로 바꾸지 마세요.
-
기존 설정 보존
Home에서 현재 항목 이름, Type, 오류가 발생한 시각을 기록하세요. Config를 수정하기 전에 기존 설정을 복사해 저장합니다. 비밀번호, UUID, 개인 키가 포함된 내용은 본인 기기에만 저장하고 공개 게시판에 올리지 마세요.
-
주소 확인
Home에서 현재 항목의 편집 화면을 열고 Address를 서비스 제공업체가 전달한 원래 설정과 한 글자씩 대조하세요. 주소 항목에는 일반적으로 도메인이나 IP를 입력합니다. 전체 웹 주소나 경로, 앞뒤 공백까지 함께 붙여 넣지 마세요.
-
포트 확인
Port가 원격 서버의 수신 포트와 일치하는지 확인하세요. 유효한 포트 범위는 1–65535입니다. 예를 들어 원격 서버에서 8443을 지정했다면 브라우저에서 HTTPS에 흔히 쓰인다는 이유로 443으로 바꾸면 안 됩니다. 포트에 연결할 수 있어도 그 포트에서 올바른 프록시 서비스가 실행 중이라는 뜻은 아닙니다.
-
인증 정보 확인
기존 정보와 Password, UUID 또는 해당 키 항목을 대조하고 복사할 때 줄바꿈과 앞뒤 공백이 포함되지 않았는지 확인하세요. 구독 링크의 액세스 토큰을 노드 비밀번호 항목에 입력하지 마세요. 두 값의 용도는 다릅니다.
-
업데이트 후 재테스트
구독으로 생성된 항목이라면 Home에서 해당 구독을 업데이트하거나 아래로 당겨 새로고침하세요. 작업이 완료되면 항목을 다시 선택합니다. 업데이트로 구독에서 생성된 설정이 덮어써질 수 있으므로 임시 수정 사항을 먼저 기록하세요. 업데이트에 실패하더라도 여전히 사용할 수 있는 기존 설정을 삭제하지 마세요.
구독 업데이트가 성공했다는 것은 구독 내용을 가져와 해석할 수 있다는 뜻일 뿐, 모든 주소가 온라인이라는 의미는 아닙니다. 반대로 업데이트에 실패했다고 저장된 항목이 반드시 사용할 수 없게 되는 것도 아닙니다. 서비스 제공업체가 포트, 인증 정보 또는 전송 설정을 변경했다면 기존 항목이 목록에 남아 있어도 더 이상 유효하지 않을 수 있습니다. 이때는 오래된 내용을 계속 가져오지 말고 서비스 제공업체에 변경 사항을 확인하세요.
3. 프로토콜 핸드셰이크 및 전송 설정 확인하기
Address와 Port가 올바르다면 Type과 관련 항목을 확인하세요. 프로토콜 이름만 바꾼다고 서로 호환되는 것은 아닙니다. 같은 서버 주소에 서로 다른 서비스가 설정되어 있을 수도 있습니다. 아래 표는 점검 방향을 안내합니다. 표시되는 항목은 프로토콜과 설정에 따라 다르므로 한 행의 설정을 모든 항목에 그대로 적용하지 마세요.
| 프로토콜 | 중점 확인 항목 | 판단 시 유의점 |
|---|---|---|
| Shadowsocks | 암호화 방식, Password, Address, Port | 비밀번호와 암호화 방식이 모두 일치해야 합니다. 포트에 연결할 수 있어도 복호화에 성공했다는 뜻은 아닙니다. |
| VMess | UUID, 암호화 설정, 전송 방식 및 서버가 지정한 추가 매개변수 | 기기 시간이 크게 어긋나면 인증에 영향을 줄 수 있으므로 UUID만 확인해서는 안 됩니다. |
| VLESS | UUID, 전송 방식, TLS 및 서버가 요구하는 보안 설정 | UUID만 복사해도 사용할 수 있는 설정 전체를 복사한 것은 아닙니다. |
| Trojan | Password, TLS, Server Name 및 인증서 신뢰 상태 | 연결에 사용하는 IP와 TLS 검증에 사용하는 도메인은 다를 수 있습니다. 원래 설정에 따라 입력하세요. |
| Hysteria2 | 인증 정보, TLS, 서버가 지정한 매개변수 및 UDP 연결 가능 여부 | QUIC 기반 프로토콜입니다. TCP 테스트에 성공해도 UDP 통신이 가능하다는 뜻은 아닙니다. |
| WireGuard | 로컬 개인 키, 피어 공개 키, Endpoint, 터널 주소 및 Allowed IPs | UDP를 사용합니다. 핸드셰이크 성공 후에도 라우팅과 DNS를 확인해야 합니다. |
WebSocket 전송을 사용하는 경우 Path와 Host를 확인하세요. Path의 슬래시, 대소문자 또는 끝 문자가 다르면 요청이 잘못된 서비스 경로로 전달될 수 있습니다. Host는 HTTP 요청에 사용되고 Server Name은 TLS 핸드셰이크의 서버 이름으로 사용되므로, 두 항목은 서로 임의로 바꿔 쓸 수 없습니다. 원래 설정에서 같은 값으로 지정한 경우에만 동일하게 입력하세요.
- TLS 이름: Address에 IP를 사용하지만 인증서는 도메인용으로 발급된 경우, 서비스 제공업체가 지정한 Server Name을 유지하세요. 모든 이름 항목을 IP로 바꾸면 안 됩니다.
- 전송 방식: 원격 서버에서 WebSocket을 요구하면 일반 TCP로 바꿔도 자동으로 호환되지 않습니다. gRPC 등 다른 전송 방식도 해당 서버 설정이 필요합니다.
- 인증서 검증: 인증서 오류가 발생하면 먼저 시간, 도메인, 인증서 유효 기간을 확인하세요. 인증서 검증을 계속 꺼 두는 방식으로 해결하지 마세요.
4. 오류 내용으로 원인을 좁히고 모든 실패를 시간 초과로 보지 않기
해당 요청의 로그나 진단 결과에 오류 전문을 기록하세요. 아래는 자주 볼 수 있는 하위 수준 오류 메시지입니다. 플랫폼에 따라 문구가 다를 수 있습니다. 연결 실패처럼 포괄적인 메시지만 보인다면 발생 단계를 함께 확인하고, 특정 단어 하나만으로 문제가 로컬 또는 원격에 있다고 단정하지 마세요.
오류: i/o timeout
원인 및 해결: 작업이 제한 시간 안에 완료되지 않았으며, 도메인 조회·연결·핸드셰이크 단계에서 발생했을 수 있습니다. 앞뒤 로그를 살펴 대상 주소와 발생 단계를 확인한 다음 같은 항목으로 네트워크를 바꿔 비교하세요. 이 메시지만으로 비밀번호가 잘못됐다고 단정할 수는 없습니다.
오류: connection refused
원인 및 해결: 연결 요청이 명시적으로 거부된 상태입니다. 해당 포트에서 서비스가 수신 대기 중이지 않거나 연결이 적극적으로 거부된 경우가 흔합니다. Port를 확인하고 서비스 제공업체에 해당 포트의 수신 상태를 문의하세요. 대기 시간을 늘려 해결하려고 하지 마세요.
오류: no such host
원인 및 해결: 도메인 조회에서 사용할 수 있는 결과를 얻지 못한 상태입니다. 철자, DNS 설정 또는 도메인 레코드가 원인일 수 있습니다. 먼저 Address를 한 글자씩 확인한 다음 현재 네트워크의 DNS를 점검하세요. 인증 실패로 바로 분류하지 마세요.
오류: x509: certificate has expired or is not yet valid
원인 및 해결: 인증서 유효 기간과 현재 기기 시간이 일치하지 않습니다. 먼저 기기의 날짜, 시간, 시간대를 맞추세요. 시간이 올바른데도 오류가 계속되면 서버 관리자가 인증서 유효 기간과 인증서 체인을 확인해야 합니다.
로그에 연결이 성립된 뒤 대상 사이트의 HTTP 오류가 나타난다면 프록시 경로와 대상의 응답을 구분하세요. 특정 페이지에서만 403 또는 429가 반환되는 경우 대상 사이트의 접근 정책이나 요청 빈도 제한일 수 있으며, 노드 포트에 연결할 수 없다는 뜻은 아닙니다. 응답이 발생한 시각과 대상 도메인을 기록해 페이지 접근 거부를 클라이언트 전체의 문제로 오해하지 않도록 하세요.
5. 시스템 시간을 맞춘 다음 네트워크 출구 확인하기
TLS는 인증서 유효 기간을 확인하며 일부 인증 방식도 시간 범위에 의존합니다. 날짜가 과거 또는 미래로 크게 어긋나거나 기기를 오랫동안 오프라인으로 둬 시간이 동기화되지 않으면 설정이 올바르더라도 핸드셰이크가 실패할 수 있습니다. iPhone/iPad에서는 시스템 Settings → General → Date & Time에서 Set Automatically를 확인하세요. 다른 플랫폼에서는 시스템의 날짜 및 시간 설정에서 자동 동기화를 켜고 표시된 시간이 정확한지 확인한 뒤 다시 테스트하세요.
- 먼저 직접 연결 상태 확인: Shadowrocket 연결을 일시 중지하고 브라우저에서 현재 Wi-Fi 또는 모바일 네트워크로 일반 웹페이지에 접속할 수 있는지 확인하세요. 호텔이나 학교 네트워크에서 웹 인증이 필요하다면 먼저 인증을 완료합니다.
- 네트워크를 바꿔 비교: 같은 기기, 같은 항목, 같은 대상에서 Wi-Fi와 모바일 네트워크를 각각 한 번씩 테스트하세요. 한 네트워크에서만 실패한다면 모든 프로토콜 설정을 바꾸기보다 해당 네트워크의 출구 정책을 먼저 확인하세요.
- UDP 제한 확인: Hysteria2와 WireGuard는 UDP를 사용합니다. 특정 네트워크에서 이 프로토콜들은 실패하지만 기존 TCP 연결은 작동한다면 UDP 통신을 확인할 필요가 있다는 뜻일 뿐, 프로토콜 구현에 문제가 있다고 단정할 수는 없습니다.
- 터널 충돌 확인: 시스템에서 다른 VPN이나 네트워크 필터 설정이 연결을 처리하고 있는지 확인하고, 충돌하는 항목을 잠시 끈 뒤 다시 테스트하세요. 관리 대상 기기에서는 관리자 정책을 따르고 조직의 제한을 우회하지 마세요.
연결을 끈 뒤 자동으로 다시 켜진다면 Shadowrocket의 Settings → On Demand를 확인하세요. 기존 설정을 기록한 후 자동 연결 조건을 일시적으로 꺼 보세요. On Demand는 연결을 시작할 시점을 정할 뿐 주소, 비밀번호, 원격 서비스 상태를 수정하지 않습니다. 문제 해결 후에는 원래 사용 목적에 맞게 설정을 복원하세요. 자동 연결을 계속 꺼 두는 것이 일반적인 해결책은 아닙니다.
DNS 변경 시 유의점: 도메인 조회가 실패하거나 결과가 명백히 잘못된 경우에만 DNS를 집중적으로 확인하세요. 모든 DNS 항목을 한꺼번에 바꾸거나 도메인 대신 IP를 임의로 사용하지 마세요. TLS 이름 검증이 함께 실패하고 원래 문제를 재현하기 어려워질 수 있습니다.
6. 지연 시간은 정상인데 접속이 안 될 때 Global Routing 및 Rule 확인하기
노드 테스트와 앱 요청은 서로 다른 경로로 처리될 수 있습니다. Home → Global Routing에서 현재 선택된 항목을 먼저 기록하세요. Proxy는 프록시 라우팅, Direct는 직접 연결 라우팅에 사용됩니다. Config는 현재 설정에 따라 처리하고 Scene은 설정된 장면에 따라 처리합니다. 이 네 가지는 연결 프로토콜이 아니며, 이름만으로 웹페이지가 어떤 경로를 사용하는지 알 수 없습니다. 매칭 결과와 실제 사용 중인 항목을 함께 확인하세요.
- 짧게 비교 테스트: 네트워크에 미치는 영향을 이해한 상태에서 Proxy와 Config의 접속 결과를 비교하고, 테스트 후 원래 설정으로 복원하세요. Proxy는 작동하지만 Config가 작동하지 않는다면 인증 항목을 먼저 바꾸기보다 규칙과 정책을 확인해야 합니다.
- 확인 순서: Config에서 현재 적용 중인 설정을 열고 Rule의 매칭 순서를 위에서 아래로 확인하세요. 앞쪽 규칙이 일치하면 일반적으로 뒤쪽 규칙은 해당 요청의 경로 선택에 적용되지 않습니다.
- 대상 확인: DOMAIN-SUFFIX는 도메인 접미사, IP-CIDR은 IP 대역, GEOIP는 IP 지리 데이터베이스를 기준으로 매칭합니다. FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 매칭 대상이 서로 다르므로 하나의 규칙으로 모든 연결을 판단할 수 없습니다.
- 정책 확인: 일치한 PROXY, DIRECT, REJECT 또는 사용자 지정 정책 그룹이 예상한 동작을 가리키는지 확인하세요. 그룹 이름이 있어도 그룹 안에서 현재 선택된 항목이 작동한다는 보장은 없습니다.
아래 예시는 규칙의 순서와 문법만 보여 주며 기존 Config 전체를 덮어쓰도록 권장하는 설정이 아닙니다. example.com은 문서용 예시 도메인이고 192.0.2.0/24는 문서용 예시 대역입니다. 실제 접속 대상을 기준으로 이해하고 예시를 실제 서비스 설정으로 사용하지 마세요.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY결론: 장애 단계에 맞춰 설정을 변경하세요
포트 연결 전에는 주소와 네트워크를 확인하세요. 핸드셰이크 실패 시에는 인증, TLS, 시간을 확인합니다. 핸드셰이크와 실제 프록시 접속이 성공한 뒤에만 특정 요청이 잘못된 정책으로 전달되는지 규칙을 중점적으로 확인하세요.
7. 재현 가능한 기록을 남기고 서비스 제공업체에 문의하기
위 항목을 확인해도 문제가 계속되면 단순히 “전부 시간 초과”라고 설명하기보다 원인을 파악할 수 있는 기록을 전달하세요. 기록에는 테스트 결과와 추측을 구분해야 합니다. 예를 들어 “같은 항목이 Wi-Fi에서는 실패하고 모바일 네트워크에서는 성공”은 검증 가능한 현상입니다. “서버가 차단됐다”는 추가 확인이 필요한 추측입니다. 테스트하지 않은 내용을 결론처럼 적지 말고, 기록을 완성하기 위해 인증 정보를 공개하지도 마세요.
- 기기 및 환경: 기기 플랫폼, 현재 네트워크 유형, 네트워크 인증 필요 여부 및 조직 관리 정책 적용 여부.
- 재현 시각: 문제가 발생한 시각과 시간대, 시스템 시간 동기화 여부를 기록해 원격 로그와 대조할 수 있게 합니다.
- 설정 범위: 프로토콜 Type, 전송 방식, TLS 사용 여부, 항목 하나만 실패하는지 같은 그룹의 모든 항목이 실패하는지 기록합니다.
- 비교 결과: 테스트 방식, 연속 세 번의 결과, 네트워크별 결과 및 Global Routing 선택 항목.
- 오류 내용: 필요한 단계 정보를 남기고 Password, UUID, 개인 키, 구독 토큰 및 개인 정보는 가리세요.
이 사이트는 노드나 구독을 제공·판매·추천하지 않습니다. 노선 상태, 인증 정보의 유효성, 원격 설정은 사용자가 이용 중인 서비스 제공업체에 확인해야 합니다. 클라이언트를 설치하는 것과 노선 서비스를 이용하는 것은 별개의 문제이므로 설정을 확인하는 대신 반복해서 설치하지 마세요. 설치하거나 기기를 변경하려면 이 사이트의 전체 플랫폼 다운로드 안내에서 기기에 맞는 항목을 선택하세요.