Shadowrocket 완벽 사용 설명서

01 / 구매

App Store 정품 구매 및 구매 범위

제품을 확인한 뒤 구매하세요

Shadowrocket은 Apple 플랫폼용 유료 클라이언트이며 App Store에서 구매할 수 있습니다. App Store에서 제품 상세 정보를 확인하고, 검색 결과에 표시된 이름만으로 구매를 결정하지 마세요. 개발자가 Shadow Launch Technology Limited인지 확인하고, 아이콘이 사이트 상단의 공식 아이콘과 같은지 살펴본 다음, 제품 링크의 앱 ID가 932747118인지 확인하세요. 이 세 가지를 함께 확인해야 제품을 정확히 식별할 수 있습니다. 비슷한 이름만으로는 충분하지 않습니다. 자세한 방법은 다운로드 안내의 정품 확인을 참고하세요.

App Store 페이지에서 가격, 호환성, 구매 조건도 확인할 수 있습니다. 사용 중인 기기가 호환성 안내에 포함되어 있는지 확인한 뒤 실제 결제 금액을 살펴보세요. 시스템 요구 사항과 구매 가능 여부는 App Store 페이지의 표기를 기준으로 합니다. 이 설명서는 주로 iPhone과 iPad를 대상으로 합니다. Mac / Apple TV에서도 같은 App Store에서 구매할 수 있지만, 모바일 기기의 버튼 위치를 다른 기기의 사용 방법으로 간주하지 마세요.

클라이언트 구매와 연결 정보는 별도로 준비하세요

클라이언트 일회성 구매 ≠ 회선 요금제. 구매하면 클라이언트를 사용할 수 있지만, 사용 가능한 서버가 자동으로 제공되지는 않습니다. 연결하려면 사용자가 보유한 서버 정보나 구독이 필요하며, 관련 정보는 이용 중인 서비스 제공업체에서 확인하세요. 사용 전에 정보 유형, 지원 프로토콜, 유효 여부를 확인해야 합니다. 서버 주소만으로는 연결하기 어려우며 포트, 인증 정보, 전송 설정도 서로 일치해야 합니다.

미국 스토어의 표시 가격을 포함한 각 스토어의 가격은 현지 통화로 표시되며, 최종 금액은 구매 확인 화면을 기준으로 합니다. 클라이언트 가격을 통신 서비스 요금으로 혼동하지 마세요. 이 설명서의 예시가 실제 연결 조건을 의미하지도 않습니다. 이 사이트는 공식 사용 설명서를 제공하며 서버 서비스는 제공하지 않습니다. 서버 만료, 인증 정보 변경, 서버 점검이 발생하면 기존 서비스 정보를 확인하세요. 클라이언트를 다시 구매해도 이러한 문제는 해결되지 않습니다.

설치 후 진행 순서

App Store에서 구매한 뒤 앱 다운로드가 끝날 때까지 기다린 다음 기기의 홈 화면에서 실행하세요. 아이콘이 대기 상태로 남아 있다면 프록시 설정 문제를 확인하기 전에 기기 네트워크, 사용 가능한 저장 공간, App Store 안내를 먼저 살펴보세요. 이 단계에서는 클라이언트가 아직 네트워크 연결을 처리하지 않으므로 설치 문제와 연결 문제를 구분해야 합니다. 구매 및 다운로드 상태는 App Store 정품 다운로드 절차를 참고해 확인할 수 있습니다.

앱을 열기 전에 기존 정보를 정리하고, 단일 서버 링크, 구독 주소, 구성 파일을 구분하세요. 단일 서버 정보는 하나의 연결을 설명하고, 구독은 여러 서버를 가져와 관리하는 데 사용됩니다. 구성 파일에는 주로 규칙과 관련 설정이 포함됩니다. 모두 텍스트나 링크로 전달될 수 있지만 용도는 서로 다릅니다. 복사할 수 있다는 이유만으로 구독 주소를 서버 주소 입력란에 붙여 넣거나 구성 파일을 구독 업데이트에 사용하지 마세요.

구매 내역과 로컬 설정은 별개입니다

기기를 바꿀 때는 App Store에서 구매 내역을 확인하고, 구매 당시 사용한 Apple 계정으로 앱을 찾으세요. 다시 다운로드할 수 있는지와 가족 공유가 적용되는지는 App Store 페이지의 표기를 기준으로 합니다. App Store에 구매 가격이 계속 표시되면 다시 결제하기 전에 계정과 구매 항목을 확인하세요. 앱을 사용할 권리와 클라이언트에 저장된 데이터는 별개입니다. 구매 항목을 복원해도 서버와 규칙이 복원되는 것은 아닙니다.

따라서 기존 기기를 사용할 수 있을 때 설정을 옮길 계획을 세우세요. 사용 중인 구독 이름, 구성 이름, 필요한 설정을 기록하고 원본 정보를 안전하게 보관하세요. 구독 주소와 비밀번호는 민감한 정보이므로 공개 메모나 스크린샷에 포함하지 마세요. 구매 단계는 앱이 정상적으로 열리고 정품 정보를 확인하면 완료됩니다. 다음으로 시스템 네트워크 설정 권한을 허용하고 보유한 정보를 클라이언트로 가져오세요.

02 / 초기 설정

최초 실행 및 시스템 권한

VPN 구성 추가 시스템 안내 이해하기

처음 연결할 때 시스템에서 Shadowrocket이 VPN 구성을 추가하도록 허용할지 물을 수 있습니다. 이는 클라이언트가 기기의 네트워크 요청을 처리하는 데 필요한 시스템 권한입니다. 서버 계정이 아니며 구독이 적용되었다는 증거도 아닙니다. 사용 중인 클라이언트에서 표시된 안내인지 확인한 뒤 시스템 지침에 따라 인증하세요. 권한을 허용하면 해당 네트워크 구성을 만들 수 있을 뿐이며, 원격 서버에 연결할 수 있는지는 이후에 확인해야 합니다.

