구독 Subscribe
보유한 구독을 가져오세요. 구독은 서버 항목을 업데이트하며 전체 분기 설정을 자동으로 대체하지는 않습니다.
CONFIGURATION / MATCH / POLICY
먼저 연결 정보를 확인한 다음 요청이 어떻게 처리될지 정하세요. Subscribe는 기존 서버 정보를 관리하고, Config는 분기 설정을 저장하며, Rule은 요청에 적용할 정책을 결정합니다. 각 항목의 역할은 서로 다르며, 가져오기에 성공했다고 연결까지 확인된 것은 아닙니다.
보유한 구독을 가져오세요. 구독은 서버 항목을 업데이트하며 전체 분기 설정을 자동으로 대체하지는 않습니다.
조건을 위에서부터 확인합니다. 더 구체적인 예외가 앞에 있는 일반 규칙에 가려지지 않도록 순서를 정하세요.
PROXY는 프록시를 거치고, DIRECT는 직접 연결하며, REJECT는 요청을 거부합니다. 정책이 대상에 연결할 수 있음을 보장하지는 않습니다.
서버 정보는 “어떤 프로토콜을 사용하고, 어느 주소에 연결하며, 어떻게 인증하는가”에 답합니다. 설정 파일은 “어떤 요청은 프록시를 사용하고, 어떤 요청은 직접 연결하며, 도메인을 어떻게 해석하는가”를 정합니다. 기존 구독은 보통 서버 항목을 일괄 관리하는 데 사용되며, 파일 이름만으로 규칙이 포함됐는지 판단할 수 없습니다. 가져온 뒤에는 Home에서 선택된 서버와 Config에서 현재 활성화된 설정을 각각 확인하세요.
오른쪽 위의 규칙 작업 공간은 텍스트 매칭을 설명하기 위한 예시이며 그대로 적용할 수 있는 설정이 아닙니다. 예를 들어 example을 포함하는 포괄적인 조건이 앞에 있으면 뒤에 있는 ad.example.com 예외 규칙이 적용되지 않을 수 있습니다. 실제로 조정할 때는 먼저 원하는 정책을 정하고 조건의 범위와 순서를 확인하세요. 파일 끝에 규칙을 계속 추가하는 것만으로 해결하려 하지 마세요.
FUNCTION INDEX
아래 항목을 선택해 설명을 확인하세요. 코드는 일부 문법이나 필드를 확인하기 위한 예시이며, 예약된 도메인과 문서용 주소를 사용하므로 실제 연결 정보가 아닙니다.
Home에서 Global Routing을 확인하세요. Config 모드는 현재 설정에 따라 요청을 분기하고, Proxy 모드는 일반적인 요청을 선택한 프록시로 전달하며, Direct 모드는 직접 연결합니다. 도메인이나 주소에 따라 요청 경로를 나누려면 Config를 선택하고, Config에서 활성화된 파일을 확인하세요. 모드를 바꿔도 서버 인증 정보가 채워지거나 서버를 사용할 수 있게 되는 것은 아닙니다. 문제를 확인할 때는 한 번에 조건 하나만 바꾸고 같은 대상의 결과를 비교하세요. 서버, 규칙, DNS를 동시에 바꾸면 원인을 파악하기 어렵습니다. 아래 예시는 해당 규칙 설정을 사용할 때 분기 의도를 나타냅니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT
On Demand는 Settings에 있으며, 설정한 조건에 따라 시스템이 연결을 시작하도록 합니다. 서버를 사용할 수 있게 해주는 기능은 아닙니다. 처음 설정하기 전에는 먼저 수동으로 연결해 실제 접속을 확인한 뒤 적용할 네트워크 조건을 점검하세요. 활성화한 뒤 수동으로 연결을 끊었는데 다시 연결된다면 설정을 계속 삭제하기보다 On Demand를 먼저 확인하세요. 네트워크별 동작은 시스템 상태에도 영향을 받으므로 모든 요청이 반드시 프록시를 거친다고 볼 수 없습니다. 일시 중지하려면 관련 조건을 끈 다음 연결을 해제하세요. 아래는 문제 해결 시 확인할 순서이며 가져오기용 설정이 아닙니다.
Settings → On Demand
수동 연결 확인 → 트리거 조건 점검 → 네트워크를 바꿔 재확인
기존 구독 링크를 사용하면 서버 정보를 일괄 가져오거나 업데이트할 수 있습니다. 보통 Home의 추가 메뉴에서 시작합니다. 가져오기 전 클립보드에 링크 전체가 복사됐는지 확인하고, 가져온 뒤에는 그룹과 항목을 확인한 다음 하나를 선택해 테스트하세요. 업데이트 과정에서 주소, 인증 매개변수 또는 항목 이름이 바뀔 수 있으므로 구독으로 관리되는 항목에 장기간 수동 변경 사항을 섞지 않는 것이 좋습니다. 구독 링크에 접근 자격 정보가 포함될 수 있으니 도움을 요청할 때는 링크 전체와 인증 필드를 가리세요. 이 사이트는 기존 정보의 가져오기와 관리 방법만 안내하며 구독을 제공하지 않습니다. 아래 예시는 예약된 도메인과 가상 값을 사용해 링크 형식만 보여줍니다.
https://example.com/sub?token=xxxx
Config의 설정 파일은 General, Rule, Host, URL Rewrite 등의 구간으로 구성될 수 있으며, 각 구간은 서로 다른 동작을 담당합니다. 편집기에 파일 내용이 보인다는 것은 파일이 있다는 뜻일 뿐입니다. 실제 적용 여부는 현재 활성화된 항목과 Global Routing 모드를 확인해야 합니다. 수정하기 전에는 복구할 수 있는 사본을 보관하고 한 번에 한 곳씩 바꿔 테스트하면 오류를 찾기 쉽습니다. 구독 업데이트와 설정 전환은 서로 다른 작업이므로 서버 항목이 늘거나 줄었다고 규칙이 업데이트됐다고 볼 수 없습니다. 아래에는 유효한 규칙 두 줄만 표시하며, 실제 요구 사항에 맞춘 전체 설정을 대신하지 않습니다.
[Rule]
DOMAIN,example.com,DIRECT
FINAL,PROXY
Rule은 조건을 위에서 아래로 확인하고, 일치하는 행의 정책을 적용합니다. DOMAIN은 전체 도메인과 일치하고, DOMAIN-SUFFIX는 도메인 접미사와 일치하며, IP-CIDR은 주소 범위와 일치합니다. 이름이 비슷하다고 서로 바꿔 쓸 수 있는 키워드가 아닙니다. 예외를 처리할 때는 범위가 좁은 조건을 이를 덮을 수 있는 포괄적인 조건보다 앞에 두세요. 마지막의 FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 문제를 진단할 때는 실제 대상, 일치한 행, 최종 정책을 함께 확인하세요. 파일에 도메인이 적혀 있는지만 봐서는 안 됩니다. 아래 예시는 특정 도메인 예외를 먼저 두고 나머지 예시 도메인 요청을 거부합니다.
[Rule]
DOMAIN,keep.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
FINAL,PROXY
DNS는 도메인을 주소로 변환하며 연결 과정의 한 단계입니다. 도메인으로는 열리지 않지만 주소로 접속된다면 이름 해석 단계를 확인할 필요가 있다는 뜻일 수 있지만, 특정 DNS 서버의 문제라고 단정할 수는 없습니다. 현재 Config의 DNS 설정을 확인한 뒤 실제 해석 결과, 캐시, 요청 경로를 함께 살펴보세요. 출처를 알 수 없는 주소를 한꺼번에 많이 입력하지 말고, 이유를 설명할 수 있는 설정만 남긴 뒤 같은 도메인으로 다시 테스트하세요. 설정을 바꾼 뒤에는 요청을 새로 보내 결과가 달라졌는지 확인하세요. 아래는 General에 쓰이는 일부 설정 문법입니다. system은 시스템의 DNS 설정을 사용한다는 뜻이며 모든 네트워크에 적합한 고정 설정은 아닙니다.
[General]
dns-server = system
URL Rewrite는 조건에 맞는 URL에 지정된 작업을 적용합니다. 프록시 또는 직접 연결을 선택하는 Rule과는 역할이 다릅니다. 편집하기 전에 어떤 요청 범위를 대상으로 할지 정하고 표현식이 지나치게 넓지 않은지 확인하세요. 암호화된 요청에서 확인할 수 있는 범위는 연결 방식과 관련 설정에 따라 다릅니다. 재작성 규칙 하나로 모든 앱 콘텐츠를 처리할 수 있는 것은 아닙니다. 접속 문제가 생기면 설정 전체를 삭제하기보다 새로 추가한 재작성 규칙을 비활성화하고 다시 테스트하세요. 아래는 예약된 도메인으로 이동시키는 문법 예시입니다. 이 페이지를 읽기 위해 인증서를 설치할 필요는 없으며, 실제 사이트에 일반적으로 적용할 재작성 방법도 아닙니다.
[URL Rewrite]
^http://example\.com/ https://example.com/ 302
Host는 지정한 도메인에 로컬 매핑을 설정하며, 대상 주소를 알고 있을 때 DNS 응답 차이를 확인하는 데 사용할 수 있습니다. 서버 구독이 아니며 프로토콜 인증을 대신하거나 대상 서비스 자체를 바꾸지도 않습니다. 매핑을 추가한 뒤에는 요청이 실제로 해당 주소를 사용하는지 확인하세요. 대상 서비스가 도메인과 인증서의 일치를 요구할 수도 있습니다. 오래된 주소를 계속 남겨두면 일부 접속에 문제가 생길 수 있으므로 각 매핑에는 분명한 목적과 되돌릴 방법이 있어야 합니다. 아래는 문서용 주소를 사용하므로 실제 접속에 사용할 수 없습니다. 고정 매핑이 필요한 대상이 없다면 설정을 완성하기 위해 이 구간을 추가하지 않아도 됩니다.
[Host]
example.com = 192.0.2.10
Add Server에서 Type을 선택한 다음 기존 서버 정보를 기준으로 Host, Port 및 해당 프로토콜의 인증 필드를 입력하세요. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard의 매개변수는 서로 바꿔 적용할 수 없습니다. 일부 유형은 전송 방식, TLS, 서버 이름도 확인해야 합니다. 프로토콜 이름만으로 속도나 배터리 소모를 판단하지 마세요. 네트워크 품질, 전송 설정, 서버 측 기능도 결과에 영향을 줍니다. 공유 링크를 가져오면 수동 입력 오류를 줄일 수 있지만, 가져온 뒤에도 해석된 필드를 확인해야 합니다. 아래는 필드 확인 목록이며 실제 값은 보유한 서버 정보를 사용하세요.
Type → Host → Port
인증 필드 → 전송 설정 → TLS(해당하는 경우)
Home의 Connectivity Test와 Settings의 Diagnostics는 연결 상태를 파악하는 데 도움이 되지만, 한 번의 테스트 결과가 모든 대상이나 프로토콜 동작을 나타내지는 않습니다. 현재 네트워크, 서버, Global Routing을 기록한 뒤 같은 대상을 다시 테스트해 주소 해석, 서버 연결, 인증, 규칙 경로를 구분하세요. 지연 시간은 선택한 테스트 방식의 왕복 또는 연결 과정을 나타내며 지속적인 처리량과 같지 않습니다. 진단 정보를 공유하기 전에 구독 링크, 인증 필드, 개인 접속 기록을 삭제하세요. 아래는 순서대로 확인할 항목이며 미리 정해진 진단 결과가 아닙니다.
현재 네트워크 → DNS → 서버 연결 가능 여부
인증 및 전송 설정 → 일치한 규칙 → 실제 대상 접속
Data의 트래픽 정보는 클라이언트 통계 범위 내 연결 활동을 보여줍니다. 수치를 확인하기 전에 통계 기간과 초기화 여부, 현재 요청에 적용된 정책을 살펴보세요. 업로드 및 다운로드 수치를 서비스 제공자의 청구 내역과 동일하게 볼 수는 없습니다. 프로토콜 오버헤드, 집계 방식, 시간 범위에 따라 차이가 날 수 있습니다. 트래픽이 비정상적으로 늘었다면 누적 수치만으로 원인을 단정하지 말고 백그라운드 동기화나 지속적인 전송이 있는지 확인한 뒤 연결 기록을 살펴보세요. 전후 차이를 비교할 때는 같은 시간대에 측정해 서로 다른 기간의 데이터를 섞지 마세요. 아래는 확인할 항목입니다.
Data
통계 기간 / 업로드 / 다운로드 / 현재 연결 및 정책
iCloud 관련 동기화나 가져오기 기능을 사용하기 전에 기기의 로그인 상태, 시스템 권한, 클라이언트에서 사용할 수 있는 옵션을 확인하세요. 앱 구매 기록, 서버 정보, 설정 파일, 연결 권한은 서로 다른 데이터입니다. 앱을 다시 다운로드해도 모든 설정이 자동으로 복구되는 것은 아닙니다. 중요한 설정은 복구 가능한 사본으로 따로 보관하고, 인증 정보가 포함될 수 있으므로 안전하게 관리하세요. 다른 기기에서 동기화를 마친 뒤에도 현재 설정과 서버 선택을 확인하고 시스템 안내에 따라 연결을 설정해야 합니다. 아래에서는 복구 시 확인할 두 가지 항목을 구분합니다. 구체적인 동기화 범위는 클라이언트의 현재 화면을 기준으로 확인하세요.
App Store → 구매 항목 확인
iCloud / 클라이언트 가져오기 → 설정 및 서버 정보 확인
FIRST CONNECTION
시작하기 전에 보유한 구독 링크나 서버 정보를 준비하세요. 앱 구매로 해결되는 것은 클라이언트를 확보하는 일이며, 실제 연결에는 유효한 서버 매개변수가 필요합니다. 처음에는 변경을 최소화하고 연결 하나가 작동하는지 확인한 뒤 규칙과 자동 연결 조건을 차례로 추가하세요.
Home에서 추가 메뉴를 여세요. 기존 공유 링크가 있다면 먼저 전체를 복사하고 가져온 결과를 확인하세요. 직접 입력할 때는 Type을 선택한 다음 Host, Port, 인증 필드를 차례로 확인합니다. QR 코드는 보유한 정보에서 가져오고, 가져온 뒤 해석된 내용을 점검하세요.
구독을 가져온 뒤에는 그룹이 표시되는지, 항목이 빠짐없이 들어왔는지 확인한 다음 서버 하나를 선택하세요. 매개변수를 확인하기도 전에 여러 고급 설정을 동시에 켜지 마세요. 가져오기에 실패하면 링크가 줄바꿈으로 잘리지 않았는지, 내용이 비어 있지 않은지 먼저 확인한 다음 형식이 지원되는지 살펴보세요.
규칙 분기가 필요하면 Config를 선택하고 Config에서 현재 활성화된 파일을 확인하세요. Proxy와 Direct는 요청 경로를 비교할 때 사용할 수 있지만 연결 문제를 자동으로 해결하는 스위치는 아닙니다. 모드를 바꾼 뒤에는 같은 대상에 요청을 다시 보내 결과를 비교하세요.
한 웹사이트는 접속되지만 다른 곳은 실패한다면 두 요청에 서로 다른 정책이 적용되는지 먼저 확인하세요. 의도한 서버와 설정을 사용 중인지 확인해야 이후 DNS, 인증, 규칙 문제를 점검할 수 있습니다. Home에 항목이 보인다는 이유만으로 설정이 적용됐다고 판단하지 마세요.
연결을 시작할 때 시스템 안내에 따라 VPN 설정 추가를 확인하고 허용하세요. 이 권한은 시스템 네트워크 연결만 설정합니다. 이미 보유한 구독의 서버 인증은 별도로 확인하세요. 완료되면 Connectivity Test를 실행한 다음 실제로 접속할 대상을 열어 결과가 예상과 맞는지 확인하세요.
시스템에 연결됨으로 표시되어도 연결 설정이 작동 중이라는 뜻일 뿐, 모든 대상에 접속할 수 있다는 의미는 아닙니다. 실패하면 현재 네트워크와 모드를 기록하고 서버 매개변수를 확인한 다음 요청 정책을 살펴보세요. 한 번에 한 항목만 바꾸고 변경 전후를 비교할 수 있도록 기록을 남기세요.
첫 연결이 예상대로 되지 않으면 원래 정보를 보관하고 구독 또는 서버 매개변수를 잘못 입력하지 않았는지 확인하세요. 다음으로 클라이언트에서 대상 항목을 선택했는지, Global Routing이 의도에 맞는지, Config가 활성화됐는지 살펴보세요. 기본 항목을 확인한 뒤 이름 해석과 구체적인 요청 기록을 점검합니다. 테스트 시간 초과만으로 문제가 규칙 때문인지 서버 때문인지 판단할 수는 없습니다.
네트워크를 바꿀 때는 같은 대상을 다시 테스트하고 일부 요청에서만 문제가 생기는지 기록하세요. 이를 통해 환경 변화와 설정 변경의 영향을 구분할 수 있습니다. 다른 사람에게 도움을 요청할 때는 모드, 오류 증상, 이미 시도한 단계를 알려주면 됩니다. 구독 주소 전체, 비밀번호, 기타 인증 필드는 공개하지 마세요.
DEVICES & APP STORE
앱을 받을 수 있는 유일한 경로는 App Store입니다. 두 기기의 구매 적용 범위, 시스템 요구 사항 및 호환성은 App Store 페이지를 기준으로 확인하세요. 이미 구매한 기기에서도 현재 계정과 연결 설정을 각각 점검해야 합니다.
먼저 App Store 제품 정보를 확인한 다음 구매하고 설치하세요. 처음 연결을 설정할 때는 시스템 안내에 따라 권한을 허용하고, 이후 Home으로 돌아가 기존 서버를 선택합니다. 네트워크나 설정을 바꾼 뒤에는 실제 접속을 다시 확인하세요.
스토어 검색 결과가 나오지 않으면 계정의 국가 또는 지역과 제품 페이지에 표시된 정보를 먼저 확인하세요. 검색 노출 문제와 클라이언트 연결 오류를 같은 문제로 취급하지 마세요.
iPhone 설치 단계 보기 →같은 Apple ID로 구매 항목을 확인하세요. 구매 적용 범위는 App Store 페이지를 기준으로 합니다. iPad에서도 설정 가져오기, 현재 서버, Global Routing을 확인해야 하며 다른 기기의 연결 상태를 이 기기의 확인 결과로 대신할 수 없습니다.
넓은 화면에서는 설정 파일을 읽기 쉽지만 규칙 매칭 방식은 화면 크기에 따라 달라지지 않습니다. 기존 설정을 복구한 뒤에는 내용이 온전한지 확인하고 연결을 시작해 요청 경로를 점검하세요.
iPad 설치 단계 보기 →Mac / Apple TV에서도 같은 App Store에서 이용할 수 있으며, 호환성은 스토어 페이지를 기준으로 확인하세요.
설치 단계 보기 →PRODUCT IDENTITY & PURCHASE
이 사이트는 Shadowrocket의 공식 웹사이트이자 공식 가이드입니다. 구매할 때는 Shadowrocket 제품명, 개발자, 공식 아이콘, 앱 ID를 함께 확인하세요. 검색 결과의 제목만으로 판단해서는 안 됩니다.
아이콘, 개발자, 제품 페이지 주소의 ID를 비교하세요. 세 정보가 서로 일치해야 합니다.
App Store 제품 페이지를 열어 먼저 앱 이름과 아이콘을 확인한 다음 개발자가 Shadow Launch Technology Limited인지 살펴보세요. 제품 페이지 주소의 id932747118은 앱 ID에 해당합니다. 아이콘이 비슷하다는 것만으로는 충분하지 않습니다. 이름이 같거나 비슷해도 이 두 가지 텍스트 정보를 대신할 수 없습니다.
검색 결과에서 제품 페이지로 이동했더라도 상세 페이지에서 다시 확인하세요. 이 사이트의 공식 아이콘은 외관 비교에 참고할 수 있으며, 최종 가격과 호환성, 구매 정보는 App Store 페이지를 기준으로 확인해야 합니다. 클라이언트 업데이트도 App Store에서 관리합니다. 변경 사항을 확인하려면 튜토리얼의 화면 모양을 근거로 추측하지 말고 스토어의 업데이트 기록을 읽으세요.
Shadowrocket은 유료 앱이며 미국 스토어 기준 가격은 2.99달러, 일회성 구매입니다. 각 스토어에서는 현지 통화로 표시되며 최종 가격은 구매 확인 화면을 기준으로 합니다. 일회성 구매는 클라이언트 앱을 이용할 권한에 해당하며 서버 연결, 이용 기간 또는 접속 품질을 보장하지 않습니다.
클라이언트 일회성 구매 ≠ 연결 서비스 요금제. 이 사이트는 노드나 구독을 제공하거나 판매하거나 추천하지 않습니다. 연결 기능을 사용하려면 보유한 구독 또는 서버 정보를 준비하세요. 기존 서비스의 유효 기간, 주소 변경, 인증 정보는 기존 서비스 계약에 따라 관리되며 클라이언트를 다시 설치해도 자동으로 복구되거나 연장되지 않습니다.
App Store는 계정의 국가 또는 지역에 따라 제품을 표시하며 검색 결과와 구매 가능 여부가 달라질 수 있습니다. Shadowrocket이 검색되지 않으면 계정 설정에서 현재 스토어를 확인한 다음 이 페이지의 제품 링크를 열어 안내를 살펴보세요. 검색 결과가 없다고 앱 이름이 변경됐거나 기존 구매 기록이 무효가 된 것은 아닙니다.
계정을 확인할 때는 기기에 로그인한 계정과 App Store 구매에 사용하는 계정을 구분하세요. 지역, 결제 수단, 구매 제한은 계정 설정과 스토어 안내를 기준으로 확인해야 합니다. 클라이언트 연결 문제를 해결하려고 구매 설정을 반복해서 바꾸지 마세요. 스토어에서 앱을 받는 과정과 네트워크 연결은 별개이며, 앱 구매로 기존 서버의 인증 오류를 해결할 수 없습니다.
기기를 바꾸거나 앱을 다시 설치할 때는 원래 구매에 사용한 계정으로 App Store의 구매 항목을 확인한 다음 Shadowrocket 제품 페이지를 살펴보세요. iPhone과 iPad의 구매 적용 범위, 기타 호환 기기, 가족 공유 조건은 App Store 페이지를 기준으로 확인해야 합니다. 다시 결제하라는 안내가 나오면 바로 재구매하지 말고 계정과 구매 기록을 먼저 확인하세요.
앱 복구와 설정 복구는 따로 진행해야 합니다. 구매 기록으로 앱을 다시 받을 수 있지만 서버 정보와 설정 파일은 직접 보관한 백업이나 기존 동기화 데이터에서 복구해야 합니다. 복구가 끝나면 현재 서버, Config, Global Routing을 다시 확인하고 기기의 시스템 안내에 따라 연결을 설정하세요. 다른 기기의 권한 및 테스트 결과는 현재 기기의 점검을 대신할 수 없습니다.
안정적으로 사용하기 시작하면 서버 정보, 분기 설정, 자동 연결 조건을 나눠 관리하세요. 구독을 업데이트한 뒤에는 항목 변경을 확인하고, 규칙을 수정한 뒤에는 매칭 결과를 확인하며, On Demand를 조정한 뒤에는 네트워크를 바꿔 테스트하세요. 세 가지 작업을 분리하면 문제가 생겼을 때 원인을 찾기 쉽습니다. 중요한 설정은 복구할 수 있는 사본으로 보관하고 인증 정보도 안전하게 관리하세요.
Shadowrocket 연결 문제를 진단할 때는 현재 네트워크, 선택한 항목, Global Routing, 구체적인 오류 증상을 기록하세요. “스위치가 켜져 있다”는 화면만 공유하는 것보다 문제 파악에 도움이 됩니다. 로그를 공유하기 전에 구독 주소 전체, 서버 비밀번호, 개인 접속 기록이 포함됐는지 확인하세요. 진단의 목적은 재현 가능한 실패 단계를 찾는 것이지, 특정 테스트 수치를 얻기 위해 모든 설정을 계속 바꾸는 것이 아닙니다.
가져오기는 정보를 클라이언트에 저장하는 단계일 뿐입니다. Home에서 사용할 항목을 선택하고 Global Routing과 현재 설정을 확인한 다음 연결을 시작해야 합니다. 항목이 존재하는지, 테스트가 통과했는지, 실제 대상에 접속할 수 있는지는 서로 다른 결과이므로 차례로 확인하세요. 가져오기 및 연결 단계 보기 →
지연 시간 테스트는 특정 방식의 연결 시간이나 왕복 시간을 보여줄 뿐 처리량, 패킷 손실, 지속적인 연결, 대상 서비스 응답까지 나타내지는 않습니다. 같은 서버와 모드를 유지한 채 실제 대상에 다시 접속해 네트워크 변화에 따라 문제가 달라지는지 확인하세요. 연결 확인 및 문제 해결 방법 보기 →
Global Routing이 Config로 설정되어 있는지, 수정한 파일이 활성화됐는지 먼저 확인한 다음 규칙 순서와 실제 요청 도메인을 살펴보세요. 새 규칙 앞에 있는 포괄적인 조건이 요청을 먼저 처리하면 새 규칙이 정책을 결정하지 못합니다. 확인한 뒤 요청을 다시 보내 결과를 비교하세요. 규칙 설정 안내 보기 →
구매 기록과 설정 데이터는 각각 확인해야 합니다. 먼저 App Store에서 구매한 앱을 다시 받은 다음 직접 보관한 백업, 기존 구독 또는 클라이언트가 지원하는 동기화 데이터에서 설정을 복구하세요. 복구가 끝난 뒤에도 정보가 온전한지 확인하고 다시 테스트해야 합니다. 구매 항목 복구 안내 보기 →
TECHNICAL NOTES
시작 단계 외에도 궁금한 내용에 따라 더 읽어보세요. 아래 노트에서는 규칙의 거부 범위, 스토어 표시와 계정 지역의 관계, 지연 시간 테스트로 알 수 있는 내용을 각각 설명합니다. 먼저 문제가 구매, 설정, 연결 중 어느 단계에 해당하는지 확인하세요.
매칭 조건과 거부 정책을 바탕으로 도메인 단위 요청 처리 범위와 같은 도메인의 콘텐츠, 앱 내부 요청 등 도메인 규칙만으로 구분하기 어려운 경우를 설명합니다.
계정이 속한 스토어를 순서대로 확인하고 검색 결과, 제품 페이지 표시, 구매 항목을 구분합니다. 구매 문제는 스토어 정보를 먼저 확인하고 클라이언트 연결 문제와 혼동하지 마세요.
보유한 서버 항목을 기준으로 테스트 방식, 지역, 프로토콜 설정이 결과에 미치는 영향을 설명하고 조건을 동일하게 유지해 비교하는 방법을 안내합니다. 서비스 추천은 포함하지 않습니다.