어느 쪽이 오르는지 보세요. 아이콘이 켜졌는지는 아닙니다.

홈에는 여러 가지가 동시에 켜집니다. 스위치, 정책, Data, 목록 옆 밀리초입니다. 눈은 그것을 「연결됐다」 「연결 안 됐다」 한 문장으로 접습니다. 오독의 시작입니다. 네 신호는 독립입니다. 어느 하나를 다른 것의 별칭으로 보면 이후 판단이 모두 뒤집힙니다. 완전한 대조는 매뉴얼 Data 장에 있습니다. 이 글은 Data 한 묶음만 쪼개고, 왜 아이콘보다 볼 가치가 있는지를 씁니다.

스위치가 답하는 것은 Network Extension이 떴는지입니다. 켜진 채 상태 표시줄에 VPN 아이콘이 있는 것은 터널 층이 살아 있다는 뜻일 뿐입니다. 정책이 답하는 것은 터널에 들어간 뒤 규칙을 물을지입니다. Config만 규칙을 돌리고, Proxy는 현재 레코드로 강제하며, Direct는 원래 경로로 강제합니다. 목록 프로브가 답하는 것은 이 홉이 지금 프로브되는지입니다. Data가 답하는 것은 이미 일어난 바이트가 Direct인지 Proxy인지입니다. 네 질문이 한 관찰에 겹치고 첫 질문만 보면 「이미 연결됐는데 왜 안 되나」라는, 손을 댈 수 없는 결론이 납니다.

VPN 아이콘은 특히 속이기 쉽습니다. 스위치에 묶이고 정책에는 묶이지 않습니다. Direct에서도 아이콘은 켜질 수 있고 요청은 셀룰러나 Wi-Fi 원래 경로로 나가 하이라이트한 레코드를 전혀 거치지 않습니다. 아이콘을 「노드를 탔다」는 증거로 쓰면 터널의 존재로 출구 사용을 대신한 것입니다. 터널이 어떻게 켜지는지는 터널을 보세요.

Data에는 카운터가 둘이고 이름은 Direct와 Proxy입니다. 기기에 쓰이며 이미 일어난 바이트를 셉니다. 요금제 잔량이 아니고 제3자 계정에 얼마나 남았는지도 보이지 않으며, 리셋하면 0부터 다시 세고 대향 쿼터는 움직이지 않습니다. Data를 「노드에 몇 GB 남았나」로 보면 숫자가 클 때도 작을 때도 전혀 무관한 결정을 내립니다.

한 번 방문한 뒤 분명히 늘어나야 하는 것은 한쪽뿐입니다. 현재 레코드에 들어가야 한다고 생각하는 호스트로 간 뒤 바로 봅니다. Proxy가 늘면 바이트가 이 레코드에 들어간 것입니다. 페이지가 아직 실패하면 문제는 대향, 이름 해결, 이 App이 터널을 거절하는 경우가 많고 「노드를 안 탄 것」이 아닙니다. 그때 규칙을 고치는 것은 이미 레코드를 탔다고 증명된 경로를 고치는 것입니다. Direct만 늘면 요청이 원래 경로에 남은 것입니다. 레코드로 넣을 생각이었다면 정책이 Direct인지, Config 아래 규칙이 먼저 DIRECT / REJECT로 썼는지를 보세요. 규칙입니다.

둘 다 거의 안 움직이면 요청이 터널에 안 들어갔을 수 있습니다. 스위치가 안 잡혔거나, 시스템에 쓸 VPN 구성이 없거나, 다른 VPN이 칸을 차지했거나, 아예 송신이 없는 경우입니다. 비행기 모드, 포털 페이지가 안 끝남, 앱이 로컬 캐시를 도는 경우 등입니다. 먼저 스위치와 시스템을 보고 레코드를 의심하세요.

REJECT가 맞으면 성공한 로드처럼 카운터를 밀어 올리지 않는 경우가 많습니다. 앱이 오류, Data가 조용한 것은 「노드에 트래픽이 없다」와 닮았습니다. 정책을 Proxy로 바꿔 한 번 더 방문해야 「규칙이 버린 것」과 「레코드 핸드셰이크 실패」가 갈립니다. 전자는 Proxy에서 통하고 후자는 Proxy에서도 실패합니다.