당시 권한을 거부했다면 클라이언트에서 연결을 다시 시도해 안내가 나타나는지 확인하세요. 필요하면 시스템 설정의 VPN 관련 항목에서 구성 상태를 살펴보세요. 시스템 버전에 따라 메뉴 이름과 위치가 다를 수 있으므로 기기에 표시되는 내용을 기준으로 합니다. 안내 하나를 해결하려고 모든 네트워크 설정을 재설정하지 마세요. 권한이 아직 허용되지 않은 것인지, 권한은 있지만 연결에 실패한 것인지 먼저 구분한 뒤 다음 단계를 진행하세요.

Home에서 작업 대상을 확인하세요

Home에 들어가면 연결 스위치, Global Routing, Connectivity Test, SERVER 목록을 먼저 확인하세요. 연결 스위치는 현재 연결을 시작하거나 중지합니다. Global Routing은 요청의 라우팅 방식을 정하고, SERVER 목록에는 추가한 서버가 표시되며, Connectivity Test는 연결 확인을 돕습니다. 각 영역의 역할은 서로 다릅니다. 목록에 서버가 있어도 연결된 것은 아니며 테스트 결과가 있어도 규칙이 예상대로 적용된다는 뜻은 아닙니다.

SERVER 목록이 비어 있으면 연결 스위치를 반복해서 누르지 말고 다음 장의 가져오기 절차를 진행하세요. 항목이 있다면 이름, 유형, 기본 선택 항목을 확인해 기존 정보를 새로 가져온 정보로 착각하지 않도록 하세요. 화면 배치는 기기 크기와 앱 업데이트에 따라 달라질 수 있습니다. 이 설명서는 고정된 좌표 대신 화면의 기능 이름을 사용합니다. 각 영역의 기본 안내는 최초 실행 및 Home 화면 안내에서 확인할 수 있습니다.

필요한 기능을 사용할 때만 추가 권한 허용

Scan QR Code를 사용할 때 카메라 권한은 QR 코드를 인식하는 데 사용됩니다. 사진에서 QR 코드를 선택하면 시스템에서 사진 접근 권한을 별도로 요청할 수 있습니다. 해당 기능을 사용할 때 필요한 권한만 허용하세요. 서버 정보를 직접 입력하는 것과 QR 코드를 스캔하는 것은 서로 다른 방식입니다. 카메라 권한이 없어도 네트워크 연결 권한이 거부된 것은 아닙니다. 스캔에 실패하면 권한 미허용, 이미지 선명도, 현재 메뉴에서 인식할 수 없는 형식 중 무엇이 원인인지 먼저 구분하세요.

QR 코드와 클립보드 내용에는 인증 정보가 포함될 수 있습니다. 작업 전에 보유한 서비스 정보에서 가져온 내용인지 확인하고, 인식 후에는 가져오기 미리보기를 살펴본 다음 저장하세요. 출처를 모르는 이미지를 바로 가져오거나 QR 코드가 포함된 전체 화면을 공개하지 마세요. 복사 후 가져오기 안내가 나타나지 않으면 정보 유형에 맞는 추가 메뉴를 이용하세요. 안내를 띄우려고 서로 다른 내용을 연달아 복사하면 출처가 혼동될 수 있습니다.

연결 전에 시스템 차원의 간섭을 확인하세요

기기에 다른 VPN 구성이 실행 중이라면 용도와 관리 조건을 먼저 확인하세요. Shadowrocket을 테스트할 때는 네트워크를 처리하는 구성을 한 번에 하나만 명확히 유지해 시스템 상태가 계속 바뀌지 않도록 하세요. 조직에서 관리하는 기기는 구성과 권한이 관리 정책에 제한될 수 있습니다. 변경할 수 없는 스위치나 시스템 제한 안내가 표시되면 클라이언트 구성을 반복해서 만들지 말고 기기 관리 지침을 따르세요.

공용 네트워크는 사용 전에 네트워크 로그인이나 확인 절차를 거쳐야 할 수 있습니다. 먼저 클라이언트 연결을 중지하고 기기의 기본 네트워크로 정상 접속되는지 확인한 뒤 설정을 시작하세요. 시스템 시간도 정확하게 유지해야 합니다. 시간이 맞지 않으면 보안 연결에서 인증서를 판단하는 데 문제가 생길 수 있습니다. 초기 설정이 끝나면 허용한 권한과 아직 사용하지 않은 권한을 기록해 두세요. 이후 문제가 발생했을 때 권한 문제와 서버 문제를 나누어 확인할 수 있습니다.

03 / 가져오기

서버, Subscribe 및 프로토콜 설정값

정보 유형에 맞는 메뉴 선택하기

서버 하나를 추가하려면 Add Server에서 직접 입력하거나 클라이언트가 지원하는 공유 정보를 가져오세요. 지속적으로 업데이트되는 서버 목록은 보통 Subscribe로 관리합니다. 먼저 받은 정보의 종류를 확인한 뒤 해당 메뉴를 선택하세요. 기존 구독 정보는 이용 중인 서비스 제공업체에서 확인할 수 있으며, 전체 주소에 인증 정보가 포함될 수 있습니다. 붙여 넣은 뒤 앞뒤 문자와 줄바꿈을 확인해 메신저에서 덧붙인 문장 부호가 주소에 포함되지 않도록 하세요.

저장한 뒤 Home으로 돌아가 새 항목의 그룹과 이름, 서버 유형이 원본 정보와 일치하는지 확인하세요. 항목이 표시되면 클라이언트가 내용을 읽었다는 뜻일 뿐, 원격 인증 정보가 유효하다는 뜻은 아닙니다. 가져온 결과가 비어 있다면 응답 내용이 클라이언트에서 인식할 수 있는 서버 정보인지, 로그인 페이지나 안내 문구는 아닌지 확인하세요. 업데이트 실패를 감추려고 이름이 같은 구독을 여러 개 만들지 마세요.

