이용 가이드 약 9분

VPN 초보자 용어 완벽 가이드: 구독, 노드, 프로토콜, 트래픽 분할 한 번에 이해하기

구독 링크란 무엇인지, 노드와 회선은 어떻게 다른지, IEPL 전용 회선·중계·직접 연결을 어떻게 구분하는지, 프로토콜 이름의 의미와 글로벌·규칙 모드 선택법까지 초보자가 자주 헷갈리는 용어를 빠르게 정리합니다.

VPN 초보자 용어 가이드는 가장 기본적인 구독, 노드, 회선, 프로토콜, 트래픽 분할부터 시작해 클라이언트 화면의 각 항목이 실제로 무엇을 제어하는지 설명합니다. 약어를 외우는 것보다 중요한 것은 명확한 연결 흐름을 이해하는 것입니다. 클라이언트가 설정을 읽고, 규칙에 따라 노드를 선택한 뒤, 해당 프로토콜로 트래픽을 전송하며, 도메인 조회 방식은 DNS 설정에 따라 결정됩니다.

구독형 서비스를 처음 접하면 많은 문제가 회선 장애가 아니라 서로 다른 계층의 개념을 혼동해서 발생합니다. 예를 들어 구독 업데이트 실패가 모든 노드를 사용할 수 없다는 뜻은 아니며, 노드 이름에 특정 지역이 적혀 있어도 전체 네트워크 경로가 그 지역에 있다는 의미는 아닙니다. 같은 프로토콜을 사용한다고 속도와 안정성까지 같은 것도 아닙니다. 용어를 먼저 구분해 두면 이후 문제 해결이 훨씬 쉬워집니다.

구독 링크, 설정 파일, 클라이언트는 각각 무엇인가

구독 링크는 설정으로 들어가는 주소이지 일반 웹페이지가 아닙니다

구독 링크는 보통 서버가 생성한 설정 모음을 가리킵니다. 클라이언트가 해당 주소에 접속하면 노드 이름, 서버 주소, 포트, 프로토콜 유형, 인증 정보와 일부 전송 매개변수를 읽고, 이를 선택 가능한 노드 목록으로 변환합니다. 구독 주소를 브라우저에 붙여넣었을 때 텍스트가 보이거나 파일이 다운로드되거나 정상적으로 서식이 표시되지 않아도 링크가 손상됐다고 단정할 수 없습니다. 애초에 웹페이지 표시용 주소가 아닐 수 있기 때문입니다.

구독 주소에는 계정이나 설정 권한을 식별하는 인증 정보가 포함되는 경우가 많으므로 민감 정보로 취급해야 합니다. 전체 주소를 공개 게시물이나 스크린샷, 신뢰할 수 없는 온라인 변환 도구에 붙여넣지 마세요. 도움을 요청할 때는 도메인과 오류 메시지만 남기고 경로에 포함된 식별 정보는 가리는 것이 좋습니다.

설정 파일은 특정 시점에 가져온 정적 내용입니다

클라이언트는 구독 링크에서 내용을 가져온 뒤 보통 로컬에 설정 사본을 저장합니다. 따라서 구독 서버에 일시적으로 접속할 수 없어도 이미 가져온 노드는 계속 표시되고 연결할 수 있습니다. 반대로 서버에서 노드를 변경했는데 클라이언트가 업데이트하지 않았다면 로컬 목록에는 변경 사항이 자동으로 반영되지 않습니다.

따라서 ‘구독’과 ‘노드’는 같은 것이 아닙니다. 하나의 구독에는 여러 노드가 포함될 수 있고 그룹, 정책, 규칙이 함께 제공되기도 합니다. 단일 노드는 설정 모음 안에 있는 하나의 연결 진입점일 뿐입니다. 구독을 삭제할 때 노드까지 함께 삭제하는 클라이언트도 있고, 이미 펼쳐진 로컬 설정을 유지하는 클라이언트도 있습니다. 구체적인 동작은 클라이언트 구현에 따라 달라집니다.

