Shadowrocket에서 시간 초과가 표시되더라도 원격 서버가 중단됐다고 단정할 수는 없습니다. 이미 서비스 제공업체와 설정을 보유한 사용자를 위한 안내입니다. 먼저 같은 테스트 방식으로 특정 노드, 현재 네트워크, 대상 웹사이트 중 어디에 문제가 있는지 구분한 다음 주소·포트·인증·전송 방식·TLS를 확인하세요. 마지막으로 시스템 시간과 실제 트래픽 경로를 점검합니다. 한 번에 한 항목만 변경하고 기존 설정과 테스트 결과를 보관해 점검 중 새로운 오류가 생기지 않도록 하세요.
1. 지연 시간 초과와 실제 연결 실패 구분하기
지연 시간 테스트는 실제로 수행한 탐색 과정만 확인하며, 모든 웹사이트와 프로토콜이 정상이라는 뜻은 아닙니다. TCP 핸드셰이크에 성공해도 대상 TCP 포트에 연결할 수 있다는 의미일 뿐, 비밀번호·UUID 또는 이후 TLS 핸드셰이크까지 올바르다는 보장은 없습니다. 프록시를 통해 테스트 주소에 접속한 결과는 테스트 주소, DNS, 원격 출구의 영향도 받습니다. 먼저 테스트 방식을 기록한 뒤 결과를 비교하고, 서로 다른 방식으로 측정한 지연 시간을 한데 모아 순위를 매기지 마세요.
아래 내용은 결과를 해석하는 기준이며, 이 사이트에서 직접 측정한 결과가 아닙니다. 사용 중인 기기에서 확인한 값을 기록하고 최소 세 번 연속 테스트하세요. 테스트 방식·노드·네트워크는 동일하게 유지해야 합니다.
| 관찰된 현상 | 판단할 수 있는 내용 | 다음 단계 |
|---|---|---|
| 노드 하나만 세 번 연속 시간 초과 | 해당 노드 또는 노드까지의 경로에 문제가 집중됐을 가능성이 큽니다. | 해당 노드의 주소·포트·프로토콜 설정을 확인하세요. |
| 보유한 노드가 모두 시간 초과 | 공통 네트워크, DNS 확인 또는 설정 문제일 수 있습니다. | 먼저 일반 인터넷 연결을 확인한 다음 네트워크를 바꿔 재테스트하세요. |
| 포트 테스트는 성공하지만 실제 웹페이지는 열리지 않음 | 포트에 연결할 수 있어도 프록시 인증에 성공했다는 뜻은 아닙니다. | 인증·TLS·전송 방식·라우팅을 확인하세요. |
| 웹페이지는 정상적으로 열리지만 테스트만 시간 초과 | 현재 연결에 적합하지 않은 테스트 대상이나 테스트 방식일 수 있습니다. | 테스트 설정을 확인하고 노드를 서둘러 다시 만들지 마세요. |
| 웹사이트 하나만 접속 실패 | 이 결과만으로 노드 전체가 작동하지 않는다고 판단할 수 없습니다. | 해당 도메인의 규칙·DNS·대상 사이트 상태를 확인하세요. |
요점: 테스트 조건부터 일정하게 유지하세요
같은 방식으로 같은 노드를 세 번 연속 테스트한 다음 네트워크만 바꿔 재테스트하세요. 프로토콜과 규칙을 동시에 변경하면 어떤 변경이 결과에 영향을 줬는지 확인하기 어렵습니다.
2. 최소한의 재테스트를 순서대로 진행하기
아래에서는 iPhone / iPad의 Home, Config, Settings 화면 용어를 기준으로 점검 위치를 안내합니다. 다른 플랫폼에서는 해당 설정을 확인하세요. 시작하기 전에 현재 설정의 사본을 저장하세요. 구독으로 추가한 노드와 직접 수정한 노드도 각각 기록해 두고, 특히 백업 없이 목록 전체를 삭제하지 마세요.
-
기본 인터넷 연결 확인
Home에서 연결을 끄고 브라우저로 평소 바로 열리는 페이지에 접속해 보세요. 기본 인터넷 연결부터 되지 않는다면 노드 비밀번호를 바꾸기 전에 Wi-Fi 로그인, 셀룰러 데이터 권한 또는 라우터 연결을 확인하세요.
-
테스트 대상 고정하기
Home으로 돌아가 보유한 노드 하나를 선택하고 테스트 방식과 세 번 연속 측정한 결과를 기록하세요. Connectivity Test를 사용하는 경우 먼저 테스트 설정을 확인하고, 재테스트 중에는 테스트 대상을 바꾸지 마세요.
-
네트워크 바꿔 연결하기
노드와 테스트 방식은 그대로 두고 Wi-Fi에서 셀룰러 네트워크로 전환한 뒤 다시 테스트하세요. 한쪽 네트워크에서만 실패한다면 해당 네트워크가 포트·UDP·도메인 확인에 미치는 영향을 먼저 살펴보세요.
-
자동 연결 설정 확인
Settings → On Demand로 이동해 현재 설정을 기록하세요. 수동으로 연결을 끊어도 다시 자동 연결된다면 점검하는 동안 On Demand를 잠시 끄고, 비교 테스트가 끝난 뒤 원래 설정으로 되돌리세요.
-
재테스트 결과 기록하기
네트워크 유형, 노드 이름, 테스트 방식, 발생 시각, 오류 원문을 기록하세요. 매번 한 항목만 변경하고 저장한 뒤 다시 연결해 같은 조건으로 테스트하세요.
3. 주소·포트·인증·전송 방식 순으로 프로토콜 설정 확인하기
Home에서 대상 노드의 편집 화면을 열고 서비스 제공업체가 제공한 원본 설정과 항목별로 대조하세요. 서버 주소와 포트를 먼저 확인한 뒤 프로토콜 유형과 인증 항목을 살펴보고, 마지막으로 전송 방식과 TLS를 확인하세요. 설정 이름을 서버 주소로 착각하지 말고, 흔히 쓰이는 포트라는 이유만으로 값을 바꾸지 마세요. 443 포트라고 해서 해당 노드가 반드시 TLS를 사용하는 것은 아니며, 8443도 임의로 바꿔 쓸 수 있는 예비 포트가 아닙니다.
| 프로토콜 또는 항목 | 확인할 내용 | 흔히 잘못 판단하는 부분 |
|---|---|---|
| 주소와 포트 | 전체 호스트 이름 또는 IP, 원래 포트(범위: 1–65535) | 문자 누락, 복사 중 공백 삽입, 또는 연결 주소에 포함된 다른 숫자를 포트로 착각 |
| Shadowsocks | 암호화 방식과 비밀번호. 원본 설정에 플러그인이 포함됐다면 플러그인 설정도 확인하세요. | 포트에는 연결되지만 암호화 방식이나 비밀번호가 일치하지 않음 |
| VMess / VLESS | UUID, 서버에서 요구하는 관련 옵션과 전송 설정 | UUID만 복사하고 WebSocket 경로나 다른 전송 설정을 빠뜨림 |
| Trojan | 비밀번호, TLS, Server Name, 인증서의 대응 관계 | 연결 IP는 맞지만 TLS에 사용하는 이름이 잘못됨 |
| Hysteria2 | 인증·TLS·포트와 현재 네트워크에서 필요한 UDP 통신을 허용하는지 여부 | TCP 테스트 결과를 UDP 연결 가능 여부로 오해 |
| WireGuard | 키·Peer·Endpoint·인터페이스 주소·라우팅 범위 | Endpoint만 입력하고 나머지 설정을 빠뜨리거나 개인 키와 공개 키를 바꿔 입력 |
| WebSocket / gRPC | 전송 유형과 원본 설정에 지정된 Host·Path 또는 Service Name | WebSocket 경로를 gRPC의 Service Name으로 잘못 입력 |
서버 연결 주소, TLS의 Server Name, WebSocket의 Host는 서로 다를 수 있습니다. 각 항목은 연결 설정, 인증서 검증 또는 애플리케이션 계층 요청에 각각 사용됩니다. 반드시 보유한 원본 설정을 기준으로 입력하고, 값을 모두 같은 도메인으로 맞추지 마세요. 경로도 원본 그대로 유지해야 합니다. 예를 들어 원본 설정이 /gateway라면 앞의 슬래시를 삭제하거나 대소문자를 임의로 바꾸지 마세요.
- 구독에서 가져온 노드는 먼저 구독이 정상적으로 업데이트됐는지 확인한 다음 로컬 설정이 오래된 것은 아닌지 살펴보세요.
- 구독 노드를 직접 수정하기 전에 사본을 보관하세요. 이후 업데이트 과정에서 노드 항목이 다시 덮어써질 수 있습니다.
- 같은 서비스 제공업체의 노드라도 포트·비밀번호·전송 방식이 다를 수 있으므로 서로의 설정을 그대로 적용하지 마세요.
- TLS 오류를 감추려고 인증서 검증을 끄지 마세요. 먼저 이름·인증서·시스템 시간을 확인하세요.
4. 오류 문구로 시간 초과·연결 거부·TLS 실패 구분하기
연결 로그에 오류 문구가 표시되면 원문과 발생 시각을 보관하세요. 시스템과 프로토콜에 따라 표현이 다를 수 있습니다. 아래는 흔히 볼 수 있는 네트워크 오류 문자열을 해석하는 방법이며, 모든 플랫폼에서 똑같은 문구가 표시된다는 뜻은 아닙니다. 오류 단어 하나만으로 원인을 특정하기는 어려우므로 앞서 진행한 네트워크 비교 테스트 결과도 함께 확인하세요.
오류: i/o timeout
원인 및 해결 방법: 제한 시간 안에 연결·핸드셰이크·데이터 읽기 등 네트워크 작업이 완료되지 않았을 수 있습니다. 먼저 오류가 발생한 단계를 확인하고 주소와 포트를 점검한 뒤, 다른 네트워크에서도 다시 테스트하세요.
오류: connection refused
원인 및 해결 방법: 연결 시도가 명시적으로 거부됐습니다. 대상 포트에서 해당 서비스가 실행되지 않거나 연결이 능동적으로 거부된 경우가 흔합니다. 포트가 올바른지 확인한 뒤 서비스 제공업체에 해당 포트의 서비스 상태를 문의하세요.
오류: no such host
원인 및 해결 방법: 서버 도메인 확인에 필요한 결과를 얻지 못했습니다. 도메인 철자와 현재 네트워크의 DNS 확인 상태를 살펴보세요. 비밀번호를 먼저 바꾸거나 인터넷에서 찾은 IP 주소로 원래 도메인을 함부로 대체하지 마세요.
오류: certificate has expired or is not yet valid
원인 및 해결 방법: 인증서 유효 기간과 기기의 현재 시간이 일치하지 않습니다. 먼저 시스템 시간 자동 설정을 켜세요. 시간이 올바른데도 문제가 계속되면 서비스 제공업체에 인증서 유효 기간을 확인해 달라고 요청하세요.
구체적인 오류 없이 ‘시간 초과’만 표시된다면 인증 오류라고 단정하지 말고 테스트 조건부터 보완하세요. 인증 실패, TLS 핸드셰이크 실패, 원격 서버 무응답이 간략한 상태 표시에서는 비슷하게 보일 수 있지만 해결 방법은 서로 다릅니다.
5. 시스템 시간과 인증서 검증 조건 확인하기
시스템 시간이 모든 시간 초과의 원인은 아니지만 TLS 또는 인증 관련 연결이 주로 실패한다면 확인할 필요가 있습니다. 인증서에는 유효 시작 시각과 만료 시각이 포함되므로 기기 시간이 실제와 크게 다르면 검증에 실패할 수 있습니다. 일부 프로토콜의 인증 방식에도 시간이 관련됩니다. 시간대를 바꾸면 표시 방식만 달라질 뿐 기기 시계가 보정되지는 않습니다.
- iPhone / iPad: 시스템의 ‘설정 → 일반 → 날짜 및 시간’을 열고 ‘자동 설정’을 켜세요. 옵션을 변경할 수 없다면 기기 관리 설정이나 시스템 제한을 확인하고 Shadowrocket 설정을 반복해서 바꾸지 마세요.
- Mac: ‘시스템 설정 → 일반 → 날짜 및 시간’에서 날짜 및 시간 자동 설정을 확인하고 기기가 정상적으로 동기화되는지 살펴보세요.
- Windows: ‘설정 → 시간 및 언어 → 날짜 및 시간’에서 시간 자동 설정을 확인하고 시스템에서 제공하는 동기화 기능을 사용하세요.
- Android / Linux: 시스템의 날짜 및 시간 설정에서 네트워크 시간 또는 시간 동기화 서비스를 확인하세요. 메뉴 이름은 기기와 데스크톱 환경에 따라 다를 수 있습니다.
시간을 맞춘 뒤 Shadowrocket으로 돌아가 연결을 끊었다가 다시 연결하고 같은 테스트를 실행하세요. 시간이 올바른데도 인증서 오류가 계속되면 Server Name이 인증서와 일치하는지, 인증서 체인이 유효한지 확인하세요. 인증서 유효 기간에 맞추려고 기기 날짜를 임의로 바꾸지 마세요. 다른 앱에 영향을 줄 수 있고 원격 인증서 문제도 해결되지 않습니다.
요점: 시스템 시간을 확인한 뒤 인증서를 점검하세요
자동 시간 설정이 정상인데도 반복해서 연결할 때 인증서 오류가 발생하면 오류 원문과 발생 시각을 서비스 제공업체에 전달해 확인하세요. 인증서 검증 설정은 유지하고 검증 기준을 낮추는 방법을 장기적인 해결책으로 사용하지 마세요.
6. 노드가 연결되면 Global Routing과 규칙 확인하기
노드 테스트는 정상으로 돌아왔지만 웹페이지가 열리지 않는다면 실제 트래픽 경로를 확인하세요. Home → Global Routing에서 현재 모드를 살펴보세요. Proxy는 트래픽을 프록시로 처리하고, Direct는 직접 연결하며, Config는 활성 설정의 규칙에 따라 처리합니다. Scene은 설정된 장면별 설정에 따라 처리합니다. 노드를 선택했더라도 모든 연결이 반드시 해당 노드를 거치는 것은 아닙니다.
기존 설정을 기록한 다음 비교 테스트를 위해 Proxy를 잠시 사용할 수 있습니다. Proxy에서는 대상 웹페이지가 열리지만 Config에서 실패한다면 노드 인증을 계속 바꾸기보다 현재 활성화된 Config와 적용된 규칙 및 정책을 확인하세요. 테스트가 끝나면 일상적인 사용 목적과 다른 설정이 계속 적용되지 않도록 원래 모드로 되돌리세요.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY위 내용은 규칙 매칭 관계를 설명하기 위한 것이며 기존 설정을 그대로 덮어쓰라는 뜻은 아닙니다. DOMAIN-SUFFIX는 지정된 도메인과 하위 도메인에 매칭되고, IP-CIDR은 주소 대역에 매칭됩니다. 규칙은 일반적으로 순서대로 적용되며 FINAL은 앞에서 매칭되지 않은 연결을 처리합니다. GEOIP은 IP 지리 위치 데이터베이스를 기준으로 판단하므로 도메인 접미사를 기준으로 하는 것과는 다릅니다.
- Config에서 설정 파일을 열어 두기만 한 것이 아니라 의도한 설정이 실제로 활성화되어 있는지 확인하세요.
- 대상 도메인에 DIRECT, 거부 정책 또는 예상과 다른 정책 그룹이 먼저 적용되는지 확인하세요.
- 도메인으로 접속할 때만 실패하고 주소로는 연결된다면 DNS를 확인하세요. IP 주소 접속과 도메인 접속을 완전히 동일한 TLS 테스트로 간주하지 마세요.
- 기기에서 다른 VPN 연결도 사용 중이라면 점검하는 동안 연결을 중지해 시스템 네트워크 상태에 따른 영향을 줄이세요.
7. 자주 묻는 질문과 점검 기록 정리하기
지연 시간은 측정되는데 웹페이지가 열리지 않는 이유는 무엇인가요?
먼저 지연 시간 테스트가 포트만 확인하는지 살펴보세요. Home으로 돌아가 Global Routing을 확인하고 기존 모드를 기록한 뒤 Proxy로 접속 결과를 비교하세요. 그래도 실패한다면 인증·TLS·전송 설정을 점검하세요. 포트에 연결된다는 사실만으로 전체 프록시 연결이 정상이라고 볼 수는 없습니다.
셀룰러 네트워크로 바꾸면 정상인데 설정을 다시 가져와야 하나요?
기존 설정을 삭제하지 마세요. 같은 노드를 두 네트워크에서 각각 세 번씩 테스트하고 네트워크 유형을 기록하세요. 차이가 계속된다면 Wi-Fi 로그인 상태, DNS 확인, UDP 연결 가능 여부를 살펴보세요. 같은 설정을 다시 가져오는 것만으로는 접속 네트워크에 따른 차이를 설명하기 어렵습니다.
구독 업데이트도 시간 초과가 발생하면 모든 노드가 작동하지 않는 건가요?
반드시 그런 것은 아닙니다. 구독을 가져오는 요청과 노드에 연결하는 요청은 서로 다른 경로를 사용합니다. 먼저 서비스 제공업체에 기존 구독 링크가 유효한지 확인하고 업데이트가 정상적으로 완료됐는지 살펴보세요. 노드를 전부 삭제하지 마세요. 오류 기록을 공유할 때는 링크에 포함된 token 등 인증 정보를 가리세요.
확인을 마쳤습니다. 어떤 정보를 전달해야 하나요?
프로토콜 유형, 시스템 플랫폼, 오류 발생 시각, 접속 네트워크, 테스트 방식, 세 번의 결과, 민감한 정보를 가린 오류 원문을 전달하고 네트워크를 바꾼 뒤의 결과도 덧붙이세요. 비밀번호·개인 키·전체 구독 링크·인증 token은 공개 스크린샷이나 게시판에 올리지 마세요.
앱을 다시 설치하거나 플랫폼별 다운로드 경로를 확인하려면 사이트의 다운로드 페이지를 이용하세요. iPhone / iPad에서는 App Store에서 다운로드할 수 있으며 개발자는 Shadow Launch Technology Limited입니다. 시스템 요구 사항은 App Store 페이지에 표시된 내용을 기준으로 확인하세요. Mac용은 Apple 칩 및 Intel 버전이 제공되며 Windows·Android·Linux 버전도 있습니다. 설정과 네트워크를 점검하지 않은 채 앱을 재설치하지 말고, 작업 전에 먼저 백업하세요.