프로토콜 설정값을 하나씩 대조하세요

프로토콜에 따라 입력해야 하는 항목이 다릅니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard의 입력 방식을 하나로 통일할 수 없습니다. 먼저 올바른 유형을 선택한 다음 원본 정보에 따라 주소, 포트, 해당 프로토콜의 인증 항목을 입력하세요. 이름은 기기에서 항목을 구분하기 위한 표시일 뿐이며 이름을 바꿔도 서버 연결 문제는 해결되지 않습니다. 포트와 인증 정보는 통신에 직접 사용되므로 공백과 대소문자까지 원본과 일치하는지 확인하세요.

TLS를 사용하는 연결에는 Server Name 같은 항목이 포함될 수 있으며, 입력한 연결 주소와 반드시 일치하지는 않습니다. 특정 전송 방식을 사용한다면 Path, Host 등의 항목도 서버 설정과 맞아야 합니다. 항목 이름만 보고 값을 추측하지 말고, 빠진 정보는 원본 자료에서 확인하세요. 인증서 검증을 끄는 것은 일반적인 해결 방법이 아니며 원격 서버의 신원 확인을 약화합니다. 이름, 시스템 시간, 정보의 만료 여부를 먼저 확인하세요.

구독 업데이트와 직접 수정은 따로 관리하세요

구독을 저장한 뒤 업데이트하고 서버 개수, 이름, 그룹이 어떻게 바뀌는지 확인하세요. 업데이트 실패는 주소를 가져오는 단계, 네트워크 접속, 콘텐츠 해석 단계에서 발생할 수 있으며 모든 서버가 동시에 무효가 된 것은 아닙니다. 현재 사용 가능한 목록을 보존한 뒤 구독 주소 변경 여부, 갱신 확인 필요 여부, 현재 네트워크에서 정보를 가져올 수 있는지 점검하세요. 비교 기준을 잃거나 기존 연결을 끊을 수 있으므로 그룹 전체를 바로 삭제하지 마세요.

구독으로 관리되는 서버는 이후 업데이트 과정에서 다시 생성되거나 덮어써질 수 있습니다. 특정 항목을 임시로 확인하려면 기존 값을 기록하고 구독 항목을 수정할 때 클라이언트가 어떻게 처리하는지 파악하세요. 장기적인 수정은 서버에서 제공한 정확한 정보에 따라야 하며 매번 업데이트 후 수동으로 고치는 방식에 의존하지 마세요. 업데이트에 성공해도 이름 변경, 항목 교체 또는 삭제가 기본 선택에 영향을 줄 수 있으므로 기본 서버를 다시 확인하세요.

직접 추가, QR 코드 스캔, 중복 항목 구분하기

정보가 완전하고 항목별 확인이 필요하면 직접 추가하고, 호환되는 QR 코드가 있으면 Scan QR Code를 이용하세요. QR 코드 스캔은 정보를 입력하는 방식일 뿐 서버의 연결 가능성을 높여 주지는 않습니다. 인식한 뒤 유형과 주요 항목을 확인하고 저장해 테스트하세요. 이름이 비슷한 항목이 여러 개라면 이름만 보고 한꺼번에 삭제하지 말고 프로토콜, 주소, 포트를 비교하세요. 전송 설정이 달라도 비슷한 이름을 쓰는 경우가 있습니다.

가져오기가 끝나면 정보 출처가 명확한 서버 하나를 선택해 처음 테스트하세요. 복잡한 규칙을 추가하거나 여러 프로토콜 항목을 한꺼번에 바꾸지 마세요. 어느 자료에서 가져왔는지, 어떤 항목을 확인했는지, 왜 기본 서버로 선택했는지 설명할 수 있으면 이후 문제를 해결할 준비가 된 것입니다. 구독은 정보를 관리하고 실제 요청의 경로는 Global Routing과 구성이 결정합니다. 다음 장에서 두 기능을 나누어 설명합니다.

04 / 라우팅

Global Routing 및 구성 파일

Config, Proxy, Direct의 차이

Global Routing에서 구성, 프록시, 직결은 각각 Config, Proxy, Direct에 해당합니다. Config는 현재 구성의 규칙에 따라 요청 경로를 결정합니다. Proxy는 프록시 모드로 요청을 처리하고, Direct는 직결 모드로 처리합니다. 모드를 바꾸면 라우팅 판단 방식이 달라질 뿐, 잘못된 인증 정보가 자동으로 수정되지는 않습니다. 문제가 발생하면 먼저 현재 모드를 확인해 규칙에 따른 직결을 서버 장애로 오해하지 않도록 하세요.

문제를 확인할 때 모드를 잠시 바꿔 비교할 수 있지만, 매번 변경 목적을 기록하세요. Proxy에서 정상이고 Config에서 문제가 발생하면 규칙과 정책을 먼저 확인하세요. 두 모드 모두 실패하면 서버 정보, 이름 해석, 현재 네트워크를 점검하세요. Direct에서 특정 대상에 접속되더라도 현재 직결 경로로 해당 대상에 접근할 수 있다는 뜻일 뿐입니다. 대상마다 네트워크 조건이 다르므로 한 페이지의 결과로 전체 연결 상태를 판단할 수 없습니다.

구성 파일의 섹션과 역할

Config 페이지에서는 구성 파일을 관리하고, Global Routing의 Config는 라우팅 모드입니다. 이름은 비슷하지만 조작 대상이 다릅니다. 구성 파일에는 General, Rule, Host 등의 섹션이 들어갈 수 있으며 각각 일반 설정, 규칙, 호스트 매핑 등을 담당합니다. 편집하기 전에 실제 사용 중인 파일인지 확인하고 사용 가능한 사본을 따로 저장하세요. 파일이 목록에 있다고 해서 연결에 사용 중이라는 뜻은 아닙니다.

