Settings 설정 항목 참고

01 / Scope

설정 범위와 현재 값 확인

Settings, Config 및 시스템 권한 구분

Settings만으로 연결 동작이 결정되는 것은 아닙니다. 확인할 항목은 세 가지 범위로 나눌 수 있습니다. 앱 범위에서는 테스트 방식, 로그 및 일부 공통 설정을 저장합니다. Config에는 규칙과 구성 파일 관련 매개변수가 들어 있습니다. 시스템 범위에서는 VPN 구성 권한, 네트워크 접근 조건 및 iCloud 사용 가능 여부를 결정합니다. 서버 항목에는 별도의 주소, 포트 및 프로토콜 정보가 있습니다. 문제가 발생하면 먼저 어느 범위에 속하는지 판단한 뒤 해당 설정을 확인하세요. Settings를 변경해도 서버 주소의 오타는 수정되지 않으며, Config를 전환해도 시스템 팝업에서 권한을 승인하는 절차를 대신할 수 없습니다.

설정이 그대로인 것처럼 보여도 실제 요청 경로는 달라졌을 수 있습니다. 예를 들어 Home에서 선택한 서버가 바뀌거나, Global Routing이 Config에서 Proxy로 전환되거나, Wi-Fi에서 셀룰러 네트워크로 바뀌면 테스트 조건도 달라집니다. 각 항목을 살펴보기 전에 현재 네트워크, 선택한 서버, Global Routing 모드 및 현재 Config 이름을 기록하세요. 이 네 가지가 결과를 비교하기 위한 기본 정보입니다. 기록 없이 “어제는 됐는데 오늘은 안 돼요”라는 증상만으로는 설정, 네트워크, 원격 상태 중 무엇이 바뀌었는지 구분하기 어렵습니다.

기본값, 현재 값, 권장값은 서로 다릅니다

기본값은 특정 설치 환경에서 아직 변경하지 않은 초기 설정입니다. 현재 값은 지금 화면에 표시되거나 구성 파일에 저장된 값이며, 적용 값은 실제 요청에 최종 반영된 동작입니다. 백업이나 동기화 데이터를 복원하면 현재 값이 이전 기기의 값일 수 있으므로 초기 기본값과 같지 않을 수 있습니다. 변경 가능한 항목은 현재 정상적으로 작동하는 값을 유지하는 것을 우선 권장합니다. 이 가이드를 참고하기 위해 앱 전체를 재설정하지 마세요. 필드에 자동, 빈 값 또는 상속이 표시되어도 즉시 꺼짐으로 해석하지 말고 Config나 시스템이 값을 결정한다는 뜻인지 확인하세요.

되돌릴 수 있는 변경 기록 만들기

변경 전에 현재 Config 사본을 저장하고, 비공개 기록에 항목 이름, 이전 값, 새 값, 변경 이유 및 검증 결과를 적어 두세요. Config 사본에는 서버 인증 정보가 포함될 수 있으므로 공개 메모에 보관하지 마세요. 예를 들어 테스트 방식만 먼저 변경하고 DNS는 함께 바꾸지 않는 식으로 한 번에 변수 하나만 수정합니다. 변경 내용을 저장한 뒤 필요한 경우 연결이 끊겨도 되는 시간에 연결을 끊었다가 다시 연결하고, 같은 대상에 동일한 요청을 실행하세요. 개선되지 않으면 변경을 더 쌓지 말고 원래 값으로 되돌리세요. 이렇게 하면 원인과 결과를 명확하게 추적할 수 있습니다.

검증할 때는 ‘설정이 저장됨’과 ‘설정이 실제로 사용됨’을 구분하세요. 이전 화면으로 돌아갈 수 있다는 것은 편집이 끝났다는 뜻일 뿐, 기존 연결이 다시 설정되었다는 뜻은 아닙니다. 브라우저에서 페이지가 열려도 캐시된 결과일 수 있습니다. 중요한 항목을 변경한 뒤에는 새 요청을 보내고 Log에서 해당 시각의 기록을 확인하세요. 시스템 권한과 관련된 경우 앱의 스위치 색상만 보지 말고 시스템의 VPN 상태를 확인하세요. 기본값 확인만을 위해 앱을 삭제할 필요는 없습니다. 삭제하면 로컬 구성과 기록에 영향을 줄 수 있으며, 이전에 정상 작동하던 설정 조합이 복원된다는 보장도 없습니다.

특정 대상에서만 문제가 발생하면 해당 대상의 규칙부터 확인하세요. 모든 대상이 실패한다면 서버, 네트워크 및 이름 확인을 점검합니다. 구매 페이지나 앱의 정품 여부가 불확실하다면 먼저 정품 확인 3가지 항목을 살펴보세요. 설정 참고 정보는 구매 범위를 바꾸지 않으며, 사용자가 보유한 서버 정보가 올바른지 확인하는 절차를 대신하지 않습니다. 자주 발생하는 증상에 대한 간단한 답변은 질문과 답변에서 확인할 수 있습니다. 먼저 문제 유형을 파악한 뒤 이 페이지에서 관련 항목을 살펴보세요.

02 / DNS

DNS 해석과 규칙의 관계

대상 도메인과 서버 도메인을 구분하세요

DNS는 도메인을 연결에 필요한 주소로 변환합니다. 프록시 요청에는 적어도 두 가지 이름 확인 과정이 포함될 수 있습니다. 먼저 기기가 서버 도메인에 해당하는 주소를 찾아야 하고, 이후 요청 대상 도메인도 해당 경로에서 해석되어야 합니다. 첫 번째 과정이 실패하면 프록시 연결 자체가 설정되지 않을 수 있습니다. 두 번째 과정이 실패하면 서버 테스트에는 응답이 있지만 특정 웹사이트는 열리지 않는 현상이 나타날 수 있습니다. 따라서 ‘DNS 변경’은 모든 연결 오류에 적용되는 해결책이 아닙니다. 어떤 도메인의 해석이 실패했는지, 연결 설정 전후 어느 시점에 문제가 발생했는지 먼저 확인하세요.