클라이언트는 해석·연결·트래픽 처리를 담당합니다

클라이언트는 기기에 설치하는 소프트웨어입니다. 구독 형식을 해석하고 노드 연결을 만든 다음, 시스템 프록시·가상 네트워크 인터페이스·애플리케이션 수준 프록시를 통해 트래픽을 처리합니다. 서비스 제공업체는 구독과 네트워크 측 기능을 제공하고, 클라이언트는 이를 실제 운영체제에서 작동하게 합니다. 두 요소의 개발 주체가 다르면 화면 구성, 기능 범위, 호환되는 형식도 달라질 수 있습니다.

  1. 신뢰할 수 있는 경로에서 전체 구독 링크를 복사합니다.
  2. 클라이언트에서 ‘구독 추가’, ‘URL에서 가져오기’ 또는 같은 의미의 메뉴를 찾습니다.
  3. 가져오기가 끝나면 구독을 업데이트하고 노드 이름이 표시되는지 확인합니다.
  4. 노드와 실행 모드를 선택한 다음 시스템 프록시 또는 가상 네트워크 모드를 시작합니다.
  5. 출구 주소를 확인할 수 있는 페이지에 접속해 실제 출구가 선택한 지역과 일치하는지 확인합니다.

노드, 회선, 진입점과 출구의 차이

‘노드’는 보통 클라이언트에서 클릭해 선택할 수 있는 하나의 설정을 뜻합니다. 서비스 진입점과 해당 프로토콜 매개변수가 포함됩니다. 노드 이름에 국가, 도시, 회선 유형 또는 용도가 표시될 수 있지만, 이름은 식별을 위한 라벨일 뿐 하위 경로 구조를 단독으로 증명하지는 않습니다.

‘진입점’은 클라이언트가 처음 연결하는 서비스 주소입니다. ‘출구’는 요청이 프록시 네트워크를 벗어나 대상 웹사이트에 접속할 때 사용하는 공인 주소입니다. 단순한 구조에서는 진입점과 출구가 같은 서버에 있을 수 있습니다. 중계 구조에서는 진입점이 트래픽을 받은 뒤 다른 출구로 전달합니다. 웹사이트는 일반적으로 클라이언트의 위치나 진입점 이름이 아니라 최종 출구 주소를 기준으로 접속 출처를 판단합니다.

‘회선’은 네트워크 경로에 가까운 개념입니다. 로컬 네트워크에서 진입점까지, 진입점에서 중계 지점까지, 다시 출구까지 데이터가 이동하는 방식을 설명합니다. 두 노드가 같은 프로토콜을 사용하더라도 진입점의 통신사, 국제 경로, 혼잡 상태 또는 출구가 다르면 실제 사용 경험은 달라질 수 있습니다. 프로토콜은 ‘어떻게 통신하는가’를, 회선은 ‘어디를 거치는가’를 결정하므로 둘을 같은 것으로 볼 수 없습니다.

용어 제어 대상 흔한 오해 확인 방법
구독 설정 모음과 업데이트 진입점 구독이 업데이트되면 모든 노드를 사용할 수 있다 업데이트 결과와 노드 연결 결과를 따로 확인합니다
노드 클라이언트의 연결 설정 노드 이름이 전체 네트워크 경로를 의미한다 설정, 출구 주소, 실제 연결 상태를 확인합니다
진입점 클라이언트가 처음 연결하는 서버 진입점 지역이 반드시 출구 지역과 같다 서비스 주소와 최종 출구 주소를 구분합니다
출구 대상 서비스에 접속할 때 표시되는 공인 주소 노드 이름을 바꾸면 출구가 반드시 바뀐다 연결 후 출구 주소를 다시 조회합니다
회선 데이터가 이동하는 네트워크 경로 프로토콜이 같으면 회선 품질도 같다 라우팅, 지연 변동, 실제 서비스 테스트를 함께 확인합니다