[General]
bypass-system = true
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

이 예시는 구성을 설명하기 위한 것으로 모든 네트워크에 적합한 완전한 설정은 아닙니다. example.com은 예시 도메인이고 PROXY는 프록시 정책, DIRECT는 직결 정책을 나타냅니다. 실제 프록시 연결 대상은 현재 선택한 서버 또는 정의된 정책에 따라 달라집니다. 검증된 기존 설정은 유지하고 테스트에 필요한 부분만 바꾸세요. 출처가 다른 파일 여러 개를 통째로 붙이면 섹션이 중복되거나 정책 참조가 맞지 않을 수 있습니다.

규칙은 순서대로 적용됩니다

규칙은 일반적으로 순서대로 확인하므로 구체적인 조건을 포괄적인 조건보다 앞에 두는 것이 좋습니다. DOMAIN은 지정한 도메인, DOMAIN-SUFFIX는 도메인 접미사, DOMAIN-KEYWORD는 도메인에 포함된 키워드에 적용됩니다. IP-CIDR과 IP-CIDR6은 주소 범위를 대상으로 하고 GEOIP는 IP 주소 위치 데이터베이스를 기준으로 판단합니다. FINAL은 앞선 규칙에 일치하지 않은 요청을 처리하므로 마지막에 배치하세요. 앞의 포괄적인 규칙이 먼저 적용되면 뒤의 구체적인 규칙은 예상대로 작동하지 않습니다.

도메인 규칙과 주소 규칙은 서로 다른 정보를 사용합니다. 도메인 조건을 적용할 수 있는지는 클라이언트가 실제 요청에서 얻은 정보에 따라 달라집니다. IP 주소 위치 결과가 서비스의 실제 운영 지역을 뜻하는 것도 아닙니다. 이름에 특정 단어가 들어 있다는 이유만으로 관련 요청 전체에 포괄적인 키워드 규칙을 적용하지 마세요. 한 페이지가 여러 도메인에 접속할 수 있으므로 실제 기록을 확인해 필요한 조건만 단계적으로 추가하고 변경 범위를 좁히세요.

저장 결과만 보지 말고 수정 사항을 검증하세요

저장한 뒤 구성을 계속 인식하는지 확인하고 새 요청을 보내 규칙이 적용되는지 살펴보세요. 편집 성공은 텍스트가 저장되었다는 뜻일 뿐입니다. 규칙 적용 여부는 현재 활성화된 파일, 라우팅 모드, 요청에서 확인할 수 있는 정보에 따라 달라집니다. 기존 연결이 같은 경로를 계속 사용할 수 있으므로 새 요청으로 확인하세요. 수정 후 문제가 생기면 조건을 계속 추가하기보다 방금 변경한 규칙을 되돌리는 편이 원인을 찾기 쉽습니다.

구성과 구독은 따로 관리하세요. 구독은 서버 정보를 업데이트하고 구성은 라우팅과 관련 동작을 제어합니다. 규칙에 지정한 정책 이름은 실제로 정의되어 있어야 합니다. 존재하지 않는 이름을 참조하는 문제는 서버를 더 추가해도 해결되지 않습니다. 설정의 의미를 파악하지 못했다면 사용 가능한 사본을 보존하고 주석만 보고 삭제하지 마세요. 구체적인 문제는 문제 해결에서 확인할 수 있습니다. 먼저 현재 파일, 모드, 대상 요청을 기록하세요.

05 / 연결 확인

기본 서버, 연결 및 테스트

변수를 명확히 정해 테스트 시작하기

Home으로 돌아가 SERVER 목록에서 기본 서버를 확인하고 DOT 표시가 가리키는 항목을 살펴보세요. 편집 화면을 여는 것과 기본 서버를 선택하는 것은 다르므로 목록에 표시된 실제 선택 상태를 기준으로 합니다. 처음 테스트할 때는 정보 출처가 명확하고 프로토콜 설정을 확인한 서버를 선택하세요. 연결 상태가 바뀌었을 때 네트워크 변화와 선택 로직 중 무엇이 원인인지 구분하기 어렵지 않도록 복잡한 자동 선택 조건은 일단 사용하지 마세요.

Global Routing을 확인하고 현재 구성 이름을 기록한 뒤 연결 스위치를 켜세요. 시스템에서 VPN 구성을 추가하라는 안내가 나오면 앞서 설명한 절차에 따라 권한을 허용하세요. 상태가 안정될 때까지 기다린 다음 테스트하고 스위치를 빠르게 반복해서 켜고 끄지 마세요. 잦은 재연결은 여러 차례의 기록을 뒤섞고, 시스템 상태가 갱신되기 전에 다음 작업을 시작하게 만들 수 있습니다. 시스템에서 명확한 오류를 표시하면 문구를 기록한 뒤 작업을 중단하고 오류 유형을 구분하세요.

테스트 결과를 단계별로 나누어 확인하세요

Connectivity Test는 연결 상태를 판단하는 데 도움을 줍니다. 구체적인 테스트 방식과 대상은 현재 클라이언트 설정을 기준으로 합니다. 결과는 로컬 네트워크, 서버 응답, 테스트 대상, 프로토콜 조건에 따라 달라집니다. 수치가 낮다고 모든 요청이 정상이라는 뜻은 아니며, 시간이 초과되었다고 인증 정보 오류라고 단정할 수도 없습니다. 먼저 어떤 서버를 어떤 방식으로 테스트했는지 확인한 뒤 실제 접속 결과와 함께 판단하세요.

연결 확인은 세 단계로 진행하세요. 시스템이 연결을 허용하는지, 클라이언트와 선택한 서버가 통신하는지, 대상 요청이 예상한 정책으로 응답하는지 확인합니다. 순서대로 확인하면 스위치가 켜진 것을 성공으로 오해하지 않을 수 있습니다. 연결 후 평소 결과를 판단할 수 있는 대상에 접속하고 적용되어야 할 정책을 확인하세요. 이어서 다른 유형의 요청도 테스트해 특정 페이지의 캐시 때문에 정상처럼 보이는 것은 아닌지 살펴보세요.