Settings의 DNS 관련 옵션은 현재 Config의 내용과 함께 살펴봐야 합니다. 사용 중인 구성에 DNS 지정이나 관련 동작 매개변수가 있다면 한 화면만 보고 최종 해석 방식을 판단하지 마세요. 기본 상태는 현재 화면과 적용 중인 구성을 기준으로 확인해야 합니다. 이 가이드에서는 모든 네트워크에 적합한 공용 주소를 지정하지 않습니다. 현재 사용 가능한 설정을 바탕으로 시작하고 Config에 명시된 설정을 유지하세요. Log에 해석 오류, 비정상적인 주소 반환 또는 예상과 다른 해석 경로가 나타나는 경우에만 해당 항목을 점검합니다.

입력 형식을 확인하고 주소와 프로토콜을 섞지 마세요

DNS 필드에는 주소, 서버 목록 또는 앱이 지원하는 특정 형식을 입력할 수 있습니다. 정확한 형식은 필드 설명과 실제 선택 항목을 기준으로 확인하세요. 일반 주소와 프로토콜이 포함된 해석 주소는 서로 바꿔 쓸 수 있는 문자열이 아닙니다. 입력 전에 프로토콜 접두사가 필요한지, 불필요한 공백이 있는지, 구분자가 올바른지, 현재 네트워크에서 해당 해석 서비스에 연결할 수 있는지 확인하세요. 웹페이지 주소를 DNS 주소로 입력하지 말고, 암호화 전송 표시가 있다는 이유만으로 현재 네트워크에서 사용할 수 있다고 가정하지 마세요. 해석 서비스에도 네트워크 연결이 필요합니다.

서버 주소가 도메인인 경우 이름 확인의 의존 관계도 고려해야 합니다. 해석 엔드포인트에 접근하려면 아직 설정되지 않은 프록시가 필요하고, 프록시를 설정하려면 그 엔드포인트가 서버 도메인을 해석해야 한다면 초기 연결 단계에서 순환 의존성이 생길 수 있습니다. 이런 문제는 먼저 기존 DNS 설정을 복원하고, 연결을 설정하기 전에 서버 도메인이 올바르게 해석되는지 확인한 뒤 대상 도메인의 해석 경로를 별도로 검증하세요. 한 번 조회한 주소를 서버 항목에 영구 입력하지 마세요. 원격 주소는 바뀔 수 있으며 일부 프로토콜은 올바른 이름 검증에도 의존합니다.

DNS와 규칙 매칭 순서의 영향

도메인 규칙과 주소 규칙은 서로 다른 대상을 확인합니다. DOMAIN-SUFFIX는 도메인 접미사를 직접 대상으로 매칭할 수 있지만, GEOIP와 IP-CIDR 등의 규칙은 주소와 관련이 있습니다. 주소 규칙의 매칭 여부를 판단하는 과정에서는 해석 결과가 필요할 수 있습니다. 명확한 도메인 하나에 특정 정책을 적용하려면 DNS를 여러 항목 변경하기보다 구체적인 도메인 규칙을 더 넓은 주소 조건보다 앞에 배치하는 것이 일반적입니다. 규칙은 순서대로 처리되므로 앞선 규칙이 이미 적용되면 뒤에 있는 예시는 같은 요청의 정책을 선택하지 않습니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

위 코드는 규칙 간 관계를 보여주는 예시일 뿐, 완전한 연결 구성은 아닙니다. example.com과 example.org는 설명용 도메인이며 PROXY와 DIRECT는 정책 키워드입니다. 사용 전에 현재 구성이 해당 정책을 지원하는지 확인하고 Global Routing을 Config 모드로 설정해 검증하세요. 여기에는 DNS 서버가 지정되어 있지 않으므로 몇 줄의 예시만으로 DNS 요청이 어떤 경로를 사용하는지 판단할 수 없습니다. 매칭 대상을 더 자세히 알아보려면 규칙 문법과 매칭 순서 안내를 참고하세요.

DNS 문제 검증 및 되돌리기

동일한 네트워크와 서버를 사용해 문제가 안정적으로 재현되는 대상을 요청하고 시각을 기록하세요. 그런 다음 Log에 해석 시간 초과, 이름 확인 실패 또는 이후 연결 실패가 있는지 확인합니다. 이름 확인에는 성공했지만 연결이 시간 초과되면 주소 접근성 쪽을 살펴봐야 합니다. 이름 확인에 실패했다면 해석 엔드포인트와 네트워크 조건을 확인하세요. DNS를 변경해도 이전 캐시가 즉시 사라지지 않을 수 있으므로 새 연결로 재검사하고 캐시된 페이지를 성공의 증거로 삼지 마세요. 명확한 개선이 없다면 원래 값으로 복원하고 테스트 기록을 보관하세요. 여러 엔드포인트를 연달아 바꾸지 마세요.

03 / On Demand

On Demand 자동 연결 조건

자동 실행은 연결 성공을 보장하지 않습니다

On Demand는 설정된 조건에 따라 시스템에 VPN 연결을 요청하는 기능입니다. ‘언제 연결을 시도할지’를 정하는 기능이지, 서버가 유효한지 확인하거나 모든 앱의 트래픽이 항상 연결된다는 것을 보장하지 않습니다. 활성화하기 전에 먼저 수동으로 연결해 Home의 기본 서버, Global Routing 및 Config가 의도한 상태인지 확인하고 Connectivity Test와 실제 대상 접속으로 검증하세요. 수동 연결이 성공하지 않았다면 자동 실행은 같은 실패를 반복할 뿐이며 주소나 인증 오류를 해결하지 못합니다.

스위치의 초기 상태, 사용 가능한 조건 및 기존 규칙은 현재 화면을 기준으로 확인하세요. 특히 이전 기기에서 복원했다면 과거 조건이 함께 적용되었는지 점검해야 합니다. 권장 시작점은 수동 제어를 유지하고 연결이 안정된 뒤 명확한 상황에 맞춰 자동 연결을 설정하는 것입니다. 자동 연결이 필요하다면 조건을 하나씩 읽고 네트워크 환경, 요청 시점 또는 그 밖의 설정 범위 중 무엇을 대상으로 하는지 확인하세요. 특정 조건 이름이 모든 네트워크에 적용된다고 해석하거나 목록의 뒤쪽 항목이 앞쪽 동작을 반드시 덮어쓴다고 가정하지 마세요.