직접 연결·중계·IEPL 전용 회선

직접 연결은 일반적으로 클라이언트가 대상 지역 또는 해당 네트워크에 위치한 서비스 노드에 직접 연결하고, 서비스 제공업체가 별도로 구축한 전달 진입점은 거치지 않는 방식을 의미합니다. 구조는 단순하지만 연결 품질이 로컬 통신사, 망간 연동, 국제 경로 변화의 영향을 직접 받습니다.

중계는 클라이언트가 먼저 가까운 진입점이나 연결 품질을 더 안정적으로 관리할 수 있는 진입점에 연결한 뒤, 진입점이 트래픽을 출구로 전달하는 방식입니다. 중계를 이용하면 일부 불리한 공용 네트워크 경로를 피할 수 있지만, 중계가 항상 더 빠른 것은 아닙니다. 진입점 부하, 진입점에서 출구까지의 경로, 전달 계층 설정이 모두 결과에 영향을 줍니다.

IEPL은 국제 이더넷 전용 회선과 관련된 업계 용어로, 지역 간 전송에서 전용 전송 구간을 사용하는 것이 핵심 특징입니다. 실제 제품은 일부 구간에서만 전용 회선을 사용할 수 있으며, 사용자의 로컬 네트워크에서 접속 지점까지 또는 출구에서 대상 웹사이트까지는 다른 네트워크를 거칠 수 있습니다. ‘IEPL’ 라벨은 회선 구조를 설명하는 것이지, 어느 장소에서든 어느 시간대든 일정한 속도를 보장한다는 뜻은 아닙니다.

프로토콜 이름 읽는 법: Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC

프로토콜은 클라이언트와 서버가 데이터를 캡슐화하고 인증하며 전송하는 방식을 규정합니다. 호환성, 핸드셰이크 방식, 전송 계층 선택, 네트워크 변동에 대응하는 방식에 영향을 주지만, 프로토콜 이름만으로 노드 부하, 출구 품질, 전체 회선 속도를 판단할 수는 없습니다. 프로토콜을 비교할 때는 먼저 클라이언트 지원 여부를 확인하고, 현재 네트워크에서 UDP가 제한되는지, 패킷 손실이 뚜렷한지, 서버 매개변수가 완전히 일치하는지 살펴봐야 합니다.

Shadowsocks

Shadowsocks는 암호화 프록시 프로토콜로, 설정에는 보통 서버 주소, 포트, 암호화 방식, 비밀번호가 포함됩니다. 구조가 비교적 단순하고 지원하는 클라이언트도 다양합니다. 구현에 따라 암호화 스위트와 확장 기능 지원이 다를 수 있으므로 ‘같은 Shadowsocks’라고 해서 모든 클라이언트에 바로 가져올 수 있는 것은 아닙니다.

VMess와 VLESS

VMess는 V2Ray 생태계의 프로토콜로, 인증과 전송 설정을 포함하며 클라이언트와 서버의 시간 동기화에 비교적 민감합니다. VLESS는 더 간결한 인증 설계를 사용하며, 자체적으로 완전한 콘텐츠 암호화를 담당하지는 않습니다. 보통 TLS, REALITY 또는 다른 보안 전송 방식과 함께 사용합니다. VLESS 설정을 확인할 때는 사용자 식별자뿐 아니라 전송 방식, 보안 계층, 서버 이름 등의 매개변수가 일치하는지도 확인해야 합니다.

Trojan

Trojan은 일반적으로 TLS 위에서 실행되며 비밀번호로 인증하고 올바른 도메인, 인증서, TLS 매개변수에 의존합니다. 서버 이름이 잘못 입력되거나 인증서 검증에 실패하거나 시스템 시간이 정확하지 않으면 암호화 연결을 설정하는 과정에서 바로 오류가 발생할 수 있습니다. 인증서 검증을 끄면 오류가 일시적으로 사라질 수 있지만 신원 확인이 약화되므로 일반적인 해결 방법으로 사용해서는 안 됩니다.

