Shadowrocket 설정 참고: 연결 동작에 맞춰 설정값 확인하기

먼저 설정이 속한 계층을 확인하세요

Shadowrocket의 연결 결과는 Settings만으로 결정되지 않습니다. Home에서 선택한 서버는 연결 출구를 정하고, Global Routing은 대상에 규칙을 적용할지 결정합니다. 현재 사용하는 Config 파일에는 규칙과 일부 네트워크 설정이 있으며, Settings에는 테스트, 연결 보조 기능과 앱 환경설정 등이 저장됩니다. 시스템 VPN 권한, 네트워크 환경과 백그라운드 실행도 영향을 줍니다. 문제를 살펴볼 때는 이 계층들을 구분하세요. 서버 인증 정보가 만료됐는데 DNS를 계속 바꾸거나, Direct 모드에서 PROXY 규칙이 올바른지 판단하는 실수를 피할 수 있습니다.

‘초기값’은 특정 환경의 시작 값, ‘현재값’은 화면에 표시된 값, ‘적용값’은 실제 연결에 사용되는 값입니다. 세 값은 다를 수 있습니다. Config를 가져온 뒤에는 파일의 DNS 설정이 실제 경로를 바꿀 수 있고, 파일을 편집했더라도 그 파일을 선택하지 않았다면 이번 연결에 적용되지 않습니다. 권장 사항을 참고할 때는 해당 옵션이 현재 플랫폼에 있는지 확인하고, 앱 설명과 선택한 Config, 실행 중인 연결을 함께 살펴보세요. 오래된 화면 캡처만으로 판단하지 마세요.

복구할 수 있도록 현재 상태를 기록하세요

시작 전에 현재 네트워크 유형, 서버 이름, Global Routing 모드, Config 파일 이름과 변경할 항목을 기록하세요. 기존 설정은 사본을 보관하고, 구독에서 생성된 파일과 직접 관리하는 파일은 이름을 구분하세요. 파일명에는 용도를 적되 계정 정보나 전체 주소는 넣지 않아도 됩니다. 내보낸 파일에 서버 비밀번호, 구독 매개변수 또는 개인 식별 정보가 포함되어 있다면 본인이 관리하는 안전한 위치에만 보관하세요. 도움을 요청할 때는 해당 항목을 가리고, 일반적인 쿼리 매개변수처럼 보이는 주소의 인증 정보도 빠뜨리지 않도록 주의하세요.

한 번에 한 항목만 바꾸고, 확인할 수 있는 목표를 정하세요. 예를 들어 ‘DNS 변경 후 같은 도메인이 확인된다’는 ‘네트워크 최적화’보다 검증하기 쉽습니다. ‘Wi-Fi로 돌아오면 자동 연결되지 않는다’도 ‘백그라운드 동작 끄기’보다 분명합니다. 이전에 접속되던 대상을 비교 대상으로 하나 고르고, 문제가 있는 대상도 하나 선택하세요. 두 대상 모두 실패하면 네트워크와 연결 자체를 먼저 확인하고, 문제 대상만 실패하면 규칙, DNS 결과와 대상 서비스를 살펴보세요. 곧바로 모든 설정을 초기화하지 마세요.

권장 시작점과 복구 조건

이미 정상 작동하는 설정은 기준으로 유지하세요. 옵션 이름이 더 고급스러워 보인다고 켤 필요는 없습니다. 연결이 아직 안정적이지 않다면 기존 설정의 요구 사항부터 확인하고, 추가 자동 조건이나 수동 재정의는 최소화하세요. 변경 사항을 저장한 뒤 설정에 따라 연결을 끊었다가 다시 연결하세요. Settings 페이지를 다시 여는 것만으로 네트워크 세션이 새로 만들어졌다고 볼 수는 없습니다. 재검사는 같은 네트워크, 서버와 대상을 사용해야 설정 변경과 환경 변화를 구분할 수 있습니다.

새 문제가 생기면 보완 설정을 더하기보다 방금 변경한 항목부터 되돌리세요. 되돌린 뒤에도 문제가 계속되면 기존 연결, 시스템 DNS 캐시, 앱 캐시 또는 네트워크 전환이 영향을 주는지 확인한 다음 새 연결을 만드세요. 복구 범위도 분명히 정해야 합니다. 테스트 결과를 되찾으려고 서버를 모두 지우거나 구독을 삭제하고 앱을 재설치하지 마세요. 가져오기와 첫 연결 과정을 다시 확인해야 한다면 가이드의 진행 순서를 참고해 문제 해결과 처음 시작을 구분하세요.

시스템 DNS, 사용자 지정 DNS 및 DNS over HTTPS

DNS는 도메인 이름을 연결에 필요한 주소로 변환합니다. 프록시 서버를 대체하거나 잘못된 프로토콜 설정을 고쳐 주지는 않습니다. 시스템 DNS는 보통 현재 네트워크의 DNS 설정을 따르므로 네트워크에서 실제로 어떤 일이 일어나는지 확인하기 좋은 출발점입니다. 사용자 지정 DNS는 지정한 DNS 서비스를 사용하지만 연결 가능 여부는 네트워크와 설정에 좌우됩니다. DNS over HTTPS는 HTTPS로 DNS 요청을 전송하며, 엔드포인트 확인과 연결 수립, 인증서 검증도 필요합니다. 방식을 바꾸기 전에 문제가 실제로 DNS 조회 단계에서 발생하는지 확인하세요. 웹페이지가 열리지 않는다는 이유만으로 모든 DNS 설정을 바꾸지 마세요.