네트워크, 설정값, 규칙 순서로 원인을 확인하세요

연결에 실패하면 먼저 클라이언트를 중지하고 기기의 기본 네트워크가 정상인지 확인하세요. 기본 네트워크도 문제가 있다면 네트워크 로그인, 신호, 라우터 문제를 먼저 해결하세요. 기본 네트워크가 정상이라면 기본 서버와 프로토콜 설정을 확인합니다. 주소 이름 해석 실패, 포트 연결 불가, 인증 실패, 인증서 확인 실패는 서로 다른 단계의 문제입니다. 안내 문구와 기록을 바탕으로 구분하고 모두 ‘노드 시간 초과’로 묶어 설명하지 마세요.

그다음 임시 모드로 비교해 규칙의 영향을 분리하세요. 프록시 모드에서 같은 요청은 성공하지만 Config 모드에서는 실패한다면 현재 파일과 적용된 정책을 확인하세요. 두 모드 모두 실패한다면 서버 정보와 네트워크 조건을 계속 살펴보세요. 매번 설정값 하나 또는 모드 하나만 바꾸고 같은 요청을 다시 보내세요. 서버 시간 초과 문제 해결 순서도 참고할 수 있습니다. 문제를 확인하는 동안 모든 조건을 한꺼번에 바꾸지 마세요.

연결은 되지만 일부 콘텐츠가 비정상인 경우

웹페이지 본문은 열리지만 이미지, 로그인, 기타 리소스가 실패한다면 여러 요청을 나누어 살펴봐야 합니다. 한 페이지에서 여러 도메인에 연결하고 각각 다른 규칙이 적용될 수 있으며 연결을 계속 유지하는 경우도 있습니다. 실패한 리소스의 도메인, 적용 정책, 오류가 발생한 단계를 기록한 뒤 조정하세요. 페이지 주소 하나를 규칙에 추가하면 모든 리소스의 경로가 바뀐다고 생각하거나 모든 요청에 장기간 같은 정책을 적용하지 마세요.

특정 앱에서만 문제가 발생한다면 해당 앱과 브라우저가 같은 대상에 요청을 보내는지 비교한 뒤 캐시, 이름 해석, 연결 재사용의 영향을 살펴보세요. 필요하면 해당 앱을 완전히 종료했다가 다시 시도하고 조정 전후 결과를 기록하세요. 보안 연결 오류가 발생하면 시스템 시간과 서버 이름부터 확인하세요. 한 번 테스트를 성공시키려고 인증 확인을 건너뛰지 마세요. 연결 보안을 위해 필요한 경계를 잃을 수 있습니다.

테스트를 마치고 일상 설정으로 되돌리기

테스트가 끝나면 임시로 사용한 라우팅 모드를 평소 설정으로 되돌리고 테스트 과정에서 기본 서버가 바뀌지 않았는지 확인하세요. 사용 가능한 구성, 테스트 네트워크, 주요 결과를 기록하되 계속 바뀌는 순간 수치까지 적을 필요는 없습니다. 유효한 기록은 단순히 ‘연결 정상’이라고 쓰는 대신 어떤 조건에서 어떤 요청이 어떤 정책으로 완료되었는지 설명해야 합니다. 그래야 다음에 문제가 발생했을 때 비교할 기준이 생깁니다.

최초 연결을 마쳤다면 첫 연결 및 Connectivity Test 안내에서 놓친 항목이 없는지 확인하세요. 계속 문제를 해결해야 한다면 서버 유형, 모드, 오류 문구, 재현 절차처럼 필요한 정보만 기록하세요. 비밀번호, 구독 주소, 개인 키, 전체 공유 정보는 공개하지 마세요. 이후 Data에서 요청을 확인할 때도 이처럼 단계를 나누어 판단하세요.

06 / 관찰

Data 트래픽 및 요청 확인

통계는 현상으로 보고 결론으로 단정하지 마세요

Data에서는 클라이언트가 제공하는 트래픽 및 연결 관련 정보를 확인할 수 있습니다. 표시 항목은 실제 화면을 기준으로 합니다. 트래픽이 늘었다는 것은 해당 통계 범위에서 데이터가 처리되었다는 뜻일 뿐 요청이 완료되었거나 모든 트래픽이 같은 원격 서버를 거쳤다는 뜻은 아닙니다. 반대로 눈에 띄는 변화가 없더라도 캐시, 통계 갱신 주기, 요청 미발생 때문일 수 있습니다. 무엇을 관찰하는지 먼저 정한 뒤 수치를 해석하고 전체 사용량을 개별 요청의 결과로 대신하지 마세요.

데이터를 확인하기 전에 연결이 실행 중인지, 기본 서버가 올바른지, 테스트 중에 백그라운드 작업이 많이 실행되지는 않는지 확인하세요. 사진을 동기화하면서 웹페이지 하나를 점검하면 전체 트래픽을 특정 작업과 연결하기 어렵습니다. 관찰 시간을 짧게 하고 재현 가능한 요청을 한 번 실행한 다음 새 기록을 확인하세요. 그러면 페이지 열기, 요청 발생, 정책 적용을 시간 순서에 따라 연결할 수 있습니다.

대상 요청에서 적용 정책까지 확인하기

클라이언트가 요청 기록이나 연결 세부 정보를 제공한다면 재현 시간과 일치하는 대상을 찾고 확인 가능한 도메인, 주소, 정책, 오류 정보를 살펴보세요. 프로토콜과 요청 유형에 따라 표시되는 정보가 다를 수 있으므로 모든 기록에 전체 URL이나 콘텐츠가 있다고 가정하지 마세요. 기록 하나로 앱 전체 동작을 추측하기보다 요청이 어디로 향했는지, 어떤 규칙에 일치했는지, 어느 단계에서 멈췄는지 먼저 확인하세요.