Hysteria2와 TUIC

Hysteria2와 TUIC는 모두 QUIC 및 UDP 전송을 기반으로 하며, 혼잡 제어, 불안정한 네트워크에서의 복구, 다중 스트림 전송 경험에 초점을 둡니다. 지연이 높거나 패킷 손실이 있는 일부 네트워크에서는 기존 TCP 경로보다 유연하게 작동할 수 있지만, 로컬 네트워크, 라우터, 서버가 모두 UDP를 정상적으로 처리해야 합니다. 네트워크 환경에서 UDP가 제한되면 연결 시간 초과가 발생할 수 있습니다. 이때는 구독이 만료됐다고 단정하기보다 사용 가능한 TCP 계열 전송으로 바꿔 비교해야 합니다.

프로토콜 주요 전송 특성 설정 시 확인할 항목 흔한 장애 원인
Shadowsocks 암호화 프록시, 단순한 구조 암호화 방식, 비밀번호, 구현 호환성 클라이언트가 해당 암호화 방식을 지원하지 않음
VMess 인증을 포함한 V2Ray 생태계 프로토콜 사용자 식별자, 전송 방식, 시스템 시간 매개변수 불일치 또는 시간 오차
VLESS 간결한 인증, 보안 계층과 함께 사용 TLS 또는 REALITY, 전송 매개변수 보안 계층과 서버 설정 불일치
Trojan TLS 기반 인증 및 전송 비밀번호, 도메인, 인증서 검증 서버 이름 또는 인증서 오류
Hysteria2 QUIC 및 UDP 기반 UDP 접속 가능 여부, 인증, TLS 현재 네트워크에서 UDP 제한
TUIC QUIC 및 UDP 기반 클라이언트 버전, 혼잡 제어, 인증 구현 버전 또는 매개변수 호환성 문제

글로벌 모드, 규칙 분할, 직접 연결 모드 중 무엇을 선택할까

실행 모드는 클라이언트가 트래픽을 처리한 뒤 요청을 프록시 노드로 보낼지 로컬 네트워크로 보낼지 결정합니다. 클라이언트마다 ‘글로벌’, ‘규칙’, ‘로컬 네트워크 우회’, ‘직접 연결’ 등 명칭이 다를 수 있으며, 구체적인 동작은 현재 규칙 세트와 시스템 트래픽 처리 방식에 따라 달라집니다.

글로벌 모드는 일반적으로 클라이언트가 처리하는 대부분의 트래픽을 선택한 노드를 통해 보내는 방식입니다. 특정 웹사이트가 트래픽 분할 규칙 때문에 잘못된 경로를 사용하는지 확인하거나, 노드 자체가 대상 서비스에 접속할 수 있는지 짧게 점검할 때 유용합니다. 다만 글로벌 모드가 모든 애플리케이션을 포함하는 것은 아닙니다. 프로그램이 시스템 프록시를 따르지 않고 클라이언트도 가상 네트워크 모드를 사용하지 않는다면 해당 프로그램은 직접 연결될 수 있습니다.

규칙 모드는 도메인, IP, 애플리케이션 또는 규칙 모음에 따라 트래픽의 경로를 결정합니다. 일반적으로 로컬 서비스는 직접 연결하고, 국제 회선이 필요한 요청은 노드를 거치며, 로컬 네트워크 기기에도 계속 접근할 수 있도록 구성합니다. 일상적인 사용에는 규칙 모드가 더 적합하지만, 오래된 규칙, 잘못된 매칭 순서, 일치하지 않는 도메인 조회 경로 때문에 예상과 다른 직접 연결이나 프록시 연결이 발생할 수 있습니다.