초기 상태는 현재 클라이언트와 선택된 Config에서 함께 확인해야 합니다. 입력란이 비어 있다고 해서 DNS 조회가 없다는 뜻은 아닙니다. 빈 값은 시스템 설정 상속, Config 값 사용 또는 클라이언트 기본 동작을 나타낼 수 있으므로 해당 필드의 설명을 확인하세요. Config에 관련 DNS 설정이 있다면 먼저 사본을 보관한 뒤 파일과 앱 중 어디에서 수정할지 결정하세요. 같은 목적의 설정은 한 곳에서 명확하게 관리해 화면 값과 파일 값이 달라지고, 이후 변경 사항이 저장되지 않았다고 오해하는 일을 피하세요.

권장값은 네트워크 환경에 따라 달라집니다

일반적인 문제 해결에서는 우선 정상 작동 중인 DNS 방식을 유지하세요. 사용자 지정 DNS가 필요하다면 사용할 수 있음을 확인했고 해당 필드 형식에도 맞는 주소만 입력하세요. 일반 DNS 주소와 HTTPS 엔드포인트는 서로 바꿔 쓸 수 있는 문자열이 아닙니다. IP 주소만 받는 입력란에 전체 URL을 붙여 넣지 마세요. 여러 값을 지원하는 필드라면 앱 안내에 나온 구분 방식을 따르고 쉼표, 공백 또는 줄바꿈을 임의로 추측하지 마세요. DNS 항목을 하나씩 추가하고 조회와 접속이 가능한지 확인한 뒤에만 예비 항목을 추가하세요.

내부 도메인은 흔히 문제가 생기는 예외 상황입니다. 프린터, 사내 서비스 또는 라우터 관리용 이름은 현재 네트워크의 DNS 서버만 인식할 수 있습니다. 모든 DNS를 외부 서비스로 바꾸면 공용 웹사이트는 열리지만 내부 도메인이 작동하지 않을 수 있으며, 이것만으로 프록시 서버의 문제라고 볼 수는 없습니다. 반대로 집에서 연결되는 DNS 서버가 호텔이나 사무실 네트워크에서는 응답하지 않을 수도 있습니다. 네트워크를 바꾼 뒤에는 DNS 경로를 다시 확인하고, 필요한 경우 내부 도메인 처리를 유지하세요. 한 네트워크에서 유효한 설정을 모든 네트워크의 공통 권장값으로 간주하지 마세요.

DNS 조회 성공이 접속 성공을 뜻하지는 않습니다

검증할 때는 먼저 같은 도메인이 주소로 확인되는지 살펴보고, 다음으로 요청에 예상한 정책이 적용되는지 확인한 뒤, 대상 서비스가 응답하는지 확인하세요. 도메인 규칙은 연결 전에 이름을 기준으로 적용될 수 있지만 IP 규칙은 주소 정보가 필요할 수 있습니다. 두 결과를 같은 것으로 취급하지 마세요. IPv6 주소가 확인되더라도 현재 네트워크나 서버 경로에서 IPv6 연결이 가능하다는 뜻은 아닙니다. 간헐적으로 실패한다면 반환된 주소 유형, 적용된 정책과 실제 오류를 각각 기록하세요. 한 번 재시도에 성공했다는 이유만으로 DNS 문제가 해결됐다고 단정하지 마세요.

변경 후에도 시스템, 브라우저 또는 앱 캐시에 이전 결과가 남아 있을 수 있습니다. 연결을 다시 설정하고 대상 요청을 새로 실행하세요. 필요한 경우 대상 앱을 종료한 뒤 다시 열어 기존 세션이 재사용되지 않도록 하세요. DNS 서버를 빠르게 반복해서 바꾸며 비교하면 캐시, 핸드셰이크와 네트워크 불안정이 뒤섞입니다. 자세한 경로 비교는 DNS 설정 기술 노트를 참고하세요. 복구할 때는 원래 DNS 방식과 설정 출처를 되돌리고 내부 도메인도 다시 테스트해 공용 접속을 복구하면서 로컬 서비스가 계속 작동하는지 확인하세요.

연결 시점을 정하며, 적용할 규칙을 정하지는 않습니다

On Demand는 시스템 네트워크 조건에 따라 연결 동작을 실행하는 기능이며, Global Routing과는 역할이 다릅니다. On Demand는 ‘언제 연결을 시작할지’를 다루고, Global Routing은 ‘연결된 뒤 특정 대상에 어떤 정책을 적용할지’를 다룹니다. On Demand를 켜도 서버 정보가 자동으로 입력되거나 Config에 빠진 규칙이 추가되지는 않습니다. 처음 사용하는 경우에는 먼저 수동 연결이 안정적으로 되는지 확인한 뒤 자동 조건을 추가하세요. 수동 연결부터 실패한다면 자동 트리거는 같은 실패를 반복할 뿐이며 문제를 관찰하기도 더 어려워집니다.