네트워크 전환별 테스트 계획 세우기

자동 연결은 Wi-Fi와 셀룰러 네트워크 간 전환, 특정 액세스 포인트 이탈 또는 기기 깨우기 후에 다르게 동작할 수 있습니다. 테스트 전에 원하는 결과를 구체적으로 적으세요. 예를 들어 지정된 네트워크에서는 현재 상태를 유지하고, 허용된 다른 네트워크에서는 연결을 요청하는 식입니다. 한 번에 조건 하나만 바꾸고 시스템이 네트워크 변경을 마칠 때까지 기다린 뒤 시스템 VPN 상태와 앱 기록을 확인하세요. 전환 직후 잠시 연결이 끊겼다고 해서 규칙이 잘못된 것은 아닙니다. 실행 시점과 이후 상태를 함께 살펴보세요. 네트워크를 계속 켰다 끄면 여러 상태 변경이 겹쳐 원인을 찾기 어려워집니다.

꺼도 다시 연결되는 이유

수동으로 연결을 끊은 뒤 시스템이 다시 연결을 시도한다면 먼저 On Demand가 켜져 있는지, 현재 조건이 계속 충족되는지 확인하세요. 수동 연결 해제와 자동 규칙은 서로 다른 제어 방식이므로 수동으로 연결을 끊어도 자동 규칙이 취소되는 것은 아닙니다. 자동 동작을 일시 중지하려면 앱에서 관련 자동 연결 설정을 먼저 끄고 연결을 해제한 다음 시스템 상태를 확인하세요. 동작이 반복된다면 시스템에서 실제로 사용 중인 VPN 구성을 확인하세요. 다른 구성에 남아 있는 동작을 현재 편집 중인 화면의 설정으로 잘못 판단하지 않도록 주의해야 합니다.

기기에 여러 VPN 구성 프로파일이 저장되어 있을 수 있으므로 앱 화면의 선택 항목과 시스템에서 실제로 사용 중인 구성이 서로 일치하는지 확인하세요. 모든 구성을 바로 삭제하지 말고 이름, 출처 및 현재 상태부터 살펴보세요. 시스템 권한 팝업에서 앱의 구성을 허용해도 모든 자동 연결 조건이 이미 설정되었다는 뜻은 아닙니다. 조직에서 관리하는 기기는 일부 네트워크나 VPN 동작이 시스템 관리 정책의 영향을 받을 수 있습니다. 앱 내 스위치로 시스템 요구 사항을 대신할 수 없으므로 기기 관리 규칙에 따라 처리하세요.

로그인 네트워크와 복구 방법

먼저 네트워크 로그인 페이지를 열어야 하는 Wi-Fi는 아직 완전한 인터넷 접근이 불가능할 수 있습니다. 네트워크 인증을 완료하기 전에는 자동 연결이 올바르게 실행되어도 서버에 연결되지 않을 수 있습니다. 이런 경우 자동 연결 시도를 잠시 중지하고 시스템이 허용하는 방식으로 네트워크 로그인을 완료한 다음 기존 조건을 복원해 다시 테스트하세요. 아직 네트워크에 접속하지 못한 상태에서 서버 프로토콜 매개변수를 계속 바꾸지 마세요. 문제는 프록시 연결 전에 발생했으며 프로토콜 변경은 변수만 늘릴 수 있습니다.

자동 규칙을 만든 뒤에는 정상적인 진입 조건, 이탈 조건 및 수동 일시 중지의 세 가지 상황을 검증하고 기존 설정을 저장하세요. 시스템 상태, 실행 기록 및 실제 접속 결과를 서로 설명할 수 있어야 합니다. 규칙이 너무 복잡하면 조건을 최소화한 뒤 하나씩 다시 추가하고, 추가할 때마다 네트워크 전환을 테스트하세요. 자동 실행과 관계없는 첫 연결 절차는 기본 서버 선택 및 Connectivity Test를 참고하세요. On Demand를 점검하기 위해 가져오기 절차 전체를 반복할 필요는 없습니다.

04 / Ping

Ping 및 Connectivity Test

테스트 결과는 해당 테스트 경로만 나타냅니다

Ping 관련 설정은 서버 목록 테스트에 사용하는 방식, 대상 또는 대기 조건에 영향을 줍니다. 정확한 항목은 현재 화면의 선택지를 기준으로 확인하세요. 목록에 표시된 응답 시간은 종합적인 네트워크 품질 점수가 아니며 웹페이지를 여는 데 필요한 전체 시간과도 다릅니다. 요청에는 이름 해석, 연결 설정, 프로토콜 협상, 원격 처리 및 콘텐츠 전송 단계가 포함될 수 있습니다. 테스트 방식마다 확인하는 단계가 다르므로 서로 다른 방식의 수치를 직접 비교하지 말고, 가장 낮은 숫자만으로 모든 용도에 적합한 서버를 판단하지 마세요.

기본 테스트 방식과 시간 제한은 현재 설정을 기준으로 확인하세요. 동기화 복원이나 이전 수동 변경으로 값이 달라졌을 수 있습니다. 기존 테스트 매개변수를 유지하고 정상적으로 작동하는 서버 하나를 기준으로 삼은 뒤 항목 하나씩 변경해 차이를 살펴보세요. 현재 화면에서 TCP 또는 다른 연결 방식의 테스트를 지원한다면 해당 연결이 대기 시간 안에 설정되는지 확인하는 데 주로 사용됩니다. 대상에 요청을 보내야 하는 테스트 방식이라면 대상 자체의 가용성도 결과에 반영됩니다. 테스트 실패는 대상 문제일 수 있으며 서버 항목이 무효라는 뜻은 아닙니다.

대상, 네트워크 및 시간을 동일하게 맞추세요