직접 연결 모드는 일반적으로 트래픽이 프록시 노드를 거치지 않는 방식입니다. 문제가 프록시 경로 때문에 발생했는지 빠르게 확인하거나 지역 간 연결이 필요하지 않을 때 로컬 네트워크 경로를 복원하는 데 사용할 수 있습니다. 직접 연결 모드가 ‘클라이언트 연결 해제’와 같은 뜻은 아닙니다. 일부 클라이언트는 로컬 프록시 포트나 DNS 처리를 계속 유지하면서 최종 정책만 직접 연결로 선택할 수 있습니다.

  • ✅ 특정 대상에 접속할 수 없으면 먼저 글로벌 모드와 규칙 모드로 교차 테스트합니다.
  • ✅ 글로벌 모드에서는 되지만 규칙 모드에서 안 되면 도메인 규칙, 규칙 우선순위, DNS 정책을 확인합니다.
  • ✅ 브라우저는 되지만 별도 애플리케이션이 안 되면 해당 애플리케이션이 시스템 프록시를 따르는지 확인합니다.
  • ✅ 로컬 기기나 내부 네트워크 서비스에 접근할 수 없으면 로컬 네트워크 주소가 직접 연결로 설정되어 있는지 확인합니다.
  • ❌ ‘노드를 선택했다’고 해서 ‘모든 프로그램이 해당 노드를 통해 연결된다’고 바로 이해하지 마세요.
  • ❌ 시스템 프록시나 가상 네트워크 인터페이스를 처리하는 클라이언트를 여러 개 동시에 실행하지 마세요.

시스템 프록시와 가상 네트워크 모드

시스템 프록시는 운영체제의 프록시 설정을 따르는 애플리케이션에 HTTP 또는 SOCKS 진입점을 제공합니다. 브라우저는 대체로 잘 지원하지만 게임, 명령줄 프로그램, 일부 독립 클라이언트는 시스템 프록시를 무시할 수 있습니다. 가상 네트워크 모드는 가상 인터페이스를 만들어 더 낮은 계층에서 IP 트래픽을 처리하므로 적용 범위가 대체로 넓지만, 라우팅 테이블, 권한, DNS 설정의 영향을 더 많이 받습니다.

가상 네트워크 모드를 켠 뒤 인터넷에 연결할 수 없다면 다른 네트워크 필터링 소프트웨어, 기존 가상 인터페이스, 충돌하는 라우팅이 있는지 먼저 확인하세요. 클라이언트를 종료한 뒤 시스템 프록시가 복원되지 않으면 ‘노드는 연결 해제됐지만 브라우저는 여전히 접속할 수 없는’ 현상이 발생할 수 있습니다. 이때는 남아 있는 시스템 프록시 설정을 꺼야 합니다.

DNS 유출, 원격 조회와 도메인 규칙

DNS는 도메인 이름을 IP 주소로 변환합니다. 웹사이트에 접속하기 전에 클라이언트는 보통 도메인 조회를 먼저 완료한 다음 그 결과를 바탕으로 연결을 설정합니다. 프록시 경로가 정상적으로 작동한다고 해서 DNS 조회까지 같은 경로를 거치는 것은 아닙니다. 조회는 로컬 네트워크에 맡기고 연결만 원격 노드를 통하면 조회 경로와 접속 경로가 분리됩니다.

일반적으로 DNS 유출은 관리되어야 할 조회 요청이 실수로 로컬 네트워크나 예상하지 않은 다른 조회 서버로 전송되는 것을 뜻합니다. 이로 인해 접속한 도메인의 단서가 노출될 수 있으며, 지역에 따라 서로 다른 주소가 반환되어 트래픽 분할 판단과 실제 연결이 일치하지 않을 수도 있습니다.

