네트워크 가속을 처음 접하면 조작 버튼보다 구독, 노드, 회선, 프로토콜, 분할 라우팅 같은 용어가 더 헷갈리기 쉽습니다. 각각은 연결 과정의 서로 다른 단계에 해당합니다. 구독은 설정을 전달하고, 노드는 연결 진입점을 제공하며, 회선은 데이터가 통과하는 네트워크 경로를 정합니다. 프로토콜은 클라이언트와 서버의 통신 방식을 규정하고, 라우팅 규칙은 어떤 요청이 이 경로를 사용할지 결정합니다. 이 전체 흐름을 먼저 이해하면 클라이언트의 여러 옵션도 더 이상 따로 놀지 않습니다.
이 글에서는 실제 연결 과정을 바탕으로 각 개념의 관계를 설명하고, 직접 연결·중계·IEPL 전용 회선·전역 모드·규칙 모드·시스템 프록시·TUN 모드·DNS 누수가 무엇을 의미하는지 살펴봅니다. 약어를 외우는 것보다 문제가 발생한 단계에서 어디를 점검해야 하는지 아는 데 초점을 둡니다.
전체 연결 흐름부터 살펴보기
클라이언트를 열고 구독을 가져오면 클라이언트가 서버 주소, 포트, 프로토콜 매개변수, 노드 이름 등의 설정을 읽습니다. 노드를 선택해 연결한 뒤 애플리케이션의 요청은 먼저 클라이언트로 전달됩니다. 클라이언트는 현재 라우팅 모드에 따라 요청을 직접 보낼지, 캡슐화해 원격 노드로 넘길지 판단합니다. 원격 노드는 대상 서비스에 접속하고 응답을 같은 연결을 통해 돌려보냅니다.
애플리케이션 요청
→ 시스템 프록시 또는 TUN이 인계
→ 라우팅 규칙 판단
→ 직접 연결하거나 선택한 노드로 전달
→ 노드에 연결된 네트워크 회선
→ 대상 서비스
→ 같은 경로로 응답 반환이 과정에서 ‘노드’와 ‘회선’은 같은 말이 아닙니다. 노드는 일반적으로 클라이언트에서 선택할 수 있는 연결 설정으로, 호스트·포트·프로토콜 등의 정보를 포함합니다. 회선은 노드 뒤에 있는 네트워크 경로를 뜻합니다. 같은 지역에 여러 회선이 제공될 수 있고, 하나의 회선에 여러 접속 진입점이 연결될 수도 있습니다. 노드 이름만으로 실제 경로를 완전히 판단할 수 없으므로 서비스 제공업체가 안내하는 회선 유형과 사용 환경을 함께 확인해야 합니다.
구독·설정·노드란 무엇인가
구독은 업데이트 가능한 설정 진입점입니다
구독은 보통 하나의 링크 형태로 제공되며, 클라이언트의 로그인 상태를 통해 가져오는 경우도 있습니다. 클라이언트가 구독에 접속하면 여러 노드 설정과 관련 매개변수를 받습니다. 서버에서 노드 주소, 회선 이름 또는 사용 가능한 설정을 조정해도 사용자는 클라이언트에서 ‘구독 업데이트’를 실행하면 되므로 항목을 하나씩 다시 입력할 필요가 없습니다.
구독 링크는 일반 공개 웹페이지 주소가 아닙니다. 구독 식별에 사용되는 인증 정보가 포함될 수 있으므로 비밀번호처럼 안전하게 보관하고 공개 페이지, 스크린샷 또는 공유 문서에 게시하지 마세요. 링크가 유출되었다고 의심되면 서비스 패널에서 다시 생성하거나 지원 채널에 문의해야 합니다.
클라이언트의 ‘로컬 설정’과 ‘구독 설정’도 구분해야 합니다. 사용자가 직접 만든 노드는 보통 해당 기기에만 저장되고, 구독으로 받은 노드는 구독 소스에서 관리합니다. 일부 클라이언트는 구독을 업데이트할 때 구독 노드에 적용한 로컬 수정 사항을 덮어쓸 수 있으므로, 구독 노드에 사용자 지정 매개변수를 장기간 저장하는 것은 적합하지 않습니다. 조정이 필요하다면 클라이언트의 오버라이드, 규칙 세트 또는 별도 설정 기능을 사용하세요.
노드는 연결 가능한 매개변수 묶음입니다
노드에는 최소한 연결 대상과 통신 방식을 클라이언트가 알 수 있도록 하는 정보가 필요합니다. 프로토콜마다 필요한 필드가 다르며, 일반적으로 서버 주소, 서버 포트, 인증 정보, 전송 방식, TLS 설정, 서버 이름 등이 포함됩니다. 클라이언트는 이 필드들을 선택 가능한 항목으로 조합하고 지역 또는 회선 이름을 사용해 식별을 돕습니다.
노드에 표시된 지역은 보통 출구 또는 회선 위치를 설명하는 데 사용되지만, 애플리케이션이 최종적으로 지역을 판단하는 방식은 출구 IP 데이터베이스, DNS 확인 결과, 브라우저 저장 정보, 계정 정보, 시스템 시간대 등의 영향을 받습니다. 따라서 노드 이름만으로 지역을 판단할 수는 없습니다. 출구를 확인하려면 연결 후 IP 검사에서 공인 주소와 DNS 결과를 확인하세요.
구독 업데이트와 클라이언트 업그레이드는 다릅니다
‘구독 업데이트’는 노드와 규칙 등의 설정을 다시 가져오는 작업이고, ‘클라이언트 업그레이드’는 새 버전의 프로그램을 설치하는 작업입니다. 구독에 클라이언트가 인식하지 못하는 프로토콜이 나타났다면 구독을 새로고침해도 해결되지 않습니다. 현재 클라이언트가 해당 프로토콜과 전송 매개변수를 지원하는지 확인해야 합니다. 반대로 클라이언트가 실행된다고 해서 구독 내용이 최신이라는 뜻도 아닙니다.
직접 연결·중계·IEPL 전용 회선의 차이
회선 유형은 로컬 네트워크에서 출구 노드까지 데이터가 지나가는 경로를 설명합니다. 공용 인터넷 혼잡, 네트워크 간 연동, 라우팅 변화의 영향을 받는 정도에 영향을 주지만, 이름만으로 모든 시간대의 실제 성능을 판단할 수는 없습니다. 회선을 평가할 때는 사용 지역, 대상 지역, 실제 이용 시간을 함께 고려해 테스트해야 합니다.
| 회선 유형 | 기본 경로 | 주요 특징 | 확인할 항목 |
|---|---|---|---|
| 직접 연결 | 로컬 네트워크에서 원격 노드로 직접 연결 | 구조가 단순하며 공용 인터넷 라우팅의 영향을 크게 받음 | 로컬 통신사와 대상 지역 간 연동 품질 |
| 중계 | 먼저 중계 진입점에 접속한 뒤 출구로 전달 | 품질이 좋지 않은 일부 공용 인터넷 구간을 우회할 수 있음 | 진입점 품질, 중계 경로와 출구 상태 |
| IEPL 전용 회선 | 국제 이더넷 전용 회선 또는 이에 준하는 전송 경로를 통해 연결 | 일반 공용 인터넷 직접 연결과 라우팅 구성 방식이 다름 | 서비스 제공업체가 표시한 진입점, 출구 및 사용 범위 |
직접 연결은 ‘로컬 애플리케이션이 프록시를 우회한다’는 뜻이 아닙니다. 노드 회선의 맥락에서는 사용자가 원격 서버에 직접 연결한다는 의미인 경우가 많지만, 라우팅 맥락에서 ‘DIRECT’는 요청이 프록시 노드를 거치지 않는다는 뜻입니다. 두 표현은 한국어 화면에서 비슷하게 보일 수 있어도 적용 계층이 다릅니다. 클라이언트 로그를 읽을 때는 노드 경로를 말하는지, 규칙 동작을 말하는지 먼저 구분하세요.
중계 회선은 하나 이상의 관리되는 전달 단계를 추가합니다. 핵심은 데이터를 단순히 ‘한 정거장 더’ 보내는 것이 아니라 진입점과 출구 사이의 경로를 다시 구성하는 데 있습니다. 로컬 네트워크에서 중계 진입점까지의 연결이 안정적이고 진입점에서 출구까지의 네트워크 품질이 좋다면, 중계가 공용 인터넷 직접 연결보다 지속적인 전송에 적합할 수 있습니다. 반대로 진입점 자체가 현재 네트워크와 맞지 않다면 결과가 달라질 수 있습니다.
IEPL은 International Ethernet Private Line의 약자로, 일반적으로 국제 이더넷 전용 회선을 뜻합니다. 이는 네트워크 전송과 회선 구성에 관한 개념이지 프록시 프로토콜이나 클라이언트가 지원해야 하는 별도 버튼이 아닙니다. 클라이언트는 여전히 Shadowsocks, Trojan, VLESS 등의 프로토콜로 진입점에 연결할 수 있으며, 이후 데이터는 서버 측 네트워크를 통해 전송됩니다. ‘IEPL 노드’는 IEPL이라는 암호화 프로토콜이 있다는 뜻이 아니라 노드 뒤에 해당 회선이 사용된다는 의미로 이해해야 합니다.
주요 프로토콜은 각각 어떤 문제를 해결할까
프로토콜은 클라이언트와 서버가 세션을 설정하고 인증하며 데이터를 암호화하거나 전송하는 방식을 규정합니다. 클라이언트와 서버가 동일한 프로토콜과 호환되는 매개변수를 지원해야 연결을 설정할 수 있습니다. 프로토콜 이름만으로 전체 설정을 대신할 수도 없습니다. 전송 계층, TLS, 서버 이름 및 기타 확장 매개변수가 호환성에 영향을 줄 수 있습니다.
Shadowsocks
Shadowsocks는 널리 사용되는 암호화 프록시 프로토콜로, 설정은 보통 서버, 포트, 비밀번호, 암호화 방식으로 구성됩니다. 구현에 따라 지원하는 암호화 방식이 다를 수 있습니다. 가져온 뒤 ‘지원하지 않는 암호화 방식’ 오류가 나타나면 라우팅 모드를 반복해서 바꾸기보다 클라이언트 버전과 코어 구현을 먼저 확인하세요.
VMess와 VLESS
VMess는 식별 정보와 프로토콜 구조를 갖춘 프록시 프로토콜로, 여러 전송 방식과 함께 사용되는 경우가 많습니다. VLESS는 더 가벼운 설계를 사용하며 자체적으로 완전한 전송 암호화를 제공하지 않습니다. 실제 배포에서는 보통 TLS 또는 다른 보안 전송 계층과 함께 사용합니다. 이름이 비슷해도 두 프로토콜의 설정 필드와 서버 구현을 임의로 바꿔 사용할 수는 없습니다.
구독을 가져온 뒤 노드는 보이지만 연결되지 않는다면 클라이언트가 전송 방식, TLS, 서버 이름, 경로 등의 매개변수를 모두 읽었는지 확인하세요. 서버 주소와 포트만 복사해서는 원래 설정을 완전히 재현하기 어려운 경우가 많습니다.
Trojan
Trojan은 일반적으로 TLS 연결 위에서 실행되며, 인증 정보·서버 이름·인증서 검증이 핵심 설정입니다. 시스템 시간이 크게 틀렸거나 서버 이름이 잘못 입력되었거나 인증서 검증에 실패하면 핸드셰이크가 완료되지 않을 수 있습니다. 문제를 확인한다는 이유로 인증서 검증을 장기간 끄는 것은 적절하지 않습니다. 시간, 도메인 또는 설정 출처를 바로잡으세요.
Hysteria2와 TUIC
Hysteria2와 TUIC는 모두 UDP 기반의 현대적인 전송 방식에 중점을 두며, 패킷 손실이나 변동이 있는 네트워크 환경에서 사용되는 경우가 많습니다. 로컬 네트워크, 라우팅 장비, 서버가 UDP를 정상적으로 지원해야 합니다. 같은 구독의 TCP 계열 프로토콜은 연결되는데 두 프로토콜만 계속 실패한다면 현재 네트워크가 UDP를 제한하는지, 클라이언트 코어가 호환되는지, 시스템 방화벽이 해당 프로그램의 통신을 허용하는지 확인하세요.
프로토콜을 선택할 때 새로운 약어만 좇을 필요는 없습니다. 이름보다 클라이언트 호환성, 회선 적합성, 현재 네트워크 조건이 더 중요합니다. 서비스 제공업체가 구독으로 매개변수를 제공했다면 먼저 원래 설정을 사용하고, 의미를 모르는 상태에서 전송 계층이나 보안 옵션을 임의로 변경하지 마세요.
시스템 프록시·TUN·애플리케이션 프록시
노드 연결 성공은 클라이언트와 서버 사이의 통로가 만들어졌다는 뜻일 뿐입니다. 이제 애플리케이션 트래픽이 클라이언트로 어떻게 들어올지 정해야 합니다. 일반적인 인계 방식으로는 시스템 프록시, TUN 모드, 애플리케이션 자체의 프록시 설정이 있습니다.
시스템 프록시
시스템 프록시는 프록시 주소를 운영체제의 네트워크 설정에 기록합니다. 시스템 프록시를 따르는 브라우저와 애플리케이션은 요청을 클라이언트에 전달하지만, 일부 프로그램은 시스템 설정을 무시하고 직접 네트워크 연결을 만듭니다. 그 결과 브라우저의 출구는 바뀌었지만 명령줄 도구나 특정 애플리케이션은 여전히 로컬 네트워크를 사용하는 상황이 생길 수 있습니다.
TUN 모드
TUN 모드는 가상 네트워크 인터페이스를 통해 더 다양한 IP 트래픽을 인계합니다. 일반적으로 시스템 프록시보다 적용 범위가 넓어 시스템 프록시 설정을 읽지 않는 애플리케이션을 처리할 때 유용합니다. 활성화하려면 시스템 권한이 필요할 수 있으며, 다른 네트워크 필터·기업 보안 소프트웨어·기존 가상 네트워크 인터페이스와 충돌할 수도 있습니다.
TUN이라고 해서 모든 요청이 원격 노드를 거쳐야 하는 것은 아닙니다. 트래픽이 TUN으로 들어온 뒤에도 규칙에 따라 프록시 또는 직접 연결을 선택할 수 있습니다. 따라서 ‘인계 방식’과 ‘라우팅 정책’은 서로 독립된 두 가지 기준입니다. 전자는 클라이언트가 어떤 트래픽을 볼 수 있는지, 후자는 해당 트래픽을 본 뒤 어떻게 처리할지를 결정합니다.
애플리케이션 프록시
일부 브라우저, 다운로드 도구, 개발 도구는 HTTP 또는 SOCKS 프록시를 별도로 입력할 수 있습니다. 특정 애플리케이션만 대상으로 테스트하기에 명확한 방식이지만, 호환되지 않는 프록시 입력란에 원격 노드 매개변수를 직접 넣지 말고 클라이언트가 제공하는 로컬 리스닝 주소를 입력해야 합니다. 애플리케이션을 종료해도 이러한 설정이 클라이언트 상태에 맞춰 자동으로 바뀌지는 않습니다.
전역 모드·규칙 모드·직접 연결 모드
라우팅 모드는 클라이언트가 인계한 요청이 다음에 어디로 향할지 결정합니다. 클라이언트마다 명칭은 조금씩 다르지만 핵심은 보통 전역, 규칙, 직접 연결로 나눌 수 있습니다.
- 전역 모드: 인계된 대부분의 요청을 선택한 노드로 전달합니다. 노드가 작동하는지 확인하고 규칙 매칭 문제를 배제할 때 유용합니다.
- 규칙 모드: 도메인, IP, 애플리케이션 또는 규칙 세트에 따라 프록시, 직접 연결, 거부를 선택합니다. 일상적인 사용에서 가장 흔한 방식입니다.
- 직접 연결 모드: 인계된 요청도 로컬 네트워크에서 직접 전송합니다. 프록시 경로를 일시적으로 중지하거나 로컬 연결을 테스트할 때 사용합니다.
규칙은 보통 클라이언트에 정의된 순서대로 매칭됩니다. 일반적인 조건으로는 전체 도메인, 도메인 접미사, IP 대역, 프로세스 이름, 지역 데이터베이스 분류가 있습니다. 매칭되면 해당 동작을 실행하고, 일치하는 규칙이 없으면 최종 규칙을 적용합니다. ‘특정 웹사이트가 선택한 노드를 거치지 않는다’면 메인 화면에 연결됨이 표시되는지만 보지 말고 연결 로그에서 해당 요청이 어떤 규칙에 매칭되었는지 확인하세요.
도메인 규칙과 IP 규칙은 서로 다른 결과를 낼 수 있습니다. 애플리케이션이 먼저 도메인을 요청하면 클라이언트가 도메인 기준으로 라우팅할 수 있습니다. 반대로 애플리케이션이 직접 해석한 뒤 IP만 제출하면 도메인 정보가 보이지 않아 IP 규칙이나 스니핑 기능에 의존해야 할 수 있습니다. 스니핑을 활성화하면 클라이언트의 트래픽 식별 방식이 바뀌므로 클라이언트 문서에 따라 설정해야 하며, 모든 문제를 해결하는 만능 스위치로 생각해서는 안 됩니다.
라우팅 문제를 가장 효과적으로 확인하려면 잠시 전역 모드로 전환해 비교하세요. 전역 모드에서는 작동하지만 규칙 모드에서는 작동하지 않는다면 문제는 대개 규칙 매칭, DNS 확인 또는 애플리케이션 인계 범위에 있습니다. 두 모드 모두 작동하지 않는다면 노드 연결과 로컬 네트워크 단계로 돌아가야 합니다.
DNS 확인과 DNS 누수
DNS는 도메인 이름을 연결 가능한 IP 주소로 변환합니다. 프록시 연결이 이미 설정되었다고 해서 DNS 요청도 반드시 같은 경로로 전송되는 것은 아닙니다. 시스템 확인, 클라이언트 내장 DNS, 브라우저의 암호화 DNS, 애플리케이션 자체 확인이 동시에 존재할 수 있어 DNS는 라우팅 문제를 점검할 때 자주 놓치는 계층입니다.
DNS 누수는 일반적으로 프록시 측 또는 지정된 확인기가 처리해야 하는 조회가 로컬 네트워크의 DNS 서비스로 전송되는 현상을 뜻합니다. 이로 인해 조회한 도메인 범위가 노출되거나 지역 판단이 일치하지 않을 수 있습니다. 점검할 때는 공인 출구 IP만 확인하지 말고 검사 페이지에 표시된 DNS 확인 위치가 현재 설정과 예상에 맞는지도 살펴봐야 합니다.
규칙 모드는 특히 DNS 설계의 영향을 크게 받습니다. 클라이언트가 먼저 도메인으로 규칙을 매칭한 뒤 로컬 또는 원격 확인을 선택할 수도 있고, 가상 IP 방식으로 도메인과 연결 사이의 매핑을 유지할 수도 있습니다. 클라이언트마다 구현이 다르므로 다른 소프트웨어의 DNS 설정을 그대로 옮기면 안 됩니다. 변경 후 도메인은 열리지 않지만 IP로는 접속된다면 확인기에 도달할 수 있는지, 규칙이 조회 요청을 잘못된 경로로 보내는지, 브라우저가 별도의 암호화 DNS를 사용하는지 확인하세요.
브라우저 캐시와 시스템 DNS 캐시에는 이전 결과가 남아 있을 수 있습니다. 회선을 바꾼 뒤에도 표시되는 콘텐츠가 달라지지 않는다고 해서 노드 전환에 실패한 것은 아닙니다. 먼저 시크릿 창을 열거나 대상 애플리케이션을 종료 후 다시 실행하고, 필요하다면 운영체제 방식에 따라 DNS 캐시를 삭제한 다음 출구와 확인 결과를 다시 점검하세요.
플랫폼별 클라이언트 차이
구독 내용은 여러 플랫폼에서 사용할 수 있지만 클라이언트 기능이 완전히 같지는 않습니다. 차이는 주로 운영체제의 네트워크 인터페이스, 백그라운드 실행 제한, 프록시 코어 버전, 클라이언트 자체의 기능 설계에서 발생합니다.
- Windows: 일반적인 클라이언트는 시스템 프록시와 TUN을 모두 지원하는 경우가 많습니다. TUN을 활성화할 때는 관리자 권한, 방화벽, 다른 가상 네트워크 어댑터를 확인하세요.
- macOS: 시스템 프록시는 시스템 설정을 따르는 애플리케이션에 적합합니다. 더 넓은 범위의 트래픽을 인계하려면 네트워크 확장 또는 TUN을 사용하며 시스템 권한 승인이 필요할 수 있습니다.
- iOS: 클라이언트는 시스템에서 제공하는 네트워크 확장을 통해 연결을 설정합니다. 백그라운드 동작, 주문형 연결, 규칙 기능은 클라이언트 구현과 시스템 제한에 따라 달라집니다.
- Android: 클라이언트는 일반적으로 시스템 VPN 인터페이스를 사용해 트래픽을 인계하며, 애플리케이션별 라우팅을 지원하는 경우가 많습니다. 배터리 절전 정책이 백그라운드 연결 유지에 영향을 줄 수 있습니다.
- Linux: 배포판과 데스크톱 환경에 따라 차이가 큽니다. 그래픽 클라이언트, 시스템 프록시, TUN 또는 명령줄 코어를 사용할 수 있으며 권한과 DNS 연동을 직접 확인해야 합니다.
한 플랫폼에서 다른 플랫폼으로 옮길 때는 구독을 다시 가져오고, 화면 캡처에 있는 서버와 포트만 복사하지 마세요. 새 클라이언트가 구독에 포함된 프로토콜, 전송 방식, 규칙 형식을 지원하는지도 확인해야 합니다. 서비스에서 공식 클라이언트를 제공한다면 구독 설정에 맞는 버전을 우선 사용하는 편이 호환성을 확인하는 수고를 줄일 수 있습니다.
구독 가져오기부터 연결 확인까지
초보자는 정해진 순서에 따라 진행하면서 각 단계에서 하나의 항목만 확인하는 것이 좋습니다. 연결에 실패하더라도 문제가 설정, 노드, 트래픽 인계, 라우팅 또는 DNS 중 어디에 있는지 빠르게 판단할 수 있습니다.
- 신뢰할 수 있는 구독을 확보하세요. 서비스 패널에서 구독을 복사하거나 클라이언트에서 로그인해 가져오고, 출처가 불분명한 공개 설정은 사용하지 마세요.
- 호환되는 클라이언트를 선택하세요. 클라이언트가 구독에 포함된 프로토콜을 지원하고 시스템에서 요구하는 네트워크 권한을 허용하는지 확인하세요.
- 구독을 가져오고 업데이트하세요. 노드 이름이 표시되는지 확인하고, 목록이 비어 있다면 먼저 구독 읽기 문제를 해결하세요.
- 노드를 선택해 연결하세요. 버튼 색상만 보지 말고 클라이언트 로그에서 프로토콜 핸드셰이크가 성공했는지 확인하세요.
- 트래픽 인계 방식을 확인하세요. 애플리케이션 범위에 따라 시스템 프록시 또는 TUN을 활성화하고, 용도가 불분명한 프록시 설정을 여러 개 겹쳐 사용하지 마세요.
- 먼저 전역 모드로 확인하세요. 대상 요청이 노드를 통과하는 것을 확인한 뒤 규칙 모드로 전환하세요.
- 출구와 DNS를 확인하세요. 공인 IP, 출구 지역, DNS 확인 결과를 비교해 트래픽이 예상대로 전송되는지 판단하세요.
- 일상적인 라우팅으로 돌아가세요. 대상 도메인에 어떤 규칙이 매칭되는지 확인하고, 필요하다면 전체 네트워크 설정을 초기화하지 말고 관련 규칙만 조정하세요.
자주 하는 실수와 빠른 판단
노드는 연결됨으로 표시되지만 웹페이지가 열리지 않을 때
‘연결됨’은 클라이언트가 노드와의 핸드셰이크를 완료했다는 뜻일 수 있습니다. 다음으로 애플리케이션이 시스템 프록시 또는 TUN의 인계를 받는지, 규칙이 요청을 직접 연결로 처리하는지, DNS가 정상적으로 확인되는지, 브라우저가 별도 프록시 설정을 사용하는지 점검하세요. 전역 모드와 여러 애플리케이션을 비교해 보는 것도 좋습니다.
프로토콜을 바꿔도 속도가 달라지지 않을 때
성능은 프로토콜만으로 결정되지 않으며 로컬 접속 환경, 회선 경로, 대상 서비스의 응답, 현재 네트워크 혼잡의 영향도 받습니다. 여러 프로토콜이 실제로 같은 진입점과 같은 출구 회선을 사용한다면 프로토콜만 바꿔도 주요 병목이 달라지지 않을 수 있습니다. 회선 유형을 비교하되 테스트 시간, 대상, 애플리케이션을 동일하게 유지하는 편이 더 의미 있습니다.
구독 업데이트 후 사용자 지정 노드가 사라질 때
대개 구독이 관리하는 설정을 직접 수정했기 때문에 업데이트 과정에서 서버 버전으로 덮어써진 경우입니다. 사용자 지정 규칙은 클라이언트의 오버라이드 영역에 넣거나 로컬 설정으로 별도 저장하세요. 수정 전 백업을 내보내고, 내보낸 내용이 공개적으로 공유되지 않도록 확인해야 합니다.
출구 지역은 맞지만 서비스가 다른 지역으로 판단할 때
지역 판단에는 출구 IP, DNS, 계정 정보, 브라우저 캐시, 위치 권한, 시스템 환경 등이 함께 사용될 수 있습니다. 먼저 이전 세션을 정리하고 DNS를 다시 확인하세요. 많은 노드를 반복해서 전환하는 것은 피하는 편이 좋습니다. 대상 서비스가 계정 지역에 별도 규칙을 적용한다면 해당 서비스의 공개 안내를 기준으로 판단해야 하며, 네트워크 출구가 바뀐다고 계정 속성이 자동으로 변경되지는 않습니다.
규칙 모드가 일부 애플리케이션에서만 작동할 때
먼저 작동하지 않는 애플리케이션이 클라이언트로 들어오는지 확인하세요. 시스템 프록시는 모든 프로그램을 처리하지 못할 수 있고, TUN의 애플리케이션 제외 설정이 특정 프로세스를 건너뛸 수도 있습니다. 로그에 해당 애플리케이션의 연결 기록이 전혀 없다면 문제는 인계 계층에 있을 가능성이 높습니다. 로그는 있지만 동작이 직접 연결로 표시된다면 규칙 계층을 점검하세요.