초기 스위치 상태와 기존 시스템 설정은 기기에 실제로 표시되는 값을 기준으로 확인하세요. ‘항상 켜기’를 모든 사용자에게 권장하지 않습니다. 수동 제어가 필요한 사용자는 수동 연결을 유지하는 편이 기준 상태를 파악하기 쉽습니다. 네트워크 조건에 따라 연결해야 한다면 실제 화면에서 지원하는 조건을 하나씩 설정하세요. 현재 플랫폼이 지원하지 않는 조건을 다른 기기의 경로에서 그대로 따라 하지 마세요. 시스템의 자동 연결 권한과 앱 내 스위치가 완전히 같은 설정이라고 간주해서도 안 됩니다.

조건을 각각 따로 검증할 수 있어야 합니다

설정 전에 ‘지정한 네트워크에서는 수동 연결을 유지하고, 다른 네트워크에서는 필요할 때 연결한다’처럼 요구 사항을 명확하게 적어 보세요. Wi-Fi 이름으로 구분하는 기능이 있다면 이름을 정확히 확인하고, 비슷하거나 같은 이름의 네트워크와 숨겨진 네트워크가 미치는 영향도 고려하세요. 이름이 같다고 해서 신뢰할 수 있는 네트워크라는 뜻은 아닙니다. 네트워크 이름 일치는 연결 조건일 뿐 인증 수단이 아닙니다. 조건을 여러 개 추가한다면 현재 화면의 우선순위와 일치 순서를 읽고, 목록에서 보이는 순서대로 시스템이 실행된다고 추측하지 마세요.

‘네트워크 하나, 조건 하나, 전환 한 번’씩 테스트하세요. 현재 Wi-Fi에서 먼저 동작을 확인한 뒤 셀룰러 데이터로 전환하고, 마지막으로 원래 Wi-Fi로 돌아와 시스템 VPN 상태와 앱 내 연결 상태를 각각 기록하세요. 테스트 중에는 서버와 Config를 그대로 유지하고 구독 업데이트나 서버 선택 변경을 피하세요. 시스템 상태 아이콘은 터널 관련 상태만 나타낼 뿐 특정 대상에 접속할 수 있다는 뜻은 아닙니다. 트리거된 뒤에는 분명한 요청을 보내 연결 여부와 예상한 정책이 적용됐는지 확인하세요.

인증이 필요한 네트워크, 절전 및 수동 연결 해제

호텔, 역 또는 방문자용 Wi-Fi는 먼저 인증 페이지를 열어야 할 수 있습니다. 이때 네트워크 이름은 조건에 일치해도 인터넷 연결은 아직 완료되지 않았으므로 자동 연결이 시간 초과될 수 있습니다. 먼저 네트워크 인증을 마친 뒤 설정된 조건을 테스트하세요. 인증 페이지가 열리지 않는다고 서버가 작동하지 않는다고 판단하지 마세요. 인증을 위해 잠시 On Demand를 껐다면 원래 상태를 기록하고 인증 후 다시 설정하세요. 네트워크가 정상에서 제한된 상태로 바뀌는 경우에도 시스템이 트리거하지 않은 것과 트리거됐지만 연결에 실패한 것을 구분해야 합니다.

기기가 잠기거나 앱이 백그라운드로 전환되거나 시스템이 절전 상태에 들어가면 관찰되는 실행 시점이 달라질 수 있습니다. 앱을 닫은 뒤 몇 초 동안 변화가 없다는 이유만으로 설정이 잘못됐다고 판단하지 마세요. 고정된 백그라운드 실행 시간을 보장할 수도 없습니다. 수동으로 연결을 끊은 뒤 다시 연결되는지는 현재 시스템 조건과 설정에 따라 달라집니다. 연결이 끊겼다가 곧 다시 연결되면 VPN 설정을 반복해서 삭제하기보다 먼저 On Demand를 확인하세요. 잠시 연결을 끊어 두려면 자동 트리거 조건을 먼저 끄고 시스템 상태를 확인해, 조건에 따른 재연결을 스위치 고장으로 오해하지 않도록 하세요.

복구하려면 먼저 방금 추가한 조건을 비활성화하고 원인을 파악할 수 있는 수동 연결 상태로 되돌린 다음 기존 서버와 Config를 다시 확인하세요. 시스템 네트워크 설정을 모두 삭제하지 마세요. 다른 용도의 설정까지 함께 지워질 수 있습니다. 수동 연결은 정상이지만 특정 네트워크 전환에서만 문제가 생기면 전환 전후 상태를 기록하고 같은 조건에서 재검증하세요. 서로 겹치는 여러 조건보다 안정적으로 재현되는 하나의 조건이 장기 설정으로 적합합니다.

Config, Proxy, Direct 세 가지 모드

Global Routing의 Config, Proxy, Direct는 각각 설정 적용, 프록시 연결, 직접 연결을 뜻합니다. Config는 현재 선택된 설정으로 대상을 처리하고, Proxy는 대상이 프록시 경로를 사용할 때의 동작을 임시로 확인하는 데 적합합니다. Direct는 프록시를 거치지 않는 접속을 살펴볼 때 사용합니다. 화면의 모드 이름과 규칙에 쓰이는 대문자 정책 키워드는 서로 다른 계층입니다. 둘 다 PROXY 또는 DIRECT가 표시된다고 서로 대신 쓸 수 있는 것은 아닙니다. DNS와 시스템 네트워크 동작도 별도로 확인해야 합니다. 모드 전환만으로 전체 네트워크 경로를 설명할 수는 없습니다.