규칙 분할은 특히 DNS에 의존합니다. 도메인 기준으로 매칭할 때는 클라이언트가 조회 전에 정책을 결정할 수 있습니다. IP 기준으로 매칭할 때는 먼저 조회한 다음 반환된 주소에 규칙을 적용해야 합니다. 일부 클라이언트는 가상 주소 매핑을 사용해 가상 네트워크가 트래픽을 처리한 뒤에도 도메인 정보를 규칙 판단에 활용합니다. 구현마다 명칭은 다르지만 핵심 목표는 ‘도메인 조회, 규칙 매칭, 연결 출구’를 일치시키는 것입니다.

브라우저에 내장된 암호화 DNS가 클라이언트 설정을 우회할 수도 있습니다. 같은 도메인이 브라우저와 다른 애플리케이션에서 다르게 작동한다면 브라우저의 독립 조회 기능을 잠시 끄고 비교해 보세요. 점검이 끝난 뒤에는 개인정보 보호 요구와 클라이언트 호환성에 맞춰 통일된 조회 방식을 선택하면 됩니다.

Windows, macOS, Android, iOS 및 Linux 클라이언트 차이

같은 구독이라도 플랫폼에 따라 결과가 다르게 나타날 수 있습니다. 이는 대개 구독 내용이 바뀌어서가 아니라 시스템 네트워크 인터페이스, 애플리케이션 권한, 클라이언트 커널이 다르기 때문입니다. 가져오기 전에 클라이언트가 구독에 포함된 프로토콜과 전송 유형을 지원하는지 확인하고, 가져온 뒤에는 트래픽 처리 방식이 대상 애플리케이션에 적합한지 점검해야 합니다.

Windows와 macOS

데스크톱 시스템에서는 시스템 프록시와 가상 네트워크라는 두 가지 실행 방식이 일반적입니다. 브라우저와 일반 데스크톱 애플리케이션만 처리한다면 시스템 프록시 설정이 간단합니다. 시스템 프록시를 따르지 않는 소프트웨어까지 포함해야 한다면 가상 네트워크 모드가 더 적합합니다. macOS는 네트워크 확장 권한을 명확히 안내하므로 처음 활성화할 때 시스템 승인을 완료해야 합니다. 그렇지 않으면 클라이언트 화면에는 실행 중으로 표시되어도 시스템 트래픽이 가상 인터페이스로 들어가지 않을 수 있습니다.

Android와 iOS

모바일 운영체제는 보통 시스템이 제공하는 VPN 인터페이스로 트래픽을 처리합니다. Android 클라이언트는 애플리케이션별 분할 기능을 제공해 지정한 앱만 프록시를 사용하거나 직접 연결하도록 할 수 있습니다. iOS는 시스템 샌드박스와 네트워크 확장机制의 제약을 받으므로 클라이언트마다 지원 프로토콜, 규칙 업데이트 방식, 백그라운드 유지 능력이 다를 수 있습니다. 시스템에서는 한 번에 하나의 주요 VPN 설정만 활성화되므로 클라이언트를 바꿀 때 기존 연결이 해제됐는지 확인해야 합니다.

Linux

Linux 환경에서는 데스크톱 프록시, 명령줄 환경 변수, 투명 프록시 또는 가상 네트워크 인터페이스를 사용할 수 있습니다. 터미널 프로그램이 프록시를 사용할지는 프로그램 자체 설정과 환경 변수에 따라 결정되므로 브라우저가 작동한다고 전체 시스템이 처리되고 있다고 판단해서는 안 됩니다. 서버 환경에서는 라우팅 전달, DNS 서비스, 권한도 확인해야 하며, 변경 전 원래 설정을 보관해 복구할 수 있도록 하세요.

