블로그
하이라이트할 수 있는 것은 출구입니다. 새로고침만 되는 것은 URL입니다.
홈 목록에 보이는 것은 보통 두 종류입니다. 스위치를 켜면 쓰는 것은 지금 하이라이트된 레코드뿐입니다. Subscribe는 컨테이너입니다. 안은 URL이고 자식 레코드는 새로고침 뒤에 나타납니다. 규칙 구성은 세 번째이며 이 열에는 나오지 않습니다.
세 오브젝트
서로 바꾸지 않습니다
하이라이트 행을 바꿔도 규칙은 바뀌지 않고, 규칙을 바꿔도 하이라이트 행은 바뀌지 않으며, 컨테이너를 새로고침해도 FINAL은 바뀌지 않습니다. 이 셋을 「한 번 가져온 세 복사」로 보면 이후 대조가 모두 흐트러집니다. 칸 설명은 오브젝트와 Config에 있습니다. 이 글이 다루는 것은 관찰상의 오류 하나입니다. 목록이 비었거나 줄이 많은 것을 보고 출구가 이미 준비됐거나 이미 깨졌다고 생각하는 것입니다.
레코드에는 주소, 포트, 프로토콜, 인증, 전송이 있습니다. 하이라이트할 수 있습니다. 「새로고침」은 없습니다. 대향이 포트를 바꿔도 로컬 이 줄은 스스로 변하지 않습니다. 편집하거나 지우고 다시 만들 뿐입니다. 유형은 이 레코드의 신원이지 라벨이 아닙니다. Trojan을 고르고 비밀번호가 Shadowsocks여도 저장은 됩니다. 터널 핸드셰이크는 실패합니다. 전송은 레코드 자신의 것입니다. 대향이 WebSocket인데 로컬이 TCP로 남고, 경로, Host, gRPC 서비스 이름을 다른 세트로 채우면 저장은 되고 핸드셰이크는 안 됩니다. 가를 때는 「프로토콜 유형」과 「전송」을 독립 점검 항목으로 두고 주소와 포트만 대조하지 마세요.
SNI, 인증서 검증 건너뛰기, 지문이 TLS가 끝날 수 있는지를 정합니다. 인증서는 시스템 시각에도 의존합니다. 시각이 자동 설정이 아니면 TLS에 의존하는 레코드가 한꺼번에 실패하고 줄을 바꿔도 소용없습니다. 레코드가 서술하는 것은 출구 하나입니다. 규칙을 포함하지 않고 「연결된 뒤 자동으로 다른 줄로 바꾼다」도 포함하지 않습니다. 목록 프로브의 밀리초는 이 홉이 지금 프로브되는지만 말합니다. Data를 보세요.
컨테이너
저장과 새로고침은 두 단계
컨테이너가 저장하는 것은 URL입니다. 저장 단계에서는 자식 레코드를 받지 않습니다. 저장 직후 집합이 비어 있어도 컨테이너로서는 정상이며 「구독이 깨진 것」이 아닙니다. 가져오는 것은 새로고침입니다. 성공하면 반환 내용으로 자식 레코드를 만들거나 바꾸고, 그 자식은 보통 레코드처럼 하이라이트할 수 있습니다. 실패해도 이미 있는 줄을 실패 때문에 지우지 않습니다. 보이는 것은 직전에 성공한 집합이며 만료됐을 수 있지만 아직 있습니다.
열 때 새로고침, 백그라운드 새로고침은 모두 「새로고침」의 반복입니다. 백그라운드가 돌 수 있는지는 시스템이 이 앱의 백그라운드 새로고침을 허용하는지, 기기가 절전인지도 봅니다. 그것은 시스템 경계이지 컨테이너 스위치가 꺼진 것이 아닙니다. 새로고침 요청은 그때의 네트워크 경로를 탑니다. 스위치가 만료된 레코드에 붙어 있으면 새로고침 자체도 실패할 수 있습니다. 정책을 Direct로 바꾸거나 스위치를 먼저 끄는 것은 경로를 격리하는 것이지 URL을 고치는 것이 아닙니다. URL이 404, 401, 빈 파일을 반환하면 클라이언트는 실패를 보고할 수만 있고 대향 링크를 이어 주지 못합니다.
구독 URL을 브라우저로 열면 웹페이지로 볼 수 없는 내용이 나오는 일이 많습니다. 클라이언트가 파싱하기 위한 것입니다. 브라우저가 바이트를 받으면 경로는 통하고 링크 자체는 살아 있습니다. 브라우저에서도 안 열리면 문제는 망이나 링크이지 Shadowrocket 파서가 아닙니다. ss://, vmess://, trojan://는 칸을 한 줄로 묶습니다. 추가 입구에 통째로 붙이면 UUID를 손으로 베끼는 것보다 실수가 줄어듭니다. 「서버 주소」 한 칸에 통째로 붙이면 보통 URI로 파싱되지 않습니다.
스캔으로 얻는 것은 레코드 하나일 수도, 컨테이너 URL일 수도, 구성 다운로드 주소일 수도 있습니다. 저장한 뒤 하이라이트할 수 있는지를 봅니다. 하이라이트되고 칸이 호스트와 포트면 레코드입니다. 펼치기만 되고 안이 URL이면 컨테이너입니다. 서버 목록이 아니라 구성 목록에 들어가면 구성입니다. 같은 코드를 두 번 스캔하면 목록에 같은 레코드가 두 줄 생길 수 있습니다. 연결 때 쓰는 것은 하이라이트된 하나뿐이며 중복 줄은 대역을 더하지 않고 고를 기회만 늘립니다.
서버 컨테이너 새로고침이 바꾸는 것은 목록의 자식 레코드입니다. 규칙 / 구성 구독 새로고침이 바꾸는 것은 목록 파일입니다. URL은 닮아도 오브젝트는 하나가 아닙니다. 컨테이너를 새로고침해도 FINAL은 안 바뀌고, 규칙을 새로고침해도 하이라이트 행은 안 바뀝니다.
많은 줄
연결 때 쓰는 것은 한 줄
목록은 많은 레코드, 많은 컨테이너를 허용합니다. 연결 때 쓰는 것은 지금 하이라이트된 하나뿐입니다. 두 컨테이너는 자동으로 부하 분산하지 않고 「프로브 숫자가 가장 작은 줄」로 자동 선택하지도 않습니다. 프로브가 아무리 작아도 하이라이트되지 않으면 스위치를 켜도 쓰지 않습니다. 컨테이너를 지우면 그것이 만든 자식 레코드는 보통 함께 사라집니다. 지금 하이라이트가 이 컨테이너에 속하면 지운 뒤 다른 줄을 고르고 스위치를 켜세요.
컨테이너 안의 한 줄을 손으로 독립 레코드로 복사하면 이후 새로고침은 이 복사본을 건드리지 않습니다. 대향이 포트를 바꿔도 복사본은 따라가지 않으니 직접 편집합니다. 「한 줄을 얼리기」와 「URL을 계속 따르기」 사이의 선택입니다. 많은 컨테이너는 토큰을 경로에 둡니다. 스크린샷, 그룹 파일, 공개 드라이브에 나오면 자식 레코드 접근권을 넘긴 것입니다. 클라이언트는 이미 샌 URL을 폐기해 주지 않고 대향에 링크를 바꾸라고 알리지도 않습니다. 내보내기 백업도 인증 파라미터를 포함하니 비밀로 다루세요.
앱은 URL 유효기간을 늘리지 못하고, 서버 요금을 대신 내지 못하며, 핸드셰이크 실패한 레코드를 쓸 수 있게 만들지 못합니다. 시스템 장에서는 할 수 없는 일로 분류하며 못 찾은 설정 항목이 아닙니다. 앱을 넣은 직후 목록이 비어 있는 것도 정상입니다. 스토어 라이선스에 출구는 없습니다. 스토어를 보세요.
컨테이너를 레코드처럼 하이라이트하거나 레코드를 컨테이너처럼 새로고침을 기다리면 잘못된 오브젝트를 조작합니다. 전자는 출구가 될 수 없는 줄을 눌러 스위치를 켜도 핸드셰이크 대상이 없습니다. 후자는 손글씨 레코드가 목록을 당겨도 대향에서 포트를 가져오지 않습니다. 판정은 단순합니다. 이 줄에 호스트와 포트가 있고 현재 출구로 고를 수 있는가. 되면 레코드, 안 되고 URL만 보이면 컨테이너입니다. 구성 파일은 다른 입구에서 지금 체크된 것이 어느 것인지까지 확인합니다. 세 곳을 본 뒤에 「왜 페이지가 그대로인가」를 말합니다.