기존 규칙을 사용하는 일반적인 환경에서는 새 규칙을 추가하기 전에 Config 모드와 선택된 파일부터 확인하세요. 현재 기본 모드는 Home 화면의 실제 선택 상태를 따르고, 파일의 초기 내용은 사용자가 보유한 설정을 기준으로 확인해야 합니다. Proxy 모드에서 대상이 정상으로 돌아와도 두 경로의 동작이 다르다는 것만 알 수 있습니다. 도메인 규칙 오류라고 단정할 수는 없습니다. DNS 결과, 규칙 적용 범위 또는 대상 서비스의 출구 처리 방식도 원인일 수 있습니다. 테스트가 끝나면 원래 모드로 돌아가 임시 진단 설정을 계속 사용하지 않도록 하세요.

규칙은 위에서 아래로 적용하며, 구체적인 규칙을 먼저 두고 마지막에 기본 처리를 둡니다

규칙은 일반적으로 순서대로 적용됩니다. 구체적인 예외를 더 넓은 조건보다 앞에 두고, 최종 처리는 맨 끝에 배치하세요. DOMAIN은 도메인과 정확히 일치하고, DOMAIN-SUFFIX는 도메인 접미사와 관련 하위 도메인에 적용되며, DOMAIN-KEYWORD는 이름에 포함된 키워드로 일치 여부를 판단합니다. 키워드 규칙은 범위가 넓어 원하지 않는 이름까지 일치할 수 있으므로 실제 요청 기록을 확인해 적용하세요. IP-CIDR, IP-CIDR6 및 GEOIP는 주소 범위나 주소의 지역 정보를 다룹니다. 이름이 비슷하다는 이유만으로 도메인 규칙과 서로 바꿔 쓸 수는 없습니다.

아래는 규칙 순서를 이해하기 위한 Shadowrocket .conf 예시입니다. 완전한 연결 설정이 아니며 서버 정보도 포함하지 않습니다. 예시 도메인은 문법 설명용이므로 테스트 서비스로 사용하지 마세요. 첫 번째 규칙은 일치하는 도메인 접미사를 PROXY로 보내고, 두 번째는 지정된 사설 IP 범위를 DIRECT로 보냅니다. 세 번째는 GEOIP 조건에 따라 DIRECT를 선택하며, 나머지 요청은 FINAL을 통해 PROXY로 보냅니다. 이러한 최종 정책을 사용할지는 사용자의 설정 목적에 따라 결정해야 합니다. 예시 전체를 기존 파일에 그대로 덮어쓰지 마세요.

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

설정 업데이트가 직접 수정한 내용을 덮어쓰지 않도록 주의하세요

Subscribe는 사용자가 보유한 구독을 업데이트하는 기능이며, Config의 규칙 파일을 예상한 방식으로 자동 병합한다는 뜻은 아닙니다. 구독에서 생성된 서버 정보, 원격 설정 내용과 로컬 편집 내용을 각각 확인하세요. 업데이트 과정에서 파일이 다시 생성되면 직접 추가한 변경 사항이 사라질 수 있습니다. 원본 파일과 로컬 테스트용 사본을 따로 보관하고 사본에서 먼저 검증하세요. 장기간 유지할 규칙은 현재 클라이언트가 지원하는 관리 방식으로 적용하고, 업데이트 후 확인할 항목을 정해 두세요. 어떤 파일이든 수동 편집 내용이 자동으로 보존된다고 보장할 수는 없습니다.

규칙이 적용되지 않는 것 같다면 네 가지를 확인하세요. 편집한 Config를 선택했는지, Global Routing이 Config인지, 요청에 예상한 도메인이나 주소가 사용됐는지, 앞선 규칙이 이미 일치했는지 확인합니다. 앱이 기존 연결을 재사용하거나 다른 도메인을 추가로 요청할 수 있으므로 브라우저 주소창만으로 실제 일치 대상을 알 수는 없습니다. 저장하고 다시 연결한 뒤 Log에서 해당 요청을 찾아 규칙과 비교하세요. 그래도 불분명하다면 범위가 명확한 임시 규칙 하나로 검증한 뒤 삭제하세요. 문제 해결용 규칙이 트래픽 경로를 장기간 바꾸지 않도록 주의하세요.

테스트 결과만으로 회선 품질을 판단할 수는 없습니다

Ping은 테스트 방식에 따라 서로 다른 탐지 절차를 가리킬 수 있습니다. 결과를 해석하기 전에 Settings에서 현재 선택한 테스트 방식과 대상을 확인하세요. 목록의 숫자 하나만 보고 실제 웹페이지 전체 로딩 시간이라고 판단하면 안 됩니다. 서버까지의 왕복, 전송 연결 수립, 프록시 인증, 테스트 대상 접속은 각각 다른 단계입니다. 한 방식의 탐지가 성공했다면 그 방식이 확인하는 단계에서 응답이 있었다는 뜻입니다. 다른 방식의 시간 초과가 서버 전체를 사용할 수 없다는 뜻은 아닐 수 있으므로 테스트 방식과 실제 요청을 함께 살펴보세요.