Config 모드에서는 예상한 정책과 실제 정책이 일치하는지 특히 주의해서 확인하세요. PROXY를 예상했는데 DIRECT가 적용되었다면 앞선 규칙과 현재 활성화된 파일을 살펴보세요. 정책이 예상대로 적용됐는데도 요청이 실패한다면 해당 서버와 대상에 접속할 수 있는지 확인하세요. 규칙이 적용됐다는 사실만으로 원격 서비스가 정상 응답한다는 것을 증명할 수는 없습니다. 정책 단계와 전송 단계를 구분하면 불필요한 수정을 줄일 수 있습니다.

이름 해석, 연결 수립, 데이터 전송을 구분하세요

도메인 요청은 일반적으로 먼저 이름을 해석한 뒤 선택한 주소에 연결하고, 이후 앱 데이터를 주고받습니다. 이름 해석에 실패했을 때 비밀번호를 바꾸는 것은 도움이 되지 않습니다. 연결 주소가 정해졌지만 연결을 수립하지 못했다면 네트워크, 포트, 서버를 확인하세요. 연결 수립 후 보안 핸드셰이크 문제가 발생하면 인증서 이름, 시간, 관련 설정을 살펴보세요. 단계마다 오류 문구가 다를 수 있으므로 문맥에 맞춰 읽고 원문을 보존하세요.

하나의 도메인에 여러 주소가 표시되어도 곧바로 설정이 잘못되었다고 판단하지 마세요. 서비스는 네트워크, 시간, 지역에 따라 서로 다른 결과를 반환할 수 있어 주소 규칙의 적용 결과도 달라집니다. 같은 요청을 반복해 현상을 확인한 다음 직결 경로와 프록시 경로의 이름 해석 조건을 비교하세요. 한 번 표시된 주소를 검증 없이 Host에 고정하지 마세요. 고정한 주소가 금방 유효하지 않게 되어 새로운 문제를 일으킬 수 있습니다.

통계 범위와 서비스 측 기록은 다를 수 있습니다

클라이언트, 기기 시스템, 서비스 측 통계는 집계 범위가 서로 다를 수 있습니다. 각각 송수신 방향, 연결 오버헤드, 집계 기간이 다를 수 있으므로 모든 수치가 완전히 일치할 필요는 없습니다. 사용량에 문제가 있는지 확인하려면 관찰 기간을 맞추고 눈에 띄는 백그라운드 작업을 중지한 뒤 변화 추이를 살펴보세요. 짧은 시간 동안의 차이만으로 과금 오류라고 단정하거나 전체 사용량을 모든 앱의 완전한 기록으로 간주하지 마세요.

통계를 초기화하기 전에 비교에 필요한 결과를 저장하고 어떤 항목이 초기화되는지 확인하세요. 로컬 화면의 수치를 지워도 서비스 측 사용 기록이 바뀌거나 연결 문제가 해결되는 것은 아닙니다. 문제를 해결할 때는 통계를 계속 초기화하기보다 특정 요청에서 상태가 어떻게 달라졌는지 확인하는 편이 유용합니다. 클라이언트에 통계 화면이 여러 개라면 각 화면의 설명과 집계 범위를 확인한 뒤 목적에 맞게 사용하세요.

기록을 공유하기 전에 필요한 정보만 남기세요

요청 기록에는 접속 대상, 서버 주소, 기타 식별 정보가 포함될 수 있습니다. 내보내거나 스크린샷을 찍기 전에 표시된 내용을 확인하고 문제 해결에 필요한 부분만 남기세요. 구독 링크의 매개변수, 서버 비밀번호, UUID, 개인 키는 기록과 함께 공개하지 마세요. QR 코드 하나를 공유해도 전체 연결 정보가 노출될 수 있습니다. 이름만 가렸다고 민감한 정보가 모두 보호되는 것은 아닙니다.

문제 해결 자료에는 재현 절차, 발생 단계, 사용 프로토콜과 정책을 적고 인증 정보가 없는 오류 원문을 인용하세요. 자신이 비교할 수 있도록 전체 기록은 로컬에 보관하고 외부에는 필요한 부분만 공유하세요. 서버 설정이 원인으로 확인됐다면 기존 자료를 확인하고 관련 없는 요청 기록은 더 수집하지 마세요. 관찰이 끝나면 평소 모드로 돌아가고 테스트용으로 추가한 기록 설정을 장시간 유지하지 마세요.

07 / 설정

Settings 주요 항목 및 변경 범위

설정이 적용되는 범위를 먼저 확인하세요

Settings의 모든 항목이 같은 기능을 제어하는 것은 아닙니다. 일부는 클라이언트 전체 동작에 영향을 주고, 일부는 연결 과정이나 화면 표시 및 테스트 설정에만 적용됩니다. 서버 편집 화면의 설정값은 해당 항목 하나에만 적용될 수도 있습니다. 변경하기 전에 적용 범위를 구분하고 구성 파일에서 관련 동작을 정의하는지 확인하세요. 특정 서버의 전송 설정을 전체 네트워크 설정으로 간주하거나 서로 다른 위치의 같은 이름 옵션이 같은 우선순위를 가진다고 가정하지 마세요.

이 장에서는 용도에 따라 설정을 설명하며 모든 기기에 같은 항목이 표시되는 것은 아닙니다. 화면 이름과 사용 가능한 옵션은 현재 클라이언트를 기준으로 합니다. 의미를 알기 어려운 옵션은 현재 값과 해결하려는 문제를 먼저 기록한 뒤 관련 안내를 확인하세요. 연결이 이미 정상이라면 고급 옵션을 여러 개 켜기보다 기본 동작을 유지하는 편이 관리하기 쉽습니다. 목표가 분명하지 않은 변경은 검증하기 어렵고 문제가 생겼을 때 되돌리기도 어렵습니다.