비교할 때는 테스트 대상, 현재 네트워크, 테스트 방식 및 서버 항목을 동일하게 유지하고 가능한 한 비슷한 시간에 진행하세요. Wi-Fi에서 셀룰러 네트워크로 전환하면 비교 조건이 달라집니다. 낮 시간의 결과와 사용량이 많은 시간대의 결과를 바로 비교해도 설정이 개선되었는지 판단하기 어렵습니다. 결과의 일관성을 확인하려면 몇 차례 반복할 수 있지만 짧은 간격으로 계속 요청할 필요는 없습니다. 테스트도 트래픽과 연결을 발생시키므로 과도한 테스트는 사용 중인 연결에 영향을 주고 일시적인 변동을 큰 문제처럼 보이게 할 수 있습니다.

시간 초과는 정해진 대기 시간 안에 테스트가 완료되지 않았다는 뜻이지 주소에 영구적으로 접근할 수 없다는 뜻은 아닙니다. 대기 시간이 너무 짧으면 느리지만 사용 가능한 경로도 제외될 수 있고, 너무 길면 작동하지 않는 항목의 결과가 늦게 표시됩니다. 이 가이드에서는 공통으로 적용할 초 단위 값을 지정하지 않습니다. 먼저 화면의 기존 값을 사용하고 실제 테스트 목적에 맞춰 조정하세요. 여러 항목에서 동시에 시간 초과가 발생하면 각 서버 필드를 다시 쓰기 전에 기기 네트워크와 테스트 대상을 확인하세요. 항목 하나만 이상하다면 해당 주소, 포트, 인증 정보 및 서비스 상태를 점검합니다.

목록 테스트와 실제 연결을 따로 검증하세요

목록에 응답이 표시되어도 해당 항목이 기본 서버로 선택되었다는 뜻은 아닙니다. 먼저 Home에서 사용할 서버를 선택하고 선택 표시를 확인한 뒤 Global Routing 모드를 점검하세요. 그런 다음 연결을 시작하고 Connectivity Test를 실행한 다음 안정적으로 문제가 재현되는 대상을 방문하세요. 이렇게 하면 ‘항목 테스트 가능 여부’, ‘현재 선택이 올바른지’, ‘연결 경로가 사용 가능한지’를 각각 확인할 수 있습니다. 첫 번째만 확인하면 선택되지 않은 서버의 테스트 결과를 현재 연결 상태로 오해하기 쉽습니다.

응답은 정상이지만 실제 접속 실패

이런 차이가 나타나면 먼저 테스트가 어떤 단계를 확인했는지 살펴보세요. 테스트가 서버 포트까지만 확인했다면 인증 정보가 여전히 틀릴 수 있습니다. 테스트 대상은 접속되지만 실제 대상은 다른 규칙과 매칭되었을 수도 있습니다. 다음으로 DNS, 대상 도메인의 정책 및 Log에 기록된 오류 단계를 확인하세요. 응답 시간만 보고 서버를 계속 전환하지 마세요. 서버를 바꾸면 원격 출구와 연결 상태가 함께 달라져 원래 문제가 새로운 조건에 가려질 수 있습니다. 조건을 고정해 문제를 재현할 수 있도록 기록하는 편이 테스트 수치를 더 많이 모으는 것보다 유용합니다.

VMess, VLESS, Trojan, Hysteria2 등 프로토콜이 서로 다르면 포트에 연결된다는 사실만으로 모든 프로토콜 매개변수가 일치한다고 볼 수 없습니다. 일부 항목은 전송 계층, 이름 검증 또는 서버 측 설정에도 영향을 받으므로 사용자가 보유한 서버 정보를 필드별로 대조해야 합니다. 프로토콜 필드의 역할은 지원 프로토콜 및 Add Server 필드 개요를 참고하세요. 이 페이지는 테스트 설정만 설명하며 테스트 수치로 서비스 제공자를 평가하거나 노드를 추천하지 않습니다.

05 / Log

Log 기록과 문제 진단

시각을 기록한 뒤 요청을 한 번 재현하세요

Log는 연결 과정에서 발생한 이벤트와 오류를 대조하는 데 유용하지만 모든 기록이 문제를 뜻하지는 않습니다. 진단을 시작할 때 기기 시간, 현재 네트워크, 기본 서버, Global Routing 및 현재 Config를 기록하세요. 그런 다음 연결 후 대상에 접속하는 등 명확한 동작을 한 번만 실행합니다. 이어서 비슷한 시각의 기록을 찾아 이름 해석, 연결 설정, 프로토콜 처리, 대상 접속 순서로 확인하세요. 로그 전체를 구분 없이 살펴보면 이전 시도의 오류와 현재 성공한 결과를 혼동하기 쉽습니다.

기록 스위치, 상세 수준 및 보관 방식은 현재 화면을 기준으로 확인하세요. 모든 설치 환경에서 동일한 내용이 기본 저장된다고 가정하지 않습니다. 평소에는 기본 진단에 필요한 현재 설정을 유지하고, 문제를 조사할 때만 가능한 범위에서 상세 기록을 일시적으로 늘린 뒤 완료 후 복원하세요. 상세 기록에는 더 많은 접근 메타데이터가 포함될 수 있으며 저장 공간과 확인 부담도 커집니다. 화면에 특정 수준이나 내보내기 옵션이 없다면 같은 이름의 숨겨진 메뉴를 찾지 않아도 됩니다. 실제로 제공되는 기능을 사용하세요.

실패 단계에 따라 범위 좁히기

로그에 이름 해석 오류가 먼저 나타나면 DNS와 해당 도메인을 확인하세요. 해석 결과가 있지만 연결 대기 시간이 끝난다면 주소, 포트 및 네트워크 접근성을 살펴봅니다. 연결 후 인증 또는 프로토콜 관련 오류가 발생하면 서버 필드를 다시 확인하세요. 대상에서 오류 응답을 반환했다면 대상 서비스 자체의 문제일 수도 있습니다. 이 순서는 모든 기록을 기계적으로 분류하기 위한 것이 아니라 불필요한 변경을 줄이기 위한 방법입니다. 이름 해석을 뒷받침하는 기록 없이 프로토콜 매개변수 여러 개를 바꾸거나 인증 실패 때 DNS를 계속 바꾸면 실제 오류 단계에서 벗어날 수 있습니다.