초기 테스트 방식, 테스트 주소와 시간 제한은 현재 클라이언트에 표시된 값을 기준으로 확인하세요. 모든 플랫폼에 적용되는 고정 초기값은 없습니다. 기존에 작동하는 테스트 설정을 유지해 같은 조건의 결과를 비교하세요. 변경이 필요하면 원래 값과 변경 이유를 먼저 기록하세요. 대상 주소를 설정할 수 있다면 실제로 접속 가능하고 응답이 안정적이며 해당 테스트 방식에 적합한 주소를 사용하세요. 임의의 웹사이트 첫 화면이 모두 같은 테스트 대상은 아닙니다. 대상에서 해당 요청을 거부하면 결과가 비정상으로 표시될 수도 있습니다.

시간 제한, 동시 테스트 및 결과 비교

시간 제한이 너무 짧으면 정상적이지만 느린 핸드셰이크가 실패로 기록되고, 너무 길면 테스트 전체의 대기 시간이 늘어납니다. 현재 클라이언트 값을 기준으로 같은 네트워크에서 반복 측정한 결과를 보고 조금씩 조정하세요. 가장 짧은 숫자만을 목표로 바로 바꾸지 마세요. 셀룰러 네트워크 전환, 기기 절전 해제 직후 또는 서버 도메인이 아직 확인되지 않은 경우 첫 테스트에 추가 준비 시간이 포함될 수 있으므로 이후 결과와 구분해 기록하세요. 항목에 단위가 있다면 변경 전에 밀리초인지 초인지 확인하고 다른 항목의 숫자를 그대로 복사하지 마세요.

현재 플랫폼에서 동시 테스트를 조절할 수 있다면 서버를 너무 많이 한꺼번에 테스트하지 마세요. 네트워크와 기기 자원을 점유하거나 원격 측의 제한을 유발할 수 있습니다. 서버 하나를 확인할 때는 먼저 단독으로 테스트한 뒤 정상 작동이 확인된 소수의 비교 대상과 결과를 비교하세요. 순서가 바뀌었다고 고장 증거는 아닙니다. 짧은 시간 동안의 변동만으로도 순서가 달라질 수 있습니다. 목록을 보기 좋게 만들기 위해 테스트 대상을 계속 바꾸지 마세요. 앞뒤 데이터의 공통 기준이 사라져 네트워크가 개선됐는지, 단지 응답이 더 빠른 탐지 대상을 바꿨는지 판단할 수 없습니다.

테스트와 실제 접속 결과를 함께 확인하세요

유효한 검증에는 서로 구분되는 세 가지 확인이 포함되어야 합니다. 서버 탐지가 성공했는지, 연결이 수립됐는지, 대상 요청이 완료됐는지 살펴보세요. 사용자가 보유한 서버에서 Connectivity Test를 실행한 뒤 해당 서버를 선택해 연결하고, 마지막으로 고정된 대상을 요청해 Log를 확인합니다. 세 단계는 같은 네트워크에서 진행하고 중간에 구독을 업데이트하지 마세요. 탐지는 실패했지만 연결과 대상 요청이 정상이면 테스트 설정을 기록하는 데 그치세요. 목록의 상태를 바로잡으려고 실제 연결을 망가뜨리지 마세요.

웹페이지는 열리지만 대용량 파일 전송이 느릴 때는 탐지 시간만으로 지속적인 전송 성능을 판단할 수 없습니다. 처리량은 대상 서비스, 네트워크 혼잡, 프로토콜 설정과 원격 처리 성능에도 영향을 받습니다. 한 번 응답 시간이 짧았다고 장시간 연결의 안정성이 입증되는 것도 아닙니다. 비교하려면 같은 대상과 비슷한 시간대의 결과를 사용하고 업로드, 다운로드와 연결 끊김을 기록하세요. Hysteria2의 전송 방식은 Hysteria2 프로토콜 기술 노트를 참고할 수 있지만, 프로토콜 설명이 특정 회선의 성능을 보장하지는 않습니다.

테스트가 끝나면 테스트 대상, 시간 제한 및 동시 테스트 설정을 원래대로 복구하거나 변경 사항을 유지할 이유를 기록하세요. 도움을 요청할 때는 숫자 하나만 제시하기보다 테스트 방식, 네트워크 유형, 문제가 반복되는지, 실제 접속은 성공하는지 함께 알리는 편이 유용합니다. 전체 구독 주소나 서버 인증 정보는 첨부하지 마세요. 특정 네트워크에서만 문제가 발생한다면 같은 기기를 다른 네트워크에서 테스트한 결과도 남기세요. 다음 단계는 네트워크 조건 확인이며, 모든 서버 정보가 잘못됐다고 바로 판단하지 마세요.

시간 범위를 정한 뒤 오류를 확인하세요

Log는 연결 과정을 관찰할 수 있는 이벤트로 나누기 위한 기능이지, 텍스트를 많이 모으기 위한 기능이 아닙니다. 문제를 살펴보기 전에 시간을 기록하고 다른 앱의 동작을 최소화한 뒤, 재현할 실패 동작을 한 번만 실행하고 해당 기록을 확인하세요. 시간 범위를 정하지 않으면 백그라운드 요청, 시스템 연결 확인과 대상 앱의 재시도가 뒤섞이기 쉽습니다. 기록에 오류가 있다고 해서 그것이 현재 문제의 원인이라고 단정하지 마세요. 대상, 서버, 시간과 이번 작업이 서로 맞는지 먼저 확인하세요.