두 카운터는 좌우만 나누고 「어느 레코드인지」는 나누지 않습니다. 하이라이트를 바꾸기 전 Proxy 숫자는 남고 줄마다 0이 되지 않습니다. 카운트를 어떤 줄에 대응시키려면 먼저 리셋하고 그 줄을 고정해 한 번 방문합니다. 열 페이지를 연 뒤 합계를 보면 Direct와 Proxy가 모두 움직여 어떤 한 번에 대응할 수 없습니다. 가르는 단위는 「한 번 방문」이지 「오후 한나절」이 아닙니다.

목록에서 한 줄을 고른 뒤 Direct → Proxy → Config 순으로 자릅니다. 동시에 레코드를 바꾸고 FINAL을 고치고 컨테이너를 새로고침하지 마세요. Direct에서는 기기 방문과 포털 인증 페이지가 되어야 합니다. 여기서 이미 망이 없으면 먼저 Wi-Fi, 셀룰러, 로그인 페이지를 처리하고 레코드와 무관합니다. Proxy에서 레코드로 보낼 호스트가 열리면 터널과 이 레코드는 앱 층에서 쓸 수 있습니다. 여기서도 안 열리면 문제는 레코드나 대향이며 규칙을 먼저 고치지 마세요. Config는 Proxy가 레코드를 쓸 수 있다고 증명한 뒤에만 조정하고, 한 번에 조건 하나, Data로 카운터가 어느 쪽에 서는지를 봅니다.

이 순서의 용도는 귀속입니다. Direct가 실패하면 로컬 망을 고칩니다. Proxy가 실패하면 레코드를 고칩니다. Config가 실패하고 Proxy가 성공하면 규칙을 고칩니다. 세 단계를 동시에 하면 화면의 매번 변화를 나머지 두 변수로 설명할 수 있어 설명이 없습니다. 매뉴얼은 같은 순서를 Data 장에 넣습니다. 이 글이 강조하는 것은 아이콘이 이 세 단계 어느 것에도 관여하지 않는다는 점입니다.

시스템 시각이 자동 설정이 아니면 TLS가 한꺼번에 실패하고 스위치는 어떤 레코드에서도 이상해 보이며 프로브도 같이 깨집니다. 먼저 시각 「자동 설정」을 켠 뒤에 레코드를 이야기하세요. 목적지가 IPv6이고 규칙이 IPv4 IP-CIDR만 적혀 있으면 요청은 FINAL로 떨어져 규칙이 「가끔 먹히는」 것처럼 보입니다. DNS를 보세요. 다른 VPN이 연결 중이면 시스템이 이 확장에 트래픽을 넘기지 않을 수 있습니다. 스위치가 켜져 있어도 바이트가 Shadowrocket에 들어간 것이 아니며 Data 둘 다 안 움직입니다.

아이콘이 켜지고, 프로브가 작고, 페이지가 실패하고, Data는 Direct만 오름. 네 가지는 동시에 참일 수 있습니다. 첫 가지만 보면 행동할 수 없는 결론이 나고, 넷을 같이 보면 결론은 정책이나 규칙이 이번 방문을 원래 경로에 남긴 것입니다. 다음 손은 그 줄을 고정하고 정책만 움직이는 것이지, 새 레코드를 사거나 새 목록을 가져오는 것이 아닙니다.

또 하나의 흔한 오독은 Data의 Proxy 숫자를 「오늘 요금을 얼마나 썼나」로 읽는 것입니다. 그 숫자는 이 기기가 현재 레코드 또는 이전에 하이라이트한 레코드로 한때 몇 바이트를 보냈는지만 말합니다. 사이트별로 쪼개지지 않고 직접 리셋하지 않으면 날짜로도 0이 되지 않습니다. 레코드를 바꿔 다시 방문하면 새 증분은 옛 Proxy 위에 쌓입니다. 「이 줄이 되나」에 답하려면 먼저 리셋하고 한 번만 방문하고 어느 쪽이 움직였는지를 봐야 합니다. 리셋 없이 줄을 바꾸고 여러 App을 열어 두면 어느 줄도 유죄로 만들 수 없는 뒤섞인 합계가 됩니다.