연결 중단은 네트워크 전환이나 수동 연결 해제 때문일 수도 있습니다. 로그 시각을 실제 조작 시각과 대조해 Wi-Fi에서 셀룰러로 전환하거나 On Demand를 켜거나 서버를 바꾼 뒤 발생한 일인지 확인하세요. 같은 동작을 반복할 때 비슷한 오류가 나타나야 재현 근거가 뚜렷해집니다. 한 번 발생한 뒤 회복된 기록이라면 우선 보관하며 지켜볼 수 있고, 바로 구성을 재설정할 필요는 없습니다. 안정적으로 재현되지 않는 문제는 무관한 설정을 대거 바꾸기보다 발생 조건을 수집하세요.

규칙 매칭을 확인하고 대상과 정책을 혼동하지 마세요

Config 모드에서 로그에 정책이나 매칭 정보가 표시된다면 실제 대상에 예상한 정책이 적용되었는지 확인하세요. 도메인 규칙은 먼저 매칭될 수 있는 넓은 규칙보다 앞에 배치하고 FINAL은 마지막 대체 정책으로 둡니다. 앱에 표시된 대상 도메인, 실제 연결 주소 및 정책 이름은 서로 다른 필드입니다. 익숙한 도메인 하나만 보았다고 프록시를 사용했다고 단정하지 마세요. Proxy 또는 Direct 모드라면 규칙이 ‘적용되지 않았다’고 판단하기 전에 현재 모드의 의미부터 확인하세요.