로그 스위치, 상세 수준 및 보관 방식은 현재 Settings와 각 플랫폼의 실제 지원 범위를 기준으로 확인하세요. 모든 플랫폼에 같은 수준 설정이 제공된다고 가정하지 마세요. 평소에는 클라이언트의 기존 설정을 유지하는 것이 좋습니다. 더 자세한 정보가 필요하면 기록 범위를 잠시 늘려 문제를 재현한 뒤 원래대로 되돌리세요. 장시간 기록은 저장 공간과 처리 부담을 늘리고 민감한 정보도 더 많이 쌓을 수 있습니다. 로그 설정을 바꾸려면 연결을 다시 만들어야 하는 경우 관련 기록을 먼저 저장하세요. 재시작 과정에서 원인을 보여 주던 기록이 사라지지 않도록 주의하세요.

DNS 조회, 연결, 인증, 대상 응답 단계 구분

먼저 DNS 조회를 확인하고, 원격 연결이 수립됐는지, 프로토콜 인증이 완료됐는지 살펴본 다음 대상 요청과 응답을 확인하세요. 이름을 확인할 수 없다면 DNS를 먼저 점검하고, 연결 단계에서 반복적으로 시간 초과가 발생하면 현재 네트워크와 서버 연결 가능 여부를 확인하세요. 인증 관련 오류는 사용자가 보유한 서버 정보를 확인해야 합니다. 대상에서 콘텐츠나 상태를 반환했다면 대상 서비스의 동작을 추가로 살펴보세요. 모든 timeout을 같은 원인으로 취급하지 마세요. 같은 단어가 서로 다른 단계에서 나타날 수 있으며 해결 방법도 다릅니다.

규칙을 진단할 때는 요청 대상, 일치한 규칙과 정책을 함께 살펴보세요. 브라우저에서 페이지 하나를 열어도 이미지, 스크립트와 다른 도메인을 동시에 요청할 수 있으므로 주소창의 이름만 검색해서는 충분하지 않습니다. 어떤 요청이 REJECT됐더라도 페이지 전체가 실패한 원인이라고 단정할 수 없습니다. 해당 요청이 필수 리소스인지 먼저 확인하세요. 현재 기록에 없는 항목을 추측해 채우지 마세요. 재현 범위를 좁혀 같은 대상을 다시 요청하고, Config에서 일치했을 가능성이 높은 규칙 위치를 확인하세요.

Data 수치는 집계 범위와 함께 확인하세요

Data 수치는 현재 화면, 집계 시작 시점과 초기화 작업을 함께 고려해야 합니다. 서버 기준 보기와 앱 기준 보기는 서로 다른 질문에 답하며, 각 화면의 숫자를 같은 기준의 트래픽으로 단순 비교해서는 안 됩니다. 소량의 업로드와 다운로드는 핸드셰이크, 재시도 또는 백그라운드 요청일 수 있으며 웹페이지 로딩 완료를 입증하지 않습니다. 누적량이 늘어도 특정 규칙을 통해 대상에 연결됐다는 뜻은 아닙니다. 서버와 앱을 고정한 다음 통제된 작업으로 증가량을 관찰하세요. 과거 누적값으로 방금 발생한 문제를 설명하지 마세요.

초기화가 필요하다면 현재 버튼이 어떤 범위에 적용되는지 확인하고 초기화 전 결과를 기록하세요. 실패할 때마다 모든 통계를 지우면 시간에 따른 연관성을 놓칠 수 있습니다. 앱별 통계 항목이 보이지 않으면 플랫폼 지원 여부, 현재 연결을 통해 트래픽이 전달되는지, 선택한 화면을 확인하세요. 존재하지 않는 앱별 증거를 추측해서 만들지 마세요. 구체적인 수치 해석은 Data 트래픽 통계 안내를 참고하세요. 통계는 요청 기록을 대신하는 것이 아니라 Log와 함께 문제를 좁히는 데 사용됩니다.

공유 전에 민감한 정보를 최소화하세요

로그에는 전체 도메인, 요청 경로, 구독 매개변수, 서버 주소, 기기 정보와 사용자 식별 정보가 포함될 수 있습니다. 공유하기 전에 문제와 관련된 짧은 부분만 남기고 인증 정보와 개인을 식별할 수 있는 내용을 가리세요. 본인의 구독이라도 전체 주소를 일반 텍스트처럼 공개하지 마세요. 단계 이름, 오류 문구와 상대 시간만으로도 문제를 설명할 수 있는 경우가 많습니다. 진단이 끝나면 로그 범위를 원래대로 돌리고 내보낸 파일도 필요에 따라 정리해 문제 해결 자료가 인증 정보를 장기간 보관하는 사본이 되지 않도록 하세요.

Widget은 실행 진입점이지 네트워크 테스트 결과가 아닙니다

Widget을 사용하면 시스템이 제공하는 화면에서 클라이언트 관련 상태를 확인하거나 조작할 수 있습니다. 실제 모양, 가능한 조작과 새로고침 동작은 기기 시스템과 클라이언트 지원 여부에 따라 다릅니다. Widget은 별도의 연결 설정이 아니며 Home에서 서버를 선택하는 작업을 대신하지 않습니다. Widget에 연결됨으로 표시되어도 대상 요청으로 접속 여부를 확인하세요. 상태가 아직 갱신되지 않았다고 연결이 끊겼다고 단정하지 마세요. 시스템이 새로고침 빈도를 제한할 수 있어 화면 표시와 실제 네트워크 상태 사이에 시간차가 생길 수 있습니다.