플랫폼 일반적인 트래픽 처리 방식 우선 확인할 항목
Windows 시스템 프록시, 가상 네트워크 인터페이스 프록시 잔여 설정, 라우팅 충돌, 애플리케이션의 프록시 준수 여부
macOS 시스템 프록시, 네트워크 확장 시스템 승인, 네트워크 확장 상태, DNS 설정
Android 시스템 VPN 인터페이스, 애플리케이션별 분할 애플리케이션 적용 범위, 배터리 백그라운드 정책, 다른 VPN과의 충돌
iOS 네트워크 확장과 시스템 VPN 설정 설정 승인, 클라이언트 프로토콜 지원, 기존 연결 상태
Linux 환경 변수, 투명 프록시, 가상 인터페이스 라우팅, 권한, DNS 및 명령줄 프로그램 설정

초보자 문제 해결: 연결 단계별로 원인 찾기

효율적인 문제 해결은 설정을 가져오는 단계부터 시작해 노드 핸드셰이크, 시스템 트래픽 처리, DNS, 대상 서비스 순서로 확인해야 합니다. 한 번에 하나의 변수만 바꿔야 어떤 설정이 영향을 주었는지 알 수 있습니다. 노드, 프로토콜, 모드, DNS를 무작정 반복해서 바꾸면 우연히 복구될 수는 있어도 실제 원인은 확인할 수 없습니다.

  1. 구독 가져오기 확인: 링크가 완전하고 만료되지 않았는지, 클라이언트가 업데이트를 완료할 수 있는지, 목록에 예상한 노드가 표시되는지 확인합니다.
  2. 클라이언트 호환성 확인: 현재 버전이 노드에서 사용하는 프로토콜, 전송 방식, 보안 계층을 지원하는지 확인합니다.
  3. 기본 핸드셰이크 확인: 노드를 선택한 뒤 오류 로그를 확인하고 시간 초과, 인증 실패, 인증서 오류, 매개변수 불일치를 구분합니다.
  4. 트래픽 처리 확인: 시스템 프록시 또는 가상 네트워크 모드가 실제로 활성화되어 있고 대상 애플리케이션도 처리 범위에 포함되는지 확인합니다.
  5. 출구 확인: 연결 후 실제 출구를 조회해 요청이 선택한 노드를 통하는지, 계속 직접 연결되는지 확인합니다.
  6. DNS 확인: 조회 경로와 출구 경로를 비교해 로컬 조회, 브라우저 독립 조회, 규칙 충돌을 배제합니다.
  7. 대상 서비스 확인: 다른 웹사이트는 정상인데 특정 서비스만 문제가 있다면 클라이언트를 바로 재설치하기보다 지역 정책, 계정 상태, 대상 측 제한을 추가로 확인해야 합니다.
구독을 업데이트할 수 없음
└─ 링크 무결성과 구독 형식 확인

구독은 업데이트되지만 노드에 연결할 수 없음
└─ 프로토콜 지원, 인증, TLS, UDP, 시스템 시간 확인

노드는 연결됨으로 표시되지만 애플리케이션에 접속할 수 없음
└─ 시스템 프록시, 가상 네트워크 인터페이스, 애플리케이션 처리 범위 확인

출구는 올바르지만 도메인 접속에 문제가 있음
└─ DNS, 트래픽 분할 규칙, 브라우저 독립 조회 확인

대부분의 대상은 정상인데 특정 서비스만 문제가 있음
└─ 대상 서비스의 지역, 계정, 콘텐츠 정책 확인

오류 로그는 ‘연결할 수 없음’이라는 메시지보다 더 많은 정보를 제공합니다. 시간 초과는 보통 네트워크 접속 가능 여부, UDP 제한, 서버 무응답과 관련이 있습니다. 인증 실패는 비밀번호, 사용자 식별자, 구독 상태가 원인일 수 있습니다. 인증서 오류는 서버 이름, 시스템 시간, TLS 설정과 관련된 경우가 많습니다. 핸드셰이크는 성공했지만 트래픽이 흐르지 않는다면 라우팅, DNS, 시스템 트래픽 처리 설정을 계속 확인해야 합니다.

무료로 시작하기