수동 연결을 확인한 뒤 On Demand 설정하기

On Demand는 조건에 따라 연결 관련 동작을 실행하는 기능입니다. 먼저 수동 연결과 대상 요청을 확인하세요. 그렇지 않으면 해결되지 않은 문제가 자동 실행으로 더 파악하기 어려워질 수 있습니다. 관련 설정에서 활성화 상태와 적용 조건을 주의 깊게 확인한 다음 실제 사용 환경에서 전환 테스트를 진행하세요. ‘켜짐’ 상태라고 모든 상황에서 연결이 유지된다는 뜻은 아닙니다. 실제 동작은 시스템, 네트워크 조건, 구성에 따라 달라집니다.

On Demand를 테스트할 때는 예상대로 실행되는 경우와 실행되지 않아야 하는 경우를 각각 확인하세요. 예를 들어 네트워크를 바꾼 뒤 시스템 상태가 안정될 때까지 기다리고 연결 상태와 요청 결과를 살펴보세요. 연결이 반복해서 시작된다면 On Demand를 잠시 끄고 수동으로 기본 연결이 정상인지 확인한 다음 실행 조건을 점검하세요. 관리 대상 기기의 제한도 확인해 클라이언트 조건과 시스템 관리 정책이 복잡하게 얽히지 않도록 하세요.

재현 가능한 문제가 있을 때만 DNS를 조정하세요

DNS는 도메인을 IP 주소로 변환하며 일부 규칙 판단에도 영향을 줄 수 있습니다. 이름 해석 단계에 문제가 있거나 결과가 예상과 다르다는 점을 확인한 뒤 관련 설정을 조정하세요. 기존 해석 방식, 테스트 도메인, 오류 현상을 기록하고 한 번에 한 항목만 바꾸세요. 모든 연결 문제의 첫 단계로 DNS를 바꾸지 마세요. 잘못된 포트, 만료된 인증 정보, 일치하지 않는 전송 설정은 이름 해석 방식을 바꿔도 해결되지 않습니다.

구성 예시에서 dns-server = system은 시스템 관련 이름 해석 설정을 사용한다는 뜻이며 모든 네트워크에 적합하다는 의미는 아닙니다. 다른 DNS 방식을 사용한다면 접속 경로와 적용 조건을 이해하고, 아직 연결되지 않은 경로에 DNS 서비스가 의존하는 상황을 피하세요. 변경한 뒤 새 요청을 보내고 캐시의 영향을 고려해 결과를 비교하세요. 테스트가 끝나면 최종적으로 사용할 방식을 명확히 정하고 임시 변경을 쌓아 두지 마세요.

테스트, 시간 초과, 네트워크 전환

Connectivity Test 관련 설정은 테스트 방식에 영향을 줍니다. 테스트 방식을 바꾸면 결과를 서로 비교하기 어려워질 수 있습니다. 서버 두 대를 비교할 때는 같은 방식과 대상을 사용하세요. 시간 초과 설정도 적절한 범위로 정해야 합니다. 너무 짧으면 정상이나 응답이 느린 경우도 실패로 처리하고, 너무 길면 문제를 늦게 확인하게 됩니다. 결과를 보기 좋게 만드는 데 집중하기보다 현재 네트워크 특성을 파악한 뒤 조정하세요.

네트워크를 전환한 뒤 잠시 문제가 발생하면 시스템 전환이 끝날 때까지 기다린 다음 새 요청을 보내세요. 기존 연결은 새 경로에서 계속 작동하지 않을 수 있으며 앱이 자동으로 재시도하기도 합니다. 네트워크를 바꿀 때만 문제가 생긴다면 고정된 네트워크에서 계속 실패하는 경우와 구분해 기록하세요. 모든 설정을 한꺼번에 재설정하기보다 On Demand, 기본 서버, 새 네트워크 상태를 확인하는 편이 효과적이고 기존의 안정적인 설정도 보존할 수 있습니다.

보안 옵션은 목적을 분명히 하고 사용하세요

인증서, HTTPS, 요청 처리와 관련된 고급 옵션은 용도와 적용 범위를 먼저 이해해야 합니다. 일반적인 서버 가져오기와 최초 연결에 추가 인증서 작업까지 무조건 적용할 필요는 없습니다. 특정 기능이 필요하다면 구성을 별도로 저장하고 해당 안내에 따라 검증하세요. 테스트 조건을 평소 사용하는 구성에 섞지 마세요. 원격 서버의 신원 확인 요건을 낮추는 변경을 하기 전에 기존 설정을 다시 점검하고 일반적인 문제 해결 지름길로 사용하지 마세요.

설정 변경 기록은 기존 값, 변경 이유, 테스트 결과, 유지 여부만 적어도 충분합니다. 이전의 정상 상태로 돌아갈 수 있도록 기록하는 것이 기억에 의존하는 것보다 안전합니다. 변경해도 문제가 해결되지 않으면 수정한 상태를 계속 유지하지 말고 바로 되돌리세요. 마지막으로 현재 구성, Global Routing, 기본 서버를 확인하고 실제로 접속해 관찰 가능한 결과로 설정 조정을 마무리하세요.

08 / 유지 관리

업데이트, 백업 및 일상적인 문제 해결

되돌릴 수 있는 작업 상태 유지하기

유지 관리의 핵심은 자주 바꾸는 것이 아니라 현재 연결이 정상인 이유를 파악하는 것입니다. 검증이 끝난 구성을 보존하고 기본 서버, Global Routing, 필요한 전역 설정을 기록하세요. 변경 전에 사본을 별도로 저장하고 용도에 따라 파일 이름을 구분하세요. 알아보기 어려운 번호를 계속 붙일 필요는 없습니다. 관련된 항목만 한 번에 수정하고 검증한 뒤 평소 사용할 구성으로 교체하세요. 그러면 문제가 발생했을 때 최근 변경 사항부터 되돌릴 수 있습니다.