Widget을 기본으로 추가할지는 사용자의 시스템 화면 설정에 따라 달라지며, 클라이언트에서 모두 자동으로 켜진다고 안내해서는 안 됩니다. 먼저 앱에서 연결을 확인한 뒤 필요한 실행 진입점을 추가하세요. 시스템에서 여러 크기나 조작 항목을 제공한다면 현재 필요한 것만 선택하면 됩니다. 모든 항목을 추가할 필요는 없습니다. 연결 또는 연결 해제 동작을 실행한 뒤 Home과 시스템 VPN 상태를 확인하세요. On Demand 조건이 계속 충족되면 수동으로 연결을 끊은 뒤 다시 연결될 수 있습니다. Widget을 반복해서 제거하기보다 자동 연결 조건을 확인하세요.

동기화 전에 무엇을 동기화할지 확인하세요

iCloud 동기화는 지원되는 데이터가 여러 기기에서 연결된 상태로 유지되도록 돕지만, 모든 Settings, 시스템 권한, Widget 배치와 실행 상태가 함께 이전된다고 가정하지 마세요. 동기화할 수 있는 항목은 동기화 화면의 설명과 실제 결과를 기준으로 확인하세요. 시스템 VPN 권한은 기기별 설정입니다. 한 기기에서 서버를 사용할 수 있다고 해서 다른 기기에서도 같은 권한 설정이 끝난 것은 아닙니다. 기기를 처음 옮길 때는 ‘자료가 나타났는지’와 ‘연결을 수립할 수 있는지’를 별도로 확인하세요.

동기화를 켜기 전에 로컬 설정 사본을 보관하고, 기기가 예상한 iCloud 계정을 사용 중인지, 시스템에서 앱의 iCloud 사용을 허용하는지, 네트워크에서 동기화가 가능한지 확인하세요. 계정이 같다고 동기화가 완료된 것은 아닙니다. 시스템 제한, 저장 공간 상태와 백그라운드 실행 조건 때문에 결과가 늦어질 수 있습니다. 초기 동기화 설정과 데이터 범위는 실제 화면을 기준으로 확인하세요. 설정 몇 개를 복사하려고 동기화 전체를 서둘러 켤 필요는 없습니다. 특정 파일만 필요하다면 클라이언트가 지원하는 가져오기·내보내기 절차를 이용하고 민감한 정보는 안전하게 보관하세요.

항목 하나를 바꿔 동기화 범위를 확인하세요

먼저 인증 정보가 없고 알아보기 쉬운 설정 이름이나 일반 환경설정을 확인용으로 선택하세요. 한 기기에서 바꾼 뒤 다른 기기에 변화가 표시되는지 기다려 방향과 범위를 확인한 다음 중요한 데이터를 다루세요. 두 기기에서 같은 파일을 동시에 편집하지 마세요. 어느 사본이 의도한 내용인지 판단하기 어렵습니다. 충돌이나 중복 항목이 나타나면 편집을 멈추고 양쪽 내용을 보관한 뒤 하나씩 비교하세요. 마지막으로 표시된 사본이 가장 최신이며 완전한 데이터라고 바로 판단하지 마세요.

다른 기기에 서버가 표시되지만 연결되지 않으면 동기화를 바로 껐다 켜지 말고 해당 기기의 네트워크와 권한부터 확인한 뒤 서버 매개변수가 완전한지 살펴보세요. 같은 자료라도 두 기기의 결과가 다르면 시스템 네트워크, DNS 또는 프로토콜 지원 여부가 원인일 수 있습니다. 복구할 때는 미리 보관한 로컬 사본을 사용하고, 복구 내용이 다른 기기에도 다시 동기화되는지 확인하세요. 삭제, 교체 및 동기화 범위를 이해한 뒤 작업해 로컬 문제 해결이 기기 간 데이터 변경으로 번지지 않게 하세요.

구입 복원과 설정 동기화는 따로 처리하세요

iPhone / iPad의 구입 복원은 다운로드 페이지의 구입 항목 복원 안내에 따라 진행하세요. iCloud에 설정이 있다고 스토어 구입 상태가 복원된 것은 아니며, 앱을 복원했다고 로컬 자료가 모두 보존됐다는 뜻도 아닙니다. iPhone / iPad 버전은 App Store에서 $2.99에 한 번 구매하며, Mac, Windows, Android, Linux 버전은 무료입니다. 앱 구입과 사용자가 보유한 회선 정보는 별개입니다. 기기를 바꾸기 전 설정 사본을 보관하고, 새 기기에서 권한을 확인한 뒤 구입 복원 및 다시 다운로드 안내를 살펴보세요. 서로 다른 시스템의 계정 및 데이터 절차를 혼동하지 않는 데 도움이 됩니다.

로컬 연결 진입점과 원격 서버 포트는 다릅니다

Proxy 관련 포트는 먼저 용도를 구분해야 합니다. Add Server의 포트는 사용자가 보유한 원격 서버 정보에 속하고, 로컬 Proxy 수신 포트는 클라이언트가 다른 프로그램에 제공하는 연결 진입점입니다. 둘 다 포트라고 부르지만 값을 서로 옮겨 적을 수는 없습니다. 원격 포트는 보유한 서버 정보를 따르고, 로컬 포트는 해당 진입점을 사용하는 프로그램과 일치해야 합니다. 현재 플랫폼에서 HTTP, SOCKS5 또는 다른 로컬 연결을 제공하는지, 별도 스위치가 필요한지는 Settings의 실제 옵션을 기준으로 확인하세요. 모든 플랫폼이 같다고 가정하지 마세요.

수신 주소와 포트에는 플랫폼을 아우르는 공통 권장 숫자가 없습니다. 현재 값과 앱 안내를 먼저 확인하세요. 같은 기기에서만 로컬 프록시를 사용한다면 기기 내부에서만 접근할 수 있는 범위를 우선 유지하세요. 명확한 용도가 없다면 로컬 네트워크까지 수신 범위를 넓히지 마세요. 다른 기기에서 접근해야 한다면 클라이언트가 해당 기능을 지원하는지, 시스템 네트워크에서 허용하는지, 접근 제어와 인증 옵션이 있는지 확인하세요. 수신 범위를 넓히는 것은 단순히 연결을 편하게 만드는 일이 아닙니다. 같은 네트워크의 다른 기기가 이 진입점에 접근할 수 있으므로 누가 연결할 수 있는지와 서비스 중지 방법을 정해야 합니다.

주소, 프로토콜 및 포트는 함께 일치해야 합니다

로컬 진입점을 사용하는 프로그램에는 올바른 프로토콜, 주소와 포트를 모두 입력해야 합니다. 포트 숫자가 같아도 HTTP 진입점을 SOCKS5 진입점처럼 사용할 수는 없습니다. 원격 서버 주소를 이 기기의 수신 주소 대신 입력해서도 안 됩니다. 같은 기기에서 루프백 주소로 접속하는 경로와 다른 기기에서 해당 기기의 로컬 네트워크 주소로 접속하는 경로는 서로 다릅니다. 다른 기기에서 그 기기 자신의 루프백 주소를 입력하면 실행 중인 Shadowrocket 기기가 아니라 해당 기기 자신에 접속합니다. 문제를 진단할 때는 먼저 요청을 보내는 기기가 무엇인지, 진입점이 실제로 어느 기기에 있는지 확인하세요.

포트 충돌이 있으면 수신을 시작하지 못하거나 다른 로컬 프로그램이 요청을 받을 수 있습니다. 포트를 바꾸기 전에 원래 값을 기록하고 새 포트를 사용 중인 프로그램이 없는지 확인하세요. 변경한 뒤에는 해당 진입점을 사용하는 모든 프로그램의 설정도 업데이트하고 다시 테스트하세요. 한쪽만 바꾸면 클라이언트 연결은 정상이어도 호출 프로그램은 이전 진입점을 계속 요청할 수 있습니다. 로컬 프록시 제공을 중지한 뒤에는 호출 프로그램의 프록시 설정도 복구하세요. 그렇지 않으면 닫힌 포트에 계속 연결을 시도해 시스템 네트워크 전체에 문제가 생긴 것처럼 보일 수 있습니다.

문제 범위에 따라 확인 순서를 정하세요

모든 앱에서 접속이 실패하면 기본 네트워크, 시스템 VPN 상태, 선택한 서버와 인증 정보를 먼저 확인하세요. 로컬 진입점을 사용하는 프로그램에서만 실패한다면 프로토콜, 수신 주소, 포트와 접근 범위를 살펴보세요. 특정 대상만 실패하면 DNS, Global Routing과 일치한 규칙을 확인하세요. 이렇게 범위를 나누면 관련 없는 설정을 바꾸는 일을 줄일 수 있습니다. 로컬 네트워크의 다른 기기가 진입점에 접속하지 못한다면 같은 네트워크에 있는지, 방문자 네트워크 격리나 시스템 방화벽이 적용되는지 확인하세요. 원격 서버 테스트 성공만으로 로컬 네트워크 진입점도 접속 가능하다고 증명할 수는 없습니다.

완전히 복구한다는 것은 모든 항목을 초기화한다는 뜻이 아닙니다. 최근 변경을 되돌리고 기존 Global Routing과 Config를 복구한 뒤 DNS와 On Demand를 확인하세요. 마지막으로 호출 프로그램에 로컬 프록시 설정이 남아 있는지 살펴보세요. 각 계층을 복구할 때마다 고정된 대상에 요청을 보내 결과가 달라지는 지점을 찾으면 추가 변경을 멈추세요. 기준 상태로 돌아가도 문제가 계속되면 관련 Log의 짧은 부분과 테스트 조건을 보관한 뒤, 사용자가 보유한 구독이 업데이트됐는지와 서버 정보가 바뀌었는지 확인하세요. 모든 자료를 삭제하고 운에 맡기지 마세요.

재설치하거나 플랫폼을 바꿔야 한다면 전체 플랫폼 다운로드에서 다운로드하고 시스템 설치 허용 안내를 확인하세요. Windows에서는 파일 출처를 확인한 뒤 SmartScreen 안내에 따라 진행하고, Mac에서는 출처를 확인한 뒤 시스템의 개인정보 보호 및 보안 설정에서 안내에 따라 허용하세요. Android에서는 시스템 안내에 따라 해당 설치 출처 권한을 부여하세요. 설치 후에는 빠른 시작 가이드를 따라 기본 연결을 복구한 다음 이 페이지의 설정을 하나씩 적용하세요. 모드별 차이를 이해하려면 프록시 모드 안내를 계속 읽고, 임시로 유효했던 진단 설정을 장기 설정으로 그대로 사용하지 마세요.