[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

이 예시에서는 example.com 자체가 먼저 DOMAIN과 매칭되어 DIRECT를 사용합니다. 하위 도메인은 뒤에 있는 DOMAIN-SUFFIX와 매칭될 수 있습니다. 구체적인 조건이 먼저 적용되는 모습을 보여주는 것으로, 관련 규칙 두 개가 있다고 해서 충돌이 발생한다는 뜻은 아닙니다. 변경할 때는 바꿔야 하는 규칙만 조정한 뒤 같은 대상에서 다시 검증하세요. 두 줄의 순서를 바꾸면 루트 도메인이 접미사 규칙과 먼저 매칭될 수 있습니다. 규칙이 ‘존재하는지’만 확인해서는 부족하며 순서와 실제 요청 이름도 확인해야 합니다.

저장하거나 공유하기 전에 민감한 내용을 처리하세요

로그에는 서버 주소, 대상 도메인, 로컬 네트워크 정보, 구독 링크 또는 인증 관련 정보가 포함될 수 있습니다. 공개적으로 도움을 요청하기 전에 전체 구독 주소와 쿼리 매개변수, 인증 정보, 개인 식별 정보 및 불필요한 접근 기록을 삭제하세요. 서버에 표시된 이름만 가려서는 충분하지 않을 수 있습니다. 실제 주소가 뒤쪽 로그에 나타날 수 있기 때문입니다. 전체 장기 기록을 보내기보다 시간 범위, 오류 단계, 민감 정보를 가린 관련 필드 및 수행한 조작 등 문제를 재현하는 데 필요한 최소한의 내용만 남기세요.

정리하기 전에 유용한 근거가 담긴 로그를 삭제하지 마세요. 필요한 부분을 비공개 위치에 먼저 저장한 다음 앱에서 현재 제공하는 방법으로 기록을 정리할 수 있습니다. 로그 정리는 구성 정리와 다르며 구성을 복원해도 로그가 반드시 복원되는 것은 아니므로 각각 따로 관리해야 합니다. 로그가 비어 있다면 기록 기능이 켜져 있는지, 올바른 범위를 보고 있는지, 요청이 실제로 현재 연결을 통과했는지 확인하세요. 로그가 없다는 사실만으로 요청의 성공이나 실패를 판단할 수 없습니다. 자주 발생하는 오류의 빠른 분류는 질문과 답변의 문제 해결 분류에서 시작하세요.

06 / Widget

Widget과 시스템 상태 확인

빠른 실행 기능은 전체 설정 화면을 대신하지 않습니다

Widget은 시스템이 제공하는 간편한 정보 표시 또는 조작 수단입니다. 사용 가능한 모양과 기능은 기기의 시스템 및 앱에서 현재 제공하는 구성 요소에 따라 다릅니다. 제한된 상태를 확인하거나 지원되는 동작을 실행하는 데 사용할 수 있지만 Home, Config 및 Settings 전체를 확인하는 기능을 대신하지는 않습니다. 특히 구성을 가져오거나 기본 서버를 바꾸거나 On Demand를 조정한 직후에는 먼저 앱으로 돌아가 실제 선택 상태를 확인한 다음 Widget을 사용하세요. Widget에 표시된 짧은 문구만으로 현재 구성, 정책 및 서버가 모두 올바르게 전환되었다고 판단할 수 없습니다.

Widget 표시 여부, 배치 위치 및 크기는 시스템에서 관리합니다. 앱 내 관련 설정은 표시하거나 읽을 수 있는 정보에 영향을 줄 수 있습니다. 두 설정 범위를 나누어 확인하세요. 기본 표시 상태는 현재 추가한 Widget과 설정을 기준으로 하며 모든 기기에 공통된 권장 배치는 없습니다. 쉽게 알아볼 수 있는 최소한의 Widget부터 사용하고 필요한 경우에만 다른 항목을 추가하세요. 이름이 비슷한 항목이 많으면 이전 선택을 잘못 누르거나 상태를 오해할 수 있습니다.

표시 지연과 연결 상태 불일치

시스템은 Widget 새로고침 시점을 관리하므로 앱 화면과 매초 일치한다고 보장되지 않습니다. 앱에서 연결을 끊었는데 Widget에는 이전 상태가 남아 있거나 연결 직후 표시가 아직 갱신되지 않을 수 있습니다. 상태가 다르면 Widget을 계속 누르며 새로고침을 시도하기보다 Shadowrocket을 열어 현재 연결을 확인하고 시스템 VPN 상태 및 실제 요청 결과와 대조하세요. 연결과 해제를 연속으로 실행하면 새로운 상태 변화가 발생해 단순한 표시 지연이 실제 연결 중단으로 이어질 수 있습니다.

시스템 절전, 기기 잠금, 백그라운드 실행 조정 및 네트워크 변경은 정보 업데이트 시점에 영향을 줄 수 있습니다. 여기서는 고정된 새로고침 간격을 보장하지 않으며 Widget 문구를 즉시 갱신하기 위해 시스템 전원 설정을 계속 바꾸는 것도 권장하지 않습니다. Widget에 이상한 표시가 지속되면 앱을 정상적으로 열어 현재 상태를 확인할 수 있는지 먼저 확인한 다음 Widget에서 사용할 구성 항목을 다시 선택해야 하는지 살펴보세요. 시스템에서 Widget 제거 및 재추가를 지원하면 기존 배치를 기록한 후 시도할 수 있습니다. 이 작업은 Widget 표시를 위한 것으로 앱을 삭제하거나 연결 구성을 재설정할 필요는 없습니다.

선택한 서버와 연결 중인 서버 구분

전환 중에는 Home의 선택, 이미 설정된 연결 및 Widget에 표시되는 항목이 서로 다른 상태일 수 있습니다. 서버 항목을 선택했다고 해서 기존 연결이 새 항목으로 다시 설정되었다고 볼 수는 없습니다. Widget에 이름이 표시되어도 해당 항목이 현재 사용 가능하다는 뜻은 아닙니다. 전환 후에는 앱의 현재 동작을 확인해 재연결이 필요한지 판단하고 Connectivity Test를 실행하세요. 테스트에 실패하면 Ping, DNS 및 Log 장을 참고해 문제를 살펴보세요. 모든 문제를 Widget 표시 설정 탓으로 돌리지 마세요.

이름이 비슷한 서버 항목이 여러 개라면 사용자가 관리하는 범위 안에서 구분하기 쉬운 이름을 사용하세요. 이름에 암호, 전체 구독 주소 또는 민감한 정보를 넣지 마세요. Widget은 주변 사람이 볼 수 있는 위치에 항목 이름을 표시할 수 있으므로 잠금 화면에 보일 때는 개인정보 보호를 고려해야 합니다. 이름은 항목 식별용일 뿐 이름을 바꿔도 프로토콜 매개변수가 수정되거나 서버의 실제 기능이 바뀌지는 않습니다. 테스트와 설정 확인은 실제 필드를 대상으로 해야 합니다.

On Demand와 함께 사용할 때의 주의 사항

Widget에서 연결을 끊어도 On Demand 조건이 계속 충족되면 시스템이 다시 연결을 시도할 수 있습니다. 이때는 Widget 버튼이 응답하지 않는다고 판단하지 말고 자동 실행 원인을 확인하세요. 연결을 일시적으로 멈추려면 앱에서 자동 조건을 확인한 뒤 연결을 해제합니다. 다시 사용하려면 기존 서버와 구성이 올바른지 확인하고 해당 조건을 복원하세요. Widget은 조작 수단이고 자동 규칙은 별도의 제어 계층이므로 마지막으로 누른 버튼만 볼 것이 아니라 하나의 검증 과정 안에서 함께 판단해야 합니다.

Widget을 눌렀을 때 예상한 동작을 바로 수행하지 않고 앱을 여는 경우에는 현재 시스템이 허용하는 방식에 따르세요. 일부 동작은 기기 잠금 해제, 앱 열기 또는 시스템 확인 절차가 필요할 수 있습니다. 모든 동작이 백그라운드에서 조용히 실행된다고 가정하지 마세요. 최초 VPN 권한은 시스템 팝업에서 직접 승인해야 합니다. Widget은 성공적으로 검증된 일상 작업에 편리하지만 최초 설정과 문제 해결은 필요한 필드와 오류를 확인할 수 있는 앱의 전체 화면에서 진행하세요.

iPhone과 iPad는 Widget 배치 방식과 사용 가능한 위치가 다를 수 있습니다. 시스템 요구 사항과 호환성은 App Store 페이지를 기준으로 확인하세요. 처음부터 명확한 연결 절차를 진행하려면 시작하기로 돌아가세요. 표시만 늦어지는 문제라면 기존 구독을 다시 가져올 필요가 없으며 Widget을 새로고침하려고 DNS나 Proxy 포트를 계속 바꿀 필요도 없습니다.

07 / iCloud

iCloud 동기화와 구성 복원

앱 구매, 구성 동기화 및 시스템 권한은 각각 확인하세요

iCloud 동기화는 앱이 지원하는 범위에서 데이터를 저장하거나 교환하는 기능이며 App Store 구매 기록과는 다릅니다. 구매 기록은 ‘앱을 다시 받을 수 있는지’를 확인하고, 동기화는 ‘어떤 앱 데이터를 기기 간에 복원할 수 있는지’를 다룹니다. 시스템 VPN 권한은 ‘이 기기에서 해당 구성을 만들 수 있는지’를 결정합니다. 같은 계정 체계를 사용하더라도 각각의 설정 위치와 상태는 다릅니다. 기기를 바꾼 뒤 앱이 설치되어 있어도 서버, 규칙 및 연결 권한이 모두 복원되었다는 뜻은 아닙니다.

동기화 스위치, 동기화 가능한 데이터 종류 및 현재 상태는 앱과 시스템 화면을 기준으로 확인하세요. Config, 서버 항목, 모든 Settings, 로그 및 시스템 권한이 하나의 묶음으로 완전히 복사된다고 가정하지 않습니다. 원본 기기에서 어떤 항목이 동기화 대상인지 확인한 뒤 새 기기에서 실제로 나타난 항목을 하나씩 점검하세요. 데이터 항목을 따로 선택하는 화면이 있다면 필요한 항목만 활성화하고 모든 것을 똑같이 만들겠다는 이유로 전부 켜지 마세요. 시스템의 VPN 권한은 새 기기에서 별도로 확인해야 합니다.

활성화 전 계정, 저장 공간 및 별도 사본 확인

동기화를 켜거나 문제를 해결하기 전에 시스템에 iCloud가 로그인되어 있는지, 앱이 필요한 조건을 갖추었는지, 저장 공간과 네트워크를 사용할 수 있는지 확인하세요. 기본 상태는 현재 기기를 기준으로 합니다. 이전 기기에서 켜져 있어도 새 기기에서 같은 상태라고 보장되지 않습니다. 정상적으로 사용 중인 구성은 먼저 별도 사본으로 저장하고 안에 포함된 인증 정보를 안전하게 보호하세요. 동기화는 이전 버전을 보관하는 기능이 아니며 실수로 변경한 모든 항목을 복구해 준다고 보장하지 않습니다. 잘못된 변경이 다른 기기로 동기화되면 복원에 사용할 원본 사본이 필요합니다.

원본 기기와 대상 기기에서 같은 항목을 동시에 편집하면 이름 중복, 내용 불일치 또는 덮어쓰기 선택이 발생할 수 있습니다. 처리하기 전에 양쪽 편집을 잠시 멈추고 사용할 수 있는 전체 데이터가 저장된 기기 하나를 기준으로 정한 다음 다른 기기의 실제 데이터를 비교하세요. 같은 이름의 구성을 두 기기에서 연달아 삭제하고 다시 만들지 마세요. 그 작업 역시 동기화 과정에 포함될 수 있습니다. 앱에 충돌 안내나 선택 화면이 표시되면 보존 범위를 먼저 확인하고 어느 쪽을 남길지 정한 뒤 진행하세요.

구독 업데이트와 iCloud 동기화는 다릅니다

Subscribe 업데이트는 사용자가 보유한 구독 주소에서 데이터를 다시 가져오는 작업입니다. iCloud 동기화는 기기 간 데이터 교환입니다. 전자는 구독 주소, 인증 및 형식에 영향을 받고 후자는 계정, 시스템 권한 및 동기화 상태에 영향을 받습니다. 새 기기에 항목이 나타나도 구독 주소가 현재 갱신 가능한 것은 아닙니다. 원본 기기에서 갱신할 수 있어도 새 기기의 목록에 최신 내용이 도착했다는 뜻은 아닙니다. 문제를 점검할 때 ‘원격 데이터 가져오기’와 ‘기기 간 데이터 전달’ 중 어느 과정에서 발생했는지 먼저 확인하고 두 절차를 번갈아 실행하지 마세요.

새 기기에 구독 항목이 있지만 업데이트에 실패한다면 iCloud를 반복해서 껐다 켜지 말고 구독 주소가 완전한지, 만료되지 않았는지, 현재 네트워크에서 접근 가능한지 확인하세요. 원본 기기에서는 업데이트되었는데 새 기기의 목록이 그대로라면 동기화 범위와 상태를 확인합니다. 새로고침 위치와 오류별 점검 방법은 구독 수동 업데이트 및 자동 업데이트 문제 해결을 참고하세요. 접근 인증 정보가 포함된 구독 주소는 비공개로 보관하고 공개적인 동기화 문제 기록에 적지 마세요.

복원 후 항목별로 확인하고 전체를 그대로 믿지 마세요

복원이 끝나면 Home 목록, 기본 서버 선택, Global Routing, 현재 Config 및 DNS 관련 설정을 먼저 확인하세요. 이어서 새 기기의 사용 환경에 On Demand가 적합한지 살펴봅니다. 두 기기의 데이터가 같더라도 연결되는 네트워크, 시스템 권한 및 라우팅 조건은 다를 수 있습니다. 따라서 원본 기기에서 대상에 접속되었다는 사실만으로 새 기기의 복원이 성공했다고 판단하지 마세요. 새 기기에서 수동 연결, Connectivity Test 및 실제 접속을 각각 확인해야 합니다.

앱을 다시 받아야 한다면 App Store의 구입 항목 또는 정품 제품 페이지에서 진행하세요. 자세한 절차는 기기 변경 및 구입 항목 복원 안내를 참고하세요. 구매 가능 여부, 시스템 요구 사항 및 공유 범위는 App Store 페이지를 기준으로 확인하세요. 앱 구매 복원에는 사용자가 별도로 관리하는 회선 서비스가 포함되지 않으며 인증 정보의 유효 기간도 보장하지 않습니다. 복원 후 일부 데이터가 없다면 앱을 반복해서 다시 설치하는 대신 현재 상태를 보존하고 동기화 범위와 별도 사본을 차례로 확인하세요.

계정에서 로그아웃하거나 동기화를 중지하거나 클라우드 데이터를 정리하기 전에 작업이 이 기기, 클라우드 또는 다른 기기에 어떤 영향을 주는지 확인하고 필요한 내용을 저장하세요. ‘동기화 중지’를 모든 사본 삭제로 해석하지 말고, ‘기기에 데이터가 남아 있음’을 클라우드 백업이 완료되었다는 뜻으로 보지 마세요. 화면 안내와 실제 확인 결과를 기준으로 처리하면 복원 중 실수로 삭제할 위험을 줄일 수 있습니다.

08 / Proxy

Proxy 포트와 최종 검증

원격 포트와 로컬 수신 포트 구분

Add Server의 서버 포트는 사용자가 보유한 서버 정보에 따라 정해지며 원격 서비스에 연결할 때 사용합니다. Settings의 Proxy 관련 로컬 포트는 기기에서 로컬 프록시 진입점을 제공할 때 사용하는 수신 설정입니다. 둘 다 숫자로 표시되어도 같은 항목은 아닙니다. 로컬 포트를 바꿔도 원격 서비스 포트는 변경되지 않으며 잘못된 서버 주소도 해결할 수 없습니다. 문제를 점검하기 전에 서버 편집 화면을 보는지 앱의 로컬 Proxy 설정을 보는지 확인해 엉뚱한 위치에서 숫자를 반복해 바꾸지 않도록 하세요.

로컬 수신 포트의 기본값, 활성화 여부 및 허용 접근 범위는 현재 화면을 기준으로 확인하세요. 로컬 프록시 연결이 필요하지 않다면 현재 상태를 유지하고 일반 연결을 위해 불필요하게 수신을 열지 마세요. 필요한 경우 주소, 포트, 프로토콜 유형 및 접근 범위를 기록한 뒤 이를 호출하는 쪽도 설정하세요. 포트는 연결 진입점의 일부이므로 수신 주소 및 프로토콜과 함께 확인해야 합니다. 포트 숫자 하나만으로는 연결 방법을 완전히 설명할 수 없으며 다른 기기에서 접근해야 하는지 판단할 수도 없습니다.

수신 주소와 접근 범위의 보안 경계

기기 안에서만 접근할 수 있는 주소와 로컬 네트워크에서 접근할 수 있는 주소는 노출 범위가 다릅니다. 수신 범위를 넓히기 전에 실제 필요성, 현재 네트워크의 신뢰성 및 앱의 접근 제어 기능을 확인하세요. 다른 기기를 연결하려고 수신 범위를 모든 접근 가능한 네트워크로 바로 확대하지 마세요. 기기 내부에서만 사용한다면 현재 기능이 허용하는 가장 좁은 접근 범위를 사용하세요. 공유 네트워크의 다른 기기는 사용자가 관리하지 않을 수 있으므로 로컬 프록시 진입점은 단순히 ‘연결할 수 있는지’가 아니라 실제 용도에 맞게 관리해야 합니다.

호출하는 쪽의 설정을 입력할 때 주소는 원격 서버 도메인이 아니라 수신 기능을 제공하는 기기를 가리켜야 합니다. 포트는 로컬 수신 값과 같아야 하며 프로토콜 유형도 일치해야 합니다. 기기가 다른 네트워크로 전환되면 로컬 네트워크 주소가 바뀔 수 있습니다. 이전 주소가 작동하지 않는다고 해서 반드시 Shadowrocket 오류인 것은 아닙니다. 점검할 때는 먼저 두 기기가 의도한 네트워크에 연결되어 있는지, 수신이 켜져 있는지, 주소가 바뀌지 않았는지 확인한 다음 포트와 프로토콜을 살펴보세요. 이런 기본 조건을 확인하기 전에 DNS, 규칙 또는 서버 인증 필드를 바꾸지 마세요.

포트 충돌과 연결 거부 확인 순서

즉시 연결 거부, 계속되는 대기 및 연결 후 프로토콜 오류는 서로 다른 현상입니다. 연결이 거부되면 수신이 시작되었는지와 주소 및 포트가 올바른지 먼저 확인하세요. 계속 대기하면 네트워크 접근성과 허용 범위를 확인합니다. 연결된 뒤 실패한다면 호출하는 쪽에서 선택한 프로토콜과 인증 요구 사항을 점검하세요. 포트 충돌로 수신 기능이 정상적으로 시작되지 않을 수도 있지만 한 번의 시간 초과만으로 충돌이라고 단정할 수는 없습니다. 앱 안내와 Log를 함께 확인하고 무작위로 많은 포트를 바꾸며 시험하지 마세요.

로컬 포트를 변경해야 한다면 연결이 끊겨도 되는 시간에 작업하세요. 변경 후 저장하고 모든 호출 기기의 설정도 함께 업데이트합니다. 기존 연결은 새 포트로 자동 전환되지 않을 수 있으므로 새 테스트 연결을 설정하세요. 값을 정하기 전에 필드에서 허용하는 범위와 다른 로컬 기능이 해당 포트를 사용 중인지 확인하세요. 이 가이드에서는 필수로 사용해야 할 공통 포트를 지정하지 않습니다. 변경해도 개선되지 않으면 기존 수신 설정과 호출 기기 설정을 복원해 한쪽만 바뀐 상태가 남지 않도록 하세요.

Proxy 진입점 이후의 라우팅과 구성 확인

로컬 진입점에서 요청을 받을 수 있어도 이후 정책이 올바르다고 보장되지는 않습니다. Global Routing, 선택한 서버 및 현재 Config도 확인해야 합니다. 아래는 정책 선택을 설명하는 독립된 규칙 예시이며 수신 설정이나 서버 인증 정보는 포함하지 않습니다. 전체 구성을 대신할 수 없으며 사용자가 보유한 구독의 프로토콜 필드를 덮어쓰는 용도로 사용해서는 안 됩니다. 로컬 포트 문제와 규칙 문제를 따로 점검해야 요청이 앱에 들어오지 않는지, 들어온 뒤 예상과 다른 경로로 처리되는지 구분할 수 있습니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,ads,REJECT
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,PROXY

예시에 나오는 도메인과 주소 범위는 문법 설명용입니다. DOMAIN-SUFFIX는 도메인 접미사와 매칭하고 DOMAIN-KEYWORD는 도메인 안의 키워드와 매칭하며 IP-CIDR은 주소 범위를 대상으로 합니다. FINAL은 마지막 대체 정책으로 사용됩니다. REJECT는 매칭된 요청을 차단하므로 추가하기 전에 적용 범위를 검토하고 중요한 서비스에 넓은 키워드를 바로 사용하지 마세요. 일반적인 규칙 분기 결과를 이 순서로 설명하려면 Global Routing이 Config 모드여야 합니다. 다른 모드에서는 해당 모드의 의미에 맞춰 검증하세요.

변경을 마무리하는 검증 절차

최종 검증은 진입과 출구 두 단계로 진행합니다. 먼저 호출하는 쪽에서 올바른 로컬 수신 포트에 도달하는지 확인하고, 다음으로 앱이 예상한 정책을 선택해 대상 접속을 완료하는지 살펴보세요. 진입은 되지만 출구에서 실패하면 Ping, DNS 및 Log 장으로 돌아가세요. 진입에 실패하면 주소, 포트 및 접근 범위부터 확인합니다. 완료 후 성공 조건, 이전 값 및 새 값을 기록하고 문제 해결을 위해서만 켰던 추가 기록 기능은 끄며 필요한 On Demand 상태를 복원하세요. 설정 가이드의 목적은 스위치를 늘리는 것이 아니라 각 변경에 명확한 이유와 검증 가능한 결과를 갖게 하는 것입니다.