이 글은 Shadowrocket에 직접 준비한 Config를 이미 가져왔지만, 기존 노드 목록에서 무엇을 선택해야 할지 모르는 사용자를 위한 안내입니다. 연결할 수 없는 항목을 먼저 제외하고, 여러 차례의 지연 시간과 변동 폭을 비교한 뒤 지역·프로토콜·실제 용도에 따라 짧게 재검증하여 안정적인 후보만 남기는 순서로 판단합니다.
먼저 지연 시간 수치가 무엇을 측정하는지 이해하기
Shadowrocket 노드 목록의 지연 시간 수치는 주로 연결을 수립할 수 있는지와 한 번의 왕복에 대략 얼마나 걸리는지를 빠르게 판단하는 데 사용됩니다. 1차 선별에는 적합하지만 다운로드 속도, 동영상 버퍼링, 페이지 전체 로딩 시간 또는 장시간 연결의 안정성을 단독으로 보여 주지는 않습니다. 테스트 대상, 현재 네트워크, DNS 확인, 프로토콜 핸드셰이크와 당시 서버 부하가 모두 결과에 영향을 줍니다.
지연 시간은 보통 ms로 표시되며, 수치가 작을수록 해당 테스트가 더 빨리 완료되었다는 뜻입니다. 예를 들어 40 ms는 약 0.04초, 180 ms는 약 0.18초입니다. 하지만 실제 페이지를 여는 과정은 한 번의 왕복만으로 끝나지 않습니다. DNS 조회, TCP 연결 수립, TLS 핸드셰이크, 요청 전송과 리소스 다운로드가 여러 차례 상호작용을 만들 수 있으므로 두 노드의 차이가 수십 ms가 아니고 10여 ms 정도라면 체감상 일관된 차이가 없을 수도 있습니다.
한 번의 최저값보다 더 유용한 정보는 여러 결과가 서로 비슷한지 여부입니다. 노드 A가 세 번의 테스트에서 42, 47, 190 ms를 기록하고 노드 B가 71, 74, 79 ms를 기록했다고 가정해 보겠습니다. A의 최저값이 더 낮지만 변동 폭이 크므로, 실제 상호작용에서는 B가 더 일관된 결과를 내기 쉽습니다. 이 수치는 판단 방법을 보여 주는 예시일 뿐 특정 지역이나 프로토콜의 고정된 성능을 의미하지 않습니다.
정해진 단계로 기존 노드 선별하기
선별할 때는 변수를 통제해야 합니다. 테스트 중에는 같은 기기와 같은 Wi-Fi 또는 셀룰러 네트워크를 유지하고, 가능한 한 비슷한 시간대에 완료하세요. 데이터의 절반은 가정용 Wi-Fi에서, 나머지는 셀룰러 네트워크에서 가져오면 접속 방식·신호 세기·통신사 네트워크 경로의 차이가 섞여 공정하게 비교할 수 없습니다.
Config 출처 확인
Home에서 기존 노드가 사용자가 직접 준비한 Config에서 가져온 것인지 확인합니다. Subscribe를 통해 관리하는 경우 Home 오른쪽 위의 「+」→ Type → Subscribe를 사용하고, 예시 주소는 https://example.com/sub?token=xxxx처럼 입력할 수 있습니다. 저장한 뒤 Config 방식에 따라 업데이트하세요.
로컬 네트워크 고정
진행 중인 대용량 파일 전송을 중지하고, 기기를 같은 Wi-Fi 액세스 포인트 또는 같은 셀룰러 네트워크 상태로 유지하여 테스트 중 연결이 바뀌지 않도록 하세요.
3회 테스트 완료
Home의 노드 목록에서 지연 시간 테스트 기능을 사용해 후보를 최소 3회 연속 테스트하고, 성공·timeout·최저값·최고값을 기록합니다.
뚜렷한 이상 항목 제외
먼저 테스트를 연속으로 완료하지 못하는 후보를 제거한 다음, 변동 폭이 몇 배씩 커지거나 수십 ms에서 수백 ms로 자주 급증하는 항목을 표시합니다.
전환 후 실제 검증
남은 후보를 하나씩 선택해 연결한 뒤 같은 웹페이지, 같은 동영상 또는 같은 통제된 파일로 짧게 검증합니다. 이때 Global Routing을 동시에 변경하지 마세요.
시간대별 재테스트
평소 실제로 사용하는 시간대에 다시 한 번 테스트합니다. 낮에 안정적이라고 해서 저녁에도 안정적인 것은 아니며, 여러 시간대의 결과가 한 번의 최저 지연 시간보다 참고 가치가 높습니다.
기록할 때 복잡한 도구를 사용할 필요는 없습니다. ‘노드 이름, 지역, 프로토콜, 3회 지연 시간, timeout 여부, 웹페이지 첫 로딩, 지속 전송’ 열을 포함한 표 하나면 충분합니다. 지연 시간이 비슷하다면 여러 차례 결과가 안정적이고 실제 작업에서 오류가 적은 항목을 우선 남기세요.
| 후보 | 3회 지연 시간 예시 | 관찰 결과 | 처리 방법 |
|---|---|---|---|
| A | 42 / 47 / 190 ms | 최저값은 낮지만 3회차에 급증 | 재테스트 대상으로 남기고 바로 우선순위로 정하지 않음 |
| B | 71 / 74 / 79 ms | 수치는 조금 높지만 3회 결과가 비슷함 | 실제 사용 검증으로 진행 |
| C | timeout / 128 / timeout | 테스트 성공률이 낮음 | Config를 확인하거나 일시적으로 제외 |
지역 간 거리는 여러 변수 중 하나일 뿐
다른 조건이 비슷하다면 지리적 거리가 짧을수록 전송 경로가 짧을 가능성이 높습니다. 하지만 노드 이름에 표시된 지역만으로 실제 라우팅을 완전히 알 수는 없습니다. 데이터 패킷은 서로 다른 국제 출구, 중계 네트워크와 혼잡 지점을 거칠 수 있으며, 인접한 지역으로 표시된 두 노드도 전혀 다른 경로를 사용할 수 있습니다.
지역을 선택할 때는 먼저 용도가 응답 시간에 민감한지 살펴보세요. 웹 브라우징, 원격 상호작용과 즉시 요청은 왕복 지연 시간과 지터를 더 중요하게 보고, 연속 동영상 시청이나 대용량 파일 전송은 지속 처리량, 패킷 손실 복구와 장시간 연결의 안정성을 더 중요하게 봅니다. 전자는 큰 지연 시간 차이를 체감하기 쉽지만, 후자는 ‘지연 시간은 최저가 아니어도 지속 속도가 안정적인’ 노드에서 더 나은 결과가 나올 수 있습니다.
권장 방법: 상호작용과 지속 전송을 나누어 테스트
상호작용 테스트
- 같은 페이지 묶음을 연속으로 열기
- 첫 응답과 이미지 로딩 관찰
- 캐시로 인한 우연한 결과를 제외하기 위해 세 번 반복
- 연결이 간헐적으로 멈추는지 기록
지속 전송 테스트
- 같은 통제된 리소스로 검증
- 테스트 시간과 파일을 동일하게 유지
- 속도가 크게 출렁이는지 관찰
- 몇 분 동안 연결이 끊기지 않는지 확인
지역 표시는 후보 범위를 좁히는 데 사용하고, 최종 선택은 같은 조건에서의 실제 작업 결과를 기준으로 합니다.
주요 작업이 특정 지역에서 제공되는 콘텐츠에 접근하는 것이라면 서비스 자체의 지역 정책도 고려해야 합니다. 지연 시간이 가장 짧은 지역이 목표 서비스의 접근 조건을 충족한다고 보장할 수 없고, 지역 조건을 충족하는 노드가 최저 지연 시간을 보인다는 보장도 없습니다. 따라서 먼저 필요한 지역을 정한 다음 해당 지역의 기존 후보 사이에서 안정성을 비교하세요.
- 인접 지역: 낮은 지연 시간 후보로 적합하지만 저녁 시간대의 변동도 확인해야 합니다.
- 먼 지역: 기본 지연 시간이 더 높을 수 있으므로 안정성과 실제 용도의 적합성을 중점적으로 살펴야 합니다.
- 같은 지역의 여러 노드: 최저값 하나만 보고 남기지 말고 3회 변동과 실제 성공률을 각각 기록하세요.
- 이름이 비슷한 노드: 이름만으로 하위 회선이 같다고 판단할 수 없으므로 테스트 결과를 따로 기록해야 합니다.
프로토콜 유형은 테스트 결과를 바꿀 수 있습니다
Shadowrocket은 다양한 프로토콜과 전송 조합을 지원합니다. 프로토콜 이름은 캡슐화와 연결 방식의 일부를 설명하지만 속도를 단독으로 결정하지는 않습니다. 같은 프로토콜이라도 서버, 포트와 네트워크 경로가 다르면 성능 차이가 클 수 있고, 서로 다른 프로토콜도 품질이 좋은 같은 경로에서는 일상적인 사용을 모두 충족할 수 있습니다.
Shadowsocks는 구조가 비교적 단순합니다. VMess와 VLESS의 실제 성능은 하위 전송 방식과 암호화 설정의 영향도 받으며, Trojan은 보통 TLS와 함께 사용됩니다. Hysteria2는 UDP 기반 전송 특성에 중점을 두고, WireGuard 역시 UDP 기반 터널 프로토콜입니다. UDP는 일부 네트워크에서 좋은 성능을 보이지만 제한이 있거나 패킷 손실이 뚜렷한 환경에서는 영향을 받을 수 있습니다. HTTPS 트래픽은 TCP 443에서 흔히 사용되고 HTTP/3 및 일부 UDP 방식은 UDP 443을 사용하는 경우가 많지만, 실제 포트는 사용자가 준비한 Config에 따라 달라집니다.
전통적 연결 그룹
- Shadowsocks
- 구조가 단순하며 암호화 방식과 회선에 따라 성능이 달라짐
- VMess
- 실제 전송 설정과 함께 판단해야 함
- VLESS
- 프로토콜 이름 외에 하위 전송 방식도 확인
프로토콜 이름만으로 지연 시간이나 처리량을 추정할 수 없습니다.
TLS 및 UDP 그룹
- Trojan
- TLS와 함께 사용하는 경우가 많아 핸드셰이크와 경로가 초기 연결에 영향을 줌
- Hysteria2
- UDP 기반이므로 현재 네트워크의 UDP 품질을 확인해야 함
- WireGuard
- UDP 기반이며 지속 연결로 안정성을 검증하는 것이 적합함
같은 네트워크에서 각각 테스트하고 네트워크가 다른 상태에서 직접 비교하지 마세요.
프로토콜 선별은 ‘특정 하나가 항상 가장 빠르다’는 식의 고정된 결론으로 판단할 수 없습니다. 사용자가 이미 준비한 Config에서 지역과 부하 조건이 비슷한 후보를 골라 각각 지연 시간과 실제 작업을 테스트하는 것이 올바른 방법입니다. 어떤 UDP 프로토콜이 Wi-Fi에서는 안정적이지만 셀룰러 네트워크에서 자주 실패한다면, 이를 일반적인 결론으로 확대하지 말고 네트워크 환경의 차이로 기록하세요.
테스트 기록 예시
네트워크: 같은 Wi-Fi
Global Routing：Config
후보 A: VLESS, 68 / 72 / 70 ms, 웹페이지 첫 로딩 안정적
후보 B: Trojan, 55 / 160 / 59 ms, 간헐적 멈춤
후보 C: Hysteria2, 83 / 81 / 85 ms, 지속 전송 안정적
결론: 용도에 따라 A와 C를 남기고 B는 다른 시간대에 재테스트합니다.Global Routing이 일치하지 않으면 결과가 왜곡됩니다
노드를 테스트할 때는 Global Routing을 동일하게 유지해야 합니다. Config는 규칙을 순서대로 매칭하고, Proxy는 트래픽을 현재 프록시를 통해 통일하며, Direct는 직접 연결하고, Scene은 설정된 장면에 따라 실행합니다. A를 Config로 테스트한 뒤 B를 Proxy로 바꾸면 두 결과가 서로 다른 처리 경로를 거칠 수 있어 직접 비교할 수 없습니다.
Config
권장현재 Config의 규칙을 위에서 아래로 매칭하므로 일상적인 분기 상태에 더 가깝습니다. 테스트 전에 대상 요청이 실제로 예상한 정책에 매칭되는지 확인해야 합니다.
적합한 경우: 일상적인 선택과 장기 사용 검증
Proxy
트래픽이 현재 프록시를 통해 통일되므로 규칙 차이가 노드 비교에 미치는 간섭을 줄일 수 있습니다.
적합한 경우: 규칙 매칭 문제 점검과 짧은 비교
Direct
트래픽이 직접 연결되므로 현재 프록시 노드의 실제 전송 성능을 판단하는 용도로는 사용하지 않습니다.
적합한 경우: 로컬 네트워크 기준선 설정
Scene
사용자가 설정한 Scene에 따라 처리 방식을 전환하며, 결과는 Scene의 조건과 동작에 따라 달라집니다.
적합한 경우: 고정된 네트워크 환경에서 자동 정책 검증
Config를 사용할 때는 규칙이 테스트 대상을 DIRECT로 할당하지 않는지도 확인해야 합니다. 일반적인 규칙은 Config 순서에 따라 매칭되며, DOMAIN-SUFFIX는 도메인 접미사, GEOIP는 IP의 소속 지역, IP-CIDR은 네트워크 대역을 대상으로 하고 FINAL은 앞에서 매칭되지 않은 트래픽을 처리합니다. 테스트 리소스가 DIRECT에 매칭되면 선택한 노드의 성능을 관찰하는 것이 아닙니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY위 예시에서는 example.com이 먼저 PROXY에 매칭되고, 로컬 네트워크 대역은 DIRECT를 사용하며, 이후 GEOIP가 조건에 맞는 주소를 처리하고 나머지 트래픽은 FINAL로 전달됩니다. 규칙은 위에서 아래로 매칭되므로 더 구체적인 규칙은 이를 덮어쓸 수 있는 포괄적인 규칙보다 앞에 두는 것이 일반적입니다.
지연 시간이 짧아도 원활하지 않을 수 있는 이유
지연 시간 테스트는 연결 경험의 일부만 확인합니다. 실제 접속은 대역폭 상한, 서버 동시 접속 부하, 경로의 패킷 손실, 지터, 재전송, DNS 응답과 대상 서비스의 처리 시간에도 영향을 받습니다. 한 노드는 짧은 테스트에서 빠르게 응답해도 지속 전송 중 혼잡으로 속도가 떨어질 수 있고, 다른 노드는 기본 지연 시간이 더 높아도 처리량이 더 안정적일 수 있습니다.
흔한 현상은 다음과 같습니다. 노드 목록에는 50 ms로 표시되지만 동영상 재생 후 버퍼링이 자주 발생하거나, 지연 시간이 약 100 ms인데도 웹페이지가 계속 안정적으로 로딩될 수 있습니다. 첫 테스트는 정상이어도 저녁에 같은 후보에서 수백 ms의 변동이 나타날 수 있고, Wi-Fi에서는 정상인 UDP 연결이 셀룰러 네트워크로 전환한 뒤 달라질 수도 있습니다. 이런 현상은 계층별 점검이 필요하다는 뜻입니다.
| 현상 | 우선 확인할 항목 | 검증 방법 |
|---|---|---|
| 지연 시간은 낮지만 지속 속도가 불안정함 | 부하, 패킷 손실, 시간대별 혼잡 | 시간대를 바꾸고 같은 리소스로 몇 분간 재테스트 |
| 3회 수치의 차이가 매우 큼 | 로컬 신호, 경로 지터 | 백그라운드 전송을 중지하고 네트워크를 고정한 뒤 5회 재테스트 |
| 일부 앱에서만 이상 발생 | Config 규칙과 DNS | 일시적으로 Proxy로 비교하고 규칙 매칭 확인 |
| Wi-Fi는 정상이나 셀룰러에서 이상 발생 | 접속 네트워크와 UDP 조건 | TCP와 UDP 프로토콜 후보의 성능을 각각 기록 |
| 연결 후 전혀 접속할 수 없음 | Config 유효성, 시스템 VPN 상태 | Home 상태를 확인하고 검증된 후보를 다시 선택 |
DNS도 ‘노드가 느리다’는 착각을 만들 수 있습니다. 도메인 확인 대기는 콘텐츠 전송 전에 발생하므로 확인이 시간 초과되거나 적절하지 않은 경로를 반환하면 페이지 첫 로딩이 느려질 수 있지만 지연 시간 수치는 여전히 정상일 수 있습니다. 점검할 때는 DNS 설정을 그대로 유지하고 먼저 여러 후보를 비교하세요. 모든 후보에서 비슷한 도메인 첫 로딩 문제가 동시에 나타난다면 그때 Config의 DNS 항목을 별도로 확인합니다.
로컬 네트워크도 기본적인 변수입니다. Wi-Fi 신호가 약하거나 액세스 포인트가 혼잡하거나 셀룰러 신호가 계속 전환되거나 백그라운드 동기화가 대역폭을 사용하면 모든 노드가 함께 느려질 수 있습니다. 여러 지역과 여러 프로토콜에서 동시에 지연 시간이 높아졌다면 노드 매개변수를 하나씩 바꾸기보다 먼저 Direct 기준선과 로컬 네트워크를 테스트해야 합니다.
- 한 번의 최저 지연 시간은 1차 선별에만 사용하고 최종 결론으로 삼지 않습니다.
- 한 번의 결과보다 3~5회의 변동이 더 중요합니다.
- 웹페이지, 동영상과 지속 전송은 각각 검증해야 합니다.
- 모든 후보에서 동시에 이상이 발생하면 먼저 로컬 네트워크와 DNS를 확인하세요.
- 특정 네트워크에서 특정 프로토콜만 이상이 있을 때 TCP, UDP와 포트 조건을 확인하세요.
On Demand와 Subscribe 업데이트 후 재확인
Settings → On Demand는 네트워크 조건에 따라 연결 동작을 결정하는 데 사용됩니다. 활성화하면 Wi-Fi 이름, 네트워크 유형 또는 기타 조건에 따라 연결이나 연결 해제가 트리거될 수 있습니다. 테스트 중 네트워크 상태가 바뀌어 On Demand가 작동하면 현재 연결이 다시 수립될 수 있으므로 전후 데이터가 같은 조건에 있지 않게 됩니다.
정식 테스트 전에 Settings → On Demand에서 기존 규칙을 확인하여 현재 Wi-Fi와 셀룰러 네트워크에서 각각 어떤 동작이 트리거되는지 파악할 수 있습니다. 테스트할 때는 조건을 완전히 동일하게 유지하거나, 명확하게 고정된 조건을 임시로 사용하세요. 선택을 마친 뒤 자동 연결을 복원하고 예상대로 작동하는지 확인합니다.
테스트 전 확인
- 진입점
- Settings → On Demand
- 네트워크
- Wi-Fi 또는 셀룰러 상태 고정
- 트리거
- 테스트 중 연결이 다시 수립되지 않는지 확인
- 라우팅
- 같은 Global Routing 유지
조건이 바뀐 뒤 생성된 데이터는 별도로 기록해야 합니다.
업데이트 후 확인
- 진입점
- Home의 기존 Subscribe Config
- 동작
- 기존 Config 방식에 따라 업데이트
- 변경 사항
- 이름, 지역, 프로토콜과 사용 가능 여부 확인
- 재테스트
- 최소 3회의 지연 시간 테스트를 다시 완료
Subscribe 내용이 바뀌면 기존 기록이 새 항목을 그대로 나타내지 못합니다.
Subscribe 업데이트로 노드가 추가·삭제·조정될 수 있고 이름과 하위 매개변수가 바뀔 수도 있습니다. 업데이트 후 이름이 같아 보이더라도 연결 가능 여부와 지연 시간 테스트를 다시 완료해야 합니다. 사용자가 여러 Config를 직접 관리한다면 현재 활성화된 Config가 무엇인지도 확인하여 잘못된 Config에서 노드를 선택하지 않도록 하세요.
Shadowrocket은 Apple 플랫폼의 유료 상용 앱이며, iPhone과 iPad가 주요 사용 기기입니다. App Store 호환성 항목에는 Mac, Apple TV와 Apple Vision이 표시될 수도 있으며, 시스템 요구 사항은 App Store 페이지의 표기를 따릅니다. 정식 이용 경로는 App Store이고 개발자는 Shadow Launch Technology Limited이며 앱 ID는 932747118입니다. 일회성 구매로 제공되는 것은 클라이언트 자체입니다.
반복 가능한 선택 기준 만들기
한 번의 테스트는 그 시점의 상태만 보여 줍니다. 더 신뢰할 수 있는 방법은 후보를 소수만 남기고 ‘주요 지역, 예비 지역, TCP 후보, UDP 후보’로 간단히 메모하는 것입니다. 네트워크 환경이나 사용 장소가 바뀌면 전체 목록을 처음부터 다시 확인하지 말고 해당 후보 그룹에서 재테스트하세요.
두 노드가 3회 지연 시간, 웹페이지 첫 로딩과 지속 전송에서 모두 비슷하다면 몇 ms 차이를 계속 좇을 필요가 없습니다. 이름이 명확하고 성능이 안정적이며 업데이트 후에도 식별하기 쉬운 항목을 선택하면 됩니다. 지나치게 자주 전환하면 DNS 캐시, 연결 재사용과 테스트 시간대가 계속 바뀌어 오히려 비교 품질이 떨어집니다.
- 기기, 네트워크, Global Routing과 테스트 리소스를 고정합니다.
- 기존 후보를 최소 3회 지연 시간 테스트합니다.
- 연속 timeout과 뚜렷하게 불안정한 항목을 제외합니다.
- 필요한 지역과 프로토콜 조건에 따라 범위를 좁힙니다.
- 웹 상호작용과 지속 전송을 각각 재테스트합니다.
- 평소 사용하는 시간대에 다시 확인하고 예비 항목을 기록합니다.
위 과정을 마쳐도 영원히 변하지 않는 ‘가장 빠른 노드’ 하나를 얻는 것은 아닙니다. 현재 네트워크와 현재 용도에 더 적합한 선택 그룹을 얻게 됩니다. 네트워크 경로와 부하는 변할 수 있으므로 사용 경험이 뚜렷하게 달라지면 로컬 네트워크 기준선부터 다시 확인한 뒤 규칙, DNS, 프로토콜과 노드 상태를 차례로 점검해야 합니다.