설치 전에 구독, 클라이언트 및 시스템 권한 확인하기
처음 설정할 때 가장 헷갈리기 쉬운 것은 구독 서비스, 클라이언트, 회선 노드라는 세 가지 요소입니다. 구독 서비스는 회선 정보를 제공하고, 클라이언트는 이 정보를 읽어 해당 네트워크 트래픽을 처리하며, 노드는 실제 연결에서 선택하는 입구와 출구입니다. 이 셋은 서로 같은 것이 아닙니다. 클라이언트만 있고 유효한 구독이 없으면 일반적으로 사용할 회선을 얻을 수 없고, 구독 링크만 있고 호환되는 클라이언트가 없으면 Windows에서 연결을 만들 수 없습니다.
클라이언트는 서비스 패널에서 제공하는 다운로드 경로를 통해 받아야 합니다. 검색 결과만 보고 이름이 비슷한 프로그램을 임의로 내려받거나 출처가 불분명한 수정 버전을 사용하지 마세요. 설치 전에는 파일 게시자, 디지털 서명, 설치 위치를 확인할 수 있습니다. 보안 프로그램이 네트워크 드라이버나 가상 네트워크 어댑터 변경을 알리면 시스템 보호를 바로 끄기보다 클라이언트 출처를 먼저 확인한 뒤 허용 여부를 결정하세요.
일부 클라이언트는 Windows 시스템 프록시만 사용하므로 가상 네트워크 어댑터가 필요하지 않습니다. 다른 클라이언트는 TUN 모드를 지원하며 네트워크 드라이버 설치와 관련 권한이 필요합니다. 설치 중 드라이버 확인 메시지가 표시된다고 해서 반드시 오류인 것은 아니지만, 선택한 클라이언트의 기능 설명과 일치해야 합니다. 회사에서 관리하는 장치는 드라이버 설치, 프록시 변경 또는 시작 시 실행이 제한될 수 있으므로 조직의 네트워크 및 장치 관리 규정을 먼저 따라야 합니다.
Windows의 날짜, 시간, 시간대가 올바른지도 확인해야 합니다. Trojan, VLESS 등은 TLS와 함께 사용되는 경우가 많아 시스템 시간 오차로 인증서 검증이 실패할 수 있습니다. 인증서 오류가 발생했을 때 검증을 끄는 방식으로 해결하지 말고, 먼저 시간을 동기화하고 구독을 업데이트한 뒤 회선 정보를 확인하는 것이 원인을 찾는 데 도움이 됩니다.
클라이언트 설치 및 구독 가져오기
사용자 패널에서 클라이언트를 받은 뒤 설치 프로그램의 안내에 따라 설치하세요. 처음 실행했을 때는 서둘러 전체 프록시를 켜지 말고, 클라이언트 화면에 구독 관리, 구성 관리 또는 원격 구성 메뉴가 있는지 먼저 확인하세요. 클라이언트마다 메뉴 이름은 다를 수 있지만 기본 방식은 비슷합니다. 클라이언트가 구독 주소를 읽고 노드 목록을 내려받은 다음, 자체적으로 인식할 수 있는 구성으로 변환합니다.
권장 가져오기 순서
- 서비스 패널에서 구독 주소를 복사하세요. 직접 선택하면 주소 일부가 빠지거나 불필요한 공백이 포함될 수 있습니다.
- 클라이언트의 구독 관리 화면으로 이동해 클립보드에서 가져오거나 원격 구독을 추가하세요.
- 구독에 알아보기 쉬운 로컬 이름을 지정하세요. 이 이름은 클라이언트 안에서 구성을 구분하기 위한 것으로, 서버 측 내용은 변경하지 않습니다.
- 업데이트를 실행하고 노드 목록이 표시될 때까지 기다린 다음, 프로토콜, 지역, 회선 이름이 표시되는지 확인하세요.
- 회선 하나를 선택해 연결을 테스트하고, 사용 가능함을 확인한 뒤 자동 업데이트와 분할 라우팅을 설정하세요.
일부 클라이언트는 Shadowsocks, VMess, Trojan, VLESS, Hysteria2 또는 TUIC 링크 하나를 직접 가져오는 기능도 제공합니다. 단일 구성은 임시 점검에 적합하지만, 일상적인 사용에는 구독 가져오기가 더 편리합니다. 회선 매개변수가 변경되어도 한 번에 업데이트할 수 있기 때문입니다. 원격 구독과 수동 노드를 함께 저장했다면 이름이 같은 항목에 주의해 실제로 이전 구성이 연결되지 않도록 하세요.
구독 업데이트에 실패하면 먼저 로컬에서 구독 경로에 접근할 수 있는지 확인한 다음 주소가 잘리지 않았는지 살펴보세요. 일부 메신저는 복사할 때 문장 부호를 덧붙이고, 일부 브라우저 확장 프로그램은 클립보드 내용을 수정할 수 있습니다. 패널에서 주소를 다시 복사할 수는 있지만, 전체 주소를 공개 검사 사이트에 제출하지 마세요. 구독 자격 증명이 노출된 것으로 의심되면 이전 주소를 계속 공유하지 말고 서비스 패널에서 갱신하세요.
QR 코드는 기기 간 구성 전송에 더 적합하며, Windows에서는 일반적으로 구독 주소를 직접 복사하는 편이 명확합니다. 클라이언트에 ‘구독 변환’ 옵션이 있다면 서비스에서 명확히 지원하는 방식을 우선 사용하세요. 비공개 구독을 출처가 불분명한 변환 서비스에 제출하면 자격 증명이 노출될 범위가 넓어지고, 변환 과정에서 프로토콜 필드가 누락될 수도 있습니다.
프로토콜과 회선 유형 선택 방법
프로토콜은 클라이언트와 노드가 데이터를 어떻게 캡슐화하고 암호화하며 전송하는지를 결정하고, 회선 유형은 트래픽이 어떤 네트워크 경로를 통과하는지 설명합니다. 프로토콜 이름이 같아도 회선 품질이 같다는 뜻은 아니며, 회선 이름이 비슷해도 프로토콜 성능이 동일한 것은 아닙니다. 판단할 때는 프로토콜 호환성, 네트워크 환경, 회선 경로를 나누어 살펴봐야 합니다.
| 프로토콜 | 전송 특징 | 선택 시 확인할 사항 |
|---|---|---|
| Shadowsocks | 구조가 비교적 단순하며 대칭 암호화로 프록시 트래픽을 보호합니다. | 클라이언트가 해당 암호화 방식과 플러그인 매개변수를 지원하는지 확인하세요. |
| VMess | 구성 필드가 많고 다양한 전송 방식 및 TLS와 함께 사용할 수 있습니다. | 시간, 전송 방식, 호스트 이름, 경로가 서버 측 설정과 일치해야 합니다. |
| Trojan | 일반적으로 TLS로 연결을 설정하므로 인증서와 도메인 검증에 민감합니다. | 인증서 오류를 무시하지 말고 먼저 시간과 구독 매개변수를 확인하세요. |
| VLESS | 프로토콜 자체는 가볍지만 보안 및 전송 성능은 함께 사용하는 방식에 따라 달라집니다. | TLS, REALITY 또는 기타 전송 매개변수를 클라이언트가 지원하는지 확인하세요. |
| Hysteria2 | QUIC 및 UDP 기반으로, 복잡한 네트워크 환경에서 혼잡 제어에 중점을 둡니다. | 로컬 네트워크에서 UDP를 제한하면 연결 성능이 크게 달라질 수 있습니다. |
| TUIC | 마찬가지로 QUIC 및 UDP 기반이며, 동시 전송과 연결 복구를 중시합니다. | 클라이언트 코어, 서버 매개변수, UDP 환경이 모두 호환되어야 합니다. |
프로토콜을 선택할 때 이름이 더 최신인 방식을 무조건 추구할 필요는 없습니다. 클라이언트 코어가 호환되지 않거나 매개변수가 부족하거나 네트워크에서 UDP를 제한하면 이론적인 기능이 실제 사용 경험으로 이어지지 않습니다. 먼저 서버에서 권장하는 구성을 사용하는 편이 안정적입니다. 웹페이지는 열리지만 회의, 다운로드 또는 원격 협업에 문제가 생긴다면 다른 호환 프로토콜과 비교해 보세요.
직접 연결, 중계 및 IEPL 전용 회선의 차이
직접 연결 회선은 일반적으로 로컬 네트워크가 해외 노드에 바로 연결되는 방식을 뜻합니다. 경로가 단순하지만 로컬 통신사의 국제 출구와 국경 간 라우팅에 더 크게 좌우됩니다. 혼잡 시간대의 경로 변경, 우회 또는 패킷 손실이 사용 경험에 영향을 줄 수 있습니다. 로컬 국제 출구 환경이 좋고 추가 중계 단계를 줄이고 싶은 경우에 적합합니다.
중계 회선은 먼저 가까운 입구에 연결한 다음 중계 네트워크를 통해 출구 노드로 전달합니다. 좋지 않은 공용 네트워크 경로 일부를 피하는 것이 목적이지만, 최종 결과는 입구 품질, 중계 구간, 출구 상태에 따라 달라집니다. 중계가 직접 연결보다 항상 빠른 것은 아니며, 입구가 너무 멀거나 회선이 혼잡하면 마찬가지로 느려질 수 있습니다.
IEPL은 일반적으로 지정된 접속 지점 사이에서 트래픽을 전달하는 국제 이더넷 전용 회선 유형을 가리킵니다. 서비스 제공업체가 실제 상품에 로컬 접속, 중계, 공용망 출구를 함께 구성할 수도 있으므로 ‘IEPL’이라는 이름만으로 전체 경로를 판단할 수 없습니다. 선택할 때는 회선 설명, 대상 지역, 로컬 네트워크 테스트를 함께 고려하고, 회선 라벨을 고정 속도 보장처럼 해석하지 마세요.
시스템 프록시와 TUN 모드의 차이
Windows 클라이언트에서 흔히 사용하는 트래픽 처리 방식은 시스템 프록시와 TUN입니다. 시스템 프록시는 Windows 프록시 설정을 변경하며, 시스템 프록시를 따르는 앱은 요청을 클라이언트로 전달할 수 있습니다. 브라우저와 많은 데스크톱 프로그램이 이를 지원하지만, 일부 게임, 명령줄 프로그램, 독립 업데이트 프로그램 또는 자체 네트워크 스택을 사용하는 앱은 시스템 프록시를 무시할 수 있습니다.
TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 IP 트래픽을 처리하므로 시스템 프록시를 지원하지 않는 프로그램에 더 유리합니다. 대신 구성이 복잡하고 보안 프로그램, 가상 머신, 컨테이너, 기업 네트워크 클라이언트 또는 다른 네트워크 드라이버와 라우팅 충돌이 발생할 수 있습니다. 활성화 후 시스템 전체가 인터넷에 연결되지 않으면 TUN을 먼저 종료하고 가상 네트워크 어댑터, 라우팅, DNS를 확인하세요. 구독을 반복해서 재설치할 필요는 없습니다.
처음에는 시스템 프록시부터 사용하는 것이 좋습니다. 웹페이지 접속과 구독 회선이 정상인지 확인한 뒤, 대상 앱이 시스템 프록시를 따르지 않을 때만 TUN을 테스트하세요. 이렇게 하면 ‘회선을 사용할 수 없음’과 ‘트래픽이 처리되지 않음’을 구분할 수 있습니다. 처음부터 시스템 프록시, TUN, DNS, 방화벽을 동시에 변경하면 문제가 어느 계층에서 발생했는지 파악하기 어렵습니다.
| 모드 | 적합한 사용 환경 | 일반적인 제한 |
|---|---|---|
| 시스템 프록시 | 브라우저, Windows 프록시 설정을 따르는 데스크톱 앱 | 일부 프로그램은 시스템 프록시를 우회합니다 |
| TUN 모드 | 더 넓은 트래픽을 처리해야 하는 앱 | 가상 네트워크 어댑터, 라우팅 또는 보안 정책과 충돌할 수 있습니다 |
| 앱 내 프록시 | 지정한 소프트웨어만 로컬 프록시 포트를 사용하게 하려는 경우 | 앱 자체에서 프록시 설정을 지원해야 합니다 |
클라이언트가 ‘규칙’, ‘전체’, ‘직접 연결’ 모드를 함께 제공한다면, 이는 트래픽이 출구를 선택하는 방식을 뜻합니다. 규칙 모드는 도메인, IP 또는 앱 규칙에 따라 노드를 사용할지 결정하고, 전체 모드는 더 많은 트래픽을 현재 노드로 보냅니다. 직접 연결 모드는 노드를 건너뜁니다. 일상적인 사용에서는 보통 규칙 모드부터 선택한 뒤 트래픽이 누락되거나 잘못 분배되는 상황에 맞춰 조정합니다.
연결 후 실제로 적용되었는지 확인하는 방법
클라이언트에 ‘연결됨’이라고 표시되는 것은 로컬 프로그램이 특정 연결 동작을 완료했다는 뜻일 뿐, 대상 앱이 반드시 선택한 회선을 사용한다는 의미는 아닙니다. 확인할 때는 출구 주소, 대상 서비스 접속, DNS 조회, 연결 복구를 모두 점검해야 합니다. 각 항목이 확인하는 내용이 다르므로 하나만 보고 판단할 수 없습니다.
단계별 연결 점검
- 먼저 클라이언트 로그를 확인해 핸드셰이크 실패, 인증서 오류, 시간 초과 또는 DNS 실패가 계속 발생하지 않는지 살펴보세요.
- 출구 주소 조회 페이지를 열고 연결 전후의 지역 정보가 선택한 회선과 일치하는지 비교하세요.
- 실제로 사용해야 하는 해외 웹사이트나 협업 서비스에 접속해 로그인, 이미지, 파일, 실시간 연결이 모두 작동하는지 확인하세요.
- 연결을 끊었다가 다시 켜서 클라이언트가 기존 세션에 의존하지 않고 연결을 복구하는지 확인하세요.
- 다른 회선으로 전환해 테스트를 반복하면 특정 노드 문제와 로컬 구성 문제를 구분할 수 있습니다.
브라우저 캐시 때문에 연결이 끊긴 뒤에도 이전 페이지가 표시될 수 있고, 기존 연결이 잠시 유지될 수도 있습니다. 따라서 확인할 때는 콘텐츠를 새로 고치거나 새 요청을 보내야 합니다. 브라우저는 되지만 대상 데스크톱 프로그램이 되지 않는다면 해당 프로그램이 시스템 프록시를 우회하는지 먼저 의심하세요. 모든 프로그램이 되지 않는다면 노드, 구독, 시스템 시간, 로컬 방화벽을 확인하세요.
로그를 확인할 때 전체 구독 주소, 인증 필드 또는 노드 자격 증명을 공개 채널에 게시하지 마세요. 지원 요청에는 오류 유형, 발생 시간, 프로토콜 이름, 회선 지역, 클라이언트 버전 정보를 남기되 민감한 필드는 가려도 됩니다. 로그의 ‘연결 거부’는 일반적으로 대상 측이 연결을 받아들이지 않았다는 뜻이고, ‘시간 초과’는 경로에 접근할 수 없거나 네트워크가 제한되었거나 노드 상태에 문제가 있을 가능성이 더 큽니다. ‘인증서 이름 불일치’가 표시되면 도메인과 TLS 매개변수를 확인해야 합니다.
분할 라우팅 규칙과 DNS 유출 처리 방법
분할 라우팅의 목적은 모든 트래픽을 같은 경로로 보내는 것이 아니라 요청마다 적합한 출구를 사용하게 하는 것입니다. 로컬 서비스, 로컬 네트워크 장치, 지역에 민감한 국내 앱은 일반적으로 직접 연결할 수 있고, 국제 회선이 필요한 도메인이나 앱은 노드로 보냅니다. 적절한 분할 라우팅은 불필요한 우회를 줄이고, 전체 프록시 때문에 로컬 프린터, 파일 공유 또는 기업 내부망이 작동하지 않는 문제도 예방합니다.
규칙은 도메인, IP 대역, 프로세스 이름 또는 규칙 세트를 기준으로 만들 수 있습니다. 도메인 규칙은 직관적이지만 대상 서비스가 여러 콘텐츠 전송 도메인을 사용할 수 있고, IP 규칙은 명확하게 적용되지만 주소가 바뀌면 업데이트해야 합니다. 프로세스 규칙은 특정 앱에 적합하지만 보조 프로세스가 시작한 요청을 놓칠 수 있습니다. 실제 구성에서는 이러한 방식을 조합하는 경우가 많습니다.
규칙의 순서도 중요합니다. 많은 클라이언트는 위에서부터 일치 여부를 확인하고, 일치하면 다음 규칙을 더 이상 판단하지 않습니다. 범위가 너무 넓은 직접 연결 규칙을 앞에 두면 회선을 사용해야 하는 요청이 먼저 직접 연결될 수 있고, 반대로 범위가 넓은 프록시 규칙은 로컬 네트워크와 서비스를 우회시킬 수 있습니다. 규칙을 수정한 뒤에는 기존 연결을 정리하고 다시 테스트하세요. 이미 설정된 세션이 새 정책을 즉시 적용하지 않을 수 있습니다.
DNS 유출이란 무엇인가
DNS 유출은 일반적으로 트래픽은 프록시 회선을 통과하지만 도메인 조회는 로컬 네트워크의 리졸버가 직접 처리하는 현상을 뜻합니다. 이 경우 출구 경로와 조회 경로가 달라지고, 현재 출구 지역에 맞지 않는 주소가 대상 도메인에 반환될 수 있습니다. 반드시 접속 불가로 나타나는 것은 아니며, 이미지가 느리게 로드되거나 콘텐츠 지역이 다르게 표시되거나 일부 하위 도메인만 실패하는 형태로도 나타납니다.
시스템 프록시 모드에서 DNS를 프록시로 보낼지는 클라이언트, 브라우저, 앱의 구현에 따라 달라집니다. 어떤 앱은 로컬에서 먼저 조회한 뒤 대상 IP를 프록시에 전달하고, 어떤 프록시 프로토콜과 클라이언트는 원격에서 도메인을 조회할 수 있습니다. TUN 모드는 일반적으로 DNS를 더 일관되게 처리할 수 있지만, 클라이언트의 DNS 가로채기, 가상 DNS 또는 분할 DNS 설정이 올바른지도 확인해야 합니다.
브라우저에 내장된 보안 DNS도 클라이언트가 예상한 조회 경로를 우회할 수 있습니다. 출구 지역은 올바르지만 DNS 검사에서 여전히 로컬 리졸버가 표시된다면 브라우저의 독립 DNS를 잠시 끄고 시스템 조회 결과와 비교하거나, 클라이언트에서 원격 조회가 활성화되어 있는지 확인하세요. 여러 DNS 도구를 동시에 겹쳐 사용하면 브라우저, 시스템, 클라이언트, 가상 네트워크 어댑터 사이에서 요청이 반복적으로 수정될 수 있습니다.
분할 라우팅 설정 원칙
- 먼저 클라이언트가 관리하는 기본 규칙을 사용하고, 처음부터 출처가 불분명한 대규모 규칙 세트를 가져오지 마세요.
- 로컬 네트워크와 로컬 컴퓨터 주소는 직접 연결로 유지해 프린터, 파일 공유, 로컬 개발 서비스를 방해하지 않도록 하세요.
- 실제로 접속에 실패한 도메인만 소규모로 추가하고, 나중에 되돌릴 수 있도록 변경 이유를 기록하세요.
- 규칙을 업데이트한 뒤 연결을 다시 설정하고 대상 앱과 DNS 경로를 확인하세요.
- 기업 내부망, 가상 머신, 컨테이너 환경에서는 겹치는 네트워크 대역과 라우팅 우선순위 충돌이 있는지 확인해야 합니다.
시작 시 자동 실행, 자동 연결 및 구독 업데이트
‘시작 시 클라이언트 실행’과 ‘실행 후 자동 연결’은 서로 다른 설정입니다. 전자는 프로그램을 실행하기만 하고, 후자가 회선을 선택해 프록시를 활성화합니다. 시작 시 실행만 켜면 Windows 로그인 후 클라이언트 아이콘은 보이지만 트래픽은 여전히 직접 연결 상태일 수 있습니다. 설정을 마친 뒤에는 시스템에 다시 로그인해 클라이언트 실행 여부, 구독 읽기 가능 여부, 회선 연결 여부, 시스템 프록시 복구 상태를 확인하세요.
자동 연결을 설정하기 전 안정적인 기본 정책을 먼저 선택하세요. 클라이언트가 정책 그룹을 지원한다면 사용 가능한 회선 중에서 선택하도록 할 수 있습니다. 마지막으로 사용한 노드만 기억하는 방식이라면 해당 노드가 만료되었을 때 계속 재시도할 수 있습니다. 임시 테스트 노드를 장기 기본값으로 지정하지 말고, TUN 호환성을 확인하기 전에는 시스템 시작과 함께 자동 실행하도록 설정하지 마세요.
구독 자동 업데이트를 사용하면 클라이언트가 회선 변경 사항을 받을 수 있지만, 중요한 회의나 대용량 파일 전송 중에는 업데이트를 피하는 것이 좋습니다. 일부 클라이언트는 업데이트 후 구성을 다시 불러오기 때문입니다. 업데이트 후 노드가 사라졌다면 먼저 구독 그룹과 필터 조건을 확인하고 업데이트 로그를 살펴보세요. 로컬 설정을 바로 모두 삭제할 필요는 없습니다.
Windows의 시작 앱 관리에서 클라이언트가 로그인과 함께 실행되도록 허용되었는지 확인할 수 있습니다. 클라이언트 설정을 켰는데도 실행되지 않으면 시스템 시작 항목이 비활성화되어 있는지 확인하세요. 관리자 권한으로 실행하면 시작 동작에 영향을 줄 수 있습니다. 일반 계정으로 로그인할 때 권한 상승이 필요한 프로그램은 알림 없이 실행되지 않을 수 있습니다. 클라이언트 문서에 따라 필요한 네트워크 서비스를 설치하는 편이 전체 화면을 계속 높은 권한으로 실행하는 것보다 적절합니다.
절전 모드에서 복귀하거나 네트워크를 전환한 뒤 기존 연결이 이미 끊겼는데도 클라이언트 화면에는 잠시 연결 상태로 표시될 수 있습니다. 네트워크 변경 후 재연결을 지원하는 클라이언트는 일반적으로 세션을 다시 설정합니다. 복구되지 않으면 연결을 끊었다가 다시 연결해 보세요. 유선 네트워크, 무선 네트워크, 가상 네트워크 어댑터 사이를 자주 전환한다면 기본 경로와 DNS가 함께 갱신되는지 중점적으로 확인해야 합니다.
Windows에서 흔한 연결 문제의 점검 순서
네트워크 문제를 점검할 때 가장 효과적인 방법은 한 번에 하나의 조건만 변경하는 것입니다. 먼저 구독 업데이트 가능 여부를 확인하고, 다음으로 노드 핸드셰이크 가능 여부를 확인한 뒤 대상 앱이 프록시를 사용하는지 판단하고, 마지막으로 DNS, 분할 라우팅, 시스템 드라이버를 점검하세요. 여러 설정을 한꺼번에 바꾸면 원래 단순했던 문제도 재현하기 어려워집니다.
클라이언트는 연결되지만 웹페이지가 열리지 않음
먼저 시스템 프록시가 켜져 있는지, 브라우저가 독립 프록시 설정을 사용하는지 확인하세요. 그런 다음 DNS가 결과를 반환하는지 살펴보세요. 회선을 바꿔도 동일하다면 다른 프록시 도구와 네트워크 필터 프로그램을 잠시 종료해 로컬 포트나 시스템 프록시가 중복으로 사용되지 않도록 하세요. TUN 모드에서는 가상 네트워크 어댑터에 경로와 DNS가 설정되었는지도 확인해야 합니다.
브라우저는 정상인데 데스크톱 앱이 연결되지 않음
이는 일반적으로 브라우저는 시스템 프록시를 따르지만 데스크톱 앱은 그렇지 않다는 뜻입니다. 먼저 대상 앱에서 프록시 설정을 제공하는지 확인하세요. 설정이 없다면 클라이언트 호환성을 확인한 뒤 TUN 모드를 테스트할 수 있습니다. 작업 표시줄 아이콘만으로 앱 트래픽이 회선을 사용한다고 판단하지 마세요. 클라이언트 연결 로그나 프로세스별 트래픽 기록이 더 유용합니다.
구독 업데이트 후 회선이 표시되지 않음
구독 업데이트가 성공했는지, 클라이언트에서 노드 필터가 활성화되어 있는지, 현재 코어가 구독에 포함된 프로토콜을 지원하는지 확인하세요. 오래된 코어는 Hysteria2, TUIC 또는 새로운 전송 매개변수를 인식하지 못할 수 있습니다. 이때는 알 수 없는 필드를 직접 삭제하지 말고 서비스 패널에서 클라이언트 또는 코어를 업데이트하세요.
연결 후 로컬 웹사이트 또는 로컬 네트워크가 작동하지 않음
먼저 전체 모드에서 규칙 모드로 전환하고 로컬 네트워크 주소가 직접 연결로 유지되는지 확인하세요. TUN을 사용한다면 가상 네트워크 어댑터의 경로가 로컬 네트워크 대역을 덮어쓰는지 살펴보세요. 기업 네트워크와 가정용 로컬 네트워크가 같은 사설 대역을 사용할 수 있고, 가상 머신이나 컨테이너가 추가되면 충돌이 더 쉽게 발생합니다. 모든 트래픽을 노드로 강제하기보다 실제 라우팅 테이블에 맞춰 조정해야 합니다.
UDP 프로토콜로 연결을 설정할 수 없음
Hysteria2와 TUIC는 UDP에 의존합니다. 현재 네트워크에서 UDP를 제한하면 클라이언트가 시간 초과를 일으키거나 폴백에 실패할 수 있습니다. 먼저 서버에서 제공하는 호환 회선으로 전환해 기본 네트워크와 구독이 정상인지 확인한 다음 UDP 환경 문제인지 판단하세요. 특정 UDP 회선의 실패를 구독 전체를 사용할 수 없다는 뜻으로 바로 해석하지 마세요.
다른 플랫폼에서는 되지만 Windows에서는 작동하지 않음
플랫폼마다 네트워크 처리 방식이 다릅니다. macOS와 iOS는 일반적으로 시스템 네트워크 확장 또는 시스템 구성으로 권한을 얻고, Android는 시스템이 제공하는 VPN 서비스 인터페이스를 사용하며, Linux는 데몬, 라우팅, 방화벽 규칙에 의존하는 경우가 많습니다. Windows에서는 시스템 프록시, TUN 드라이버, 네트워크 인터페이스 우선순위가 관련될 수 있습니다. 같은 구독이 다른 플랫폼에서 작동한다는 것은 서버 구성이 기본적으로 유효하다는 뜻일 뿐이며, Windows 클라이언트 코어, 드라이버, 프록시 모드는 별도로 확인해야 합니다.
기본 구성을 마친 뒤에는 정상 작동이 확인된 설정을 하나 저장하고, 이후 사용자 지정 규칙, TUN, 앱별 분할 라우팅, 자동 연결을 단계적으로 추가하는 것이 좋습니다. 나중에 조정으로 문제가 생겨도 작동하는 상태로 빠르게 되돌릴 수 있습니다. Windows 네트워크 가속의 핵심은 옵션을 더 많이 쌓는 것이 아니라 구독, 프로토콜, 회선, 트래픽 처리 방식, DNS 경로가 서로 일치하도록 구성하는 데 있습니다.