백업에는 직접 수정한 규칙과 필요한 설정이 포함되어야 하지만 민감한 정보는 별도로 보호해야 합니다. 서버 비밀번호, 개인 키, 구독 주소를 일반 문서와 함께 공개된 위치에 저장하지 마세요. 클라이언트에서 제공하는 내보내기, 백업, 복원 기능을 사용할 때는 어떤 데이터가 포함되는지 확인한 뒤 직접 관리할 수 있는 위치에 저장하세요. 백업을 만들었다고 복원할 수 있다고 단정할 수는 없습니다. 필요하다면 사본이 열리는지 확인하고 원본 정보도 보관하세요.

앱 업데이트와 구독 업데이트를 구분하세요

앱은 App Store에서 업데이트하고 구독은 클라이언트 안에서 서버 정보를 관리합니다. 두 작업은 서로 독립적입니다. 앱을 업데이트해도 만료된 인증 정보가 갱신되지 않으며, 구독을 업데이트해도 App Store 구매 상태는 바뀌지 않습니다. 앱 업데이트 전 중요한 구성을 저장하고 App Store의 안내를 읽으세요. 업데이트가 끝나면 현재 파일, 기본 서버, 연결 상태를 확인하세요. 앱이 열리는 것만으로 확인을 마치지 마세요.

구독 업데이트 후에는 그룹, 항목, 기본 선택을 주의 깊게 확인하세요. 서버에서 특정 항목을 제거했다면 기존 선택을 다시 확인해야 할 수 있습니다. 이름이 같아도 내부 설정이 바뀌지 않았다는 보장은 없으므로 문제가 생기면 기존 정보와 대조하세요. 업데이트에 실패하면 사용 가능한 정보를 보존하고 가져오기 실패인지 내용 해석 실패인지 확인한 뒤 다시 시도할지 결정하세요. 앱과 구독을 동시에 업데이트한 다음 연결 문제를 확인하면 어느 쪽의 변화가 영향을 미쳤는지 파악하기 어렵습니다.

기기 변경 및 재설치는 세 단계로 복원하세요

복원할 때는 앱을 먼저 가져오고 서버 정보를 복원한 다음 구성과 설정을 복원하세요. 첫 번째 단계에서는 App Store 구매 내역을 확인합니다. 두 번째 단계에서는 안전하게 보관한 구독 또는 서버 정보를 사용합니다. 세 번째 단계에서는 백업을 가져와 적용 범위를 확인합니다. 순서를 지키면 앱은 설치했지만 서버가 없거나 서버는 가져왔지만 규칙이 비어 있는 상황을 방지할 수 있습니다.

새 기기에서 시스템 권한과 호환성을 다시 확인하고 시스템 요구 사항은 App Store 페이지의 표기를 기준으로 하세요. 기존 기기의 권한이 모두 이전된다고 가정하지 말고 구매 내역 복원을 로컬 데이터 복원으로 혼동하지 마세요. 복원 후 서버 하나와 대상 하나로 먼저 확인한 다음 On Demand와 기타 추가 조건을 설정하세요. 이전 기기는 이전 및 확인이 끝날 때까지 사용 가능한 상태로 유지하면 가장 직접적인 비교 기준이 됩니다.

전체 초기화보다 문제 발생 단계를 좁혀 가세요

문제가 발생하면 연결을 시작할 수 없는지, 테스트 시간이 초과되는지, 일부 요청만 실패하는지, 규칙이 예상과 다르게 적용되는지 구체적으로 기록하세요. 그런 다음 네트워크 전환, 구독 업데이트, 규칙 편집, 시스템 설정 변경 등 최근에 달라진 점을 확인합니다. 변화와 직접 관련된 부분부터 살펴보세요. 전체 초기화는 원인 파악에 필요한 단서와 사용 가능한 설정을 함께 지울 수 있습니다. 영향을 정확히 이해하고 백업을 준비한 경우에만 범위를 넓혀 복원하세요.

추가 안내가 필요하면 구매 및 복원 문제는 다운로드 안내, 기본 사용법은 빠른 시작, 자주 발생하는 문제는 문제 해결을 확인하세요. 해당 기능을 정확히 찾을 수 있도록 화면에 표시된 용어와 오류 문구를 그대로 기록하세요. 서버 정보가 충분하지 않다면 기존 서비스 자료를 확인하세요. 규칙을 계속 바꿔도 빠진 프로토콜 설정을 보완할 수는 없습니다.

필요한 기록만으로 일상 점검하기

유지 관리 기록에는 네 가지 질문에 답하면 됩니다. 현재 사용하는 구성 파일, 기본 서버, 최근 변경 사항, 검증 결과입니다. 스크린샷을 많이 남기는 것보다 문제가 발생한 네트워크와 재현 절차를 기록하는 편이 유용합니다. 문제가 해결되면 실제 원인과 되돌리는 방법을 적고 공개된 사본에서 인증 정보를 삭제하세요. 다음에 비슷한 현상이 발생하면 지난번 변경 사항을 그대로 반복하기 전에 원인이 같은지 확인할 수 있습니다.

마지막으로 실제 사용 상태를 확인하세요. 현재 모드가 예상과 맞는지, 대상 요청이 완료되는지, 규칙이 적용된 이유를 설명할 수 있는지, 임시 테스트 옵션을 복구했는지 점검합니다. 연결이 정상이라면 설정을 더 추가할 필요가 없습니다. 용도를 알 수 없는 파일을 쌓기보다 명확하고 검증 가능하며 되돌릴 수 있는 구성을 유지하는 편이 관리하기 쉽습니다. 이 설명서의 8단계를 반복해 현재 문제의 계층을 찾고 입력 정보를 확인한 뒤 같은 요청으로 결과를 검증하세요.