이 Windows VPN 설정 가이드는 빈 바탕화면에서 시작합니다. 먼저 클라이언트 출처를 확인한 뒤 구독을 가져오고, 노드를 선택하고, 시스템 프록시를 켠 다음 출구 주소와 DNS를 확인합니다. 핵심은 특정 버튼을 켜는 데 있지 않고 클라이언트, 구독, 노드, 프록시 모드가 각각 어떤 역할을 하는지 이해하는 데 있습니다. 소프트웨어 화면의 버튼 이름이 조금 달라도 같은 흐름으로 설정을 완료할 수 있습니다.
시작하기 전에 두 가지를 준비해야 합니다. Windows와 호환되는 클라이언트와 계정 패널에서 제공하는 구독 링크입니다. 클라이언트는 설정을 읽고 연결을 구성하며 지정한 트래픽을 처리합니다. 구독 링크는 노드, 프로토콜, 업데이트 경로를 전달합니다. 둘 다 필요하지만 같은 것은 아닙니다.
Windows 클라이언트와 설치 출처부터 올바르게 선택하기
먼저 클라이언트가 구독에 포함된 프로토콜과 호환되는지 확인해야 합니다. 일반적인 구독에는 Shadowsocks, VMess, Trojan, VLESS, Hysteria2 또는 TUIC가 포함될 수 있습니다. 클라이언트 이름이 비슷해도 지원 범위가 같은 것은 아닙니다. 기존 시스템 프록시만 지원하는 도구는 TUN, 분할 라우팅, DNS 제어 기능을 제공하지 않을 수 있습니다. 다운로드하기 전에 서비스 패널의 권장 클라이언트와 호환성 안내를 확인하세요.
| 프로토콜 | 전송 특성 | 클라이언트 확인 항목 | 적합성 판단 |
|---|---|---|---|
| Shadowsocks | 암호화 프록시로, 설정 구조가 비교적 간단함 | 암호화 방식 지원 여부 | 호환성이 넓어 일반 웹과 앱 트래픽에 적합 |
| VMess | 관련 프록시 생태계에서 흔히 사용되며 다양한 전송 계층과 함께 구성 가능 | 전송 방식, TLS 및 호스트 매개변수가 모두 포함되어 있는지 | 클라이언트가 구독의 모든 필드를 올바르게 해석해야 함 |
| Trojan | 일반적으로 TLS를 기반으로 연결 | 인증서 검증과 서버 이름이 유지되는지 | 오류를 피하려고 인증서 검증을 임의로 끄면 안 됨 |
| VLESS | 프로토콜 자체는 콘텐츠 암호화를 담당하지 않으며 일반적으로 외부 보안 전송에 의존 | TLS, 전송 계층과 클라이언트 코어 버전이 호환되는지 | 설정 필드가 누락되면 연결이 구성되지 않을 수 있음 |
| Hysteria2 | QUIC 기반이며 주로 UDP 사용 | 로컬 네트워크에서 UDP를 허용하는지, 클라이언트 코어가 지원하는지 | 네트워크에서 UDP가 제한되면 기대한 성능을 내지 못할 수 있음 |
| TUIC | 마찬가지로 QUIC과 UDP 기반 | 프로토콜 구현과 인증 필드가 호환되는지 | 호환되는 네트워크에서 테스트하기에 적합하며 노드 이름만 보고 판단하지 않는 것이 좋음 |
설치 파일은 서비스 패널, 클라이언트 프로젝트의 공식 릴리스 페이지 또는 사이트에서 명확히 제공하는 클라이언트 다운로드 경로에서 받아야 합니다. 다운로드 후 파일 이름, 게시자 정보와 아키텍처를 먼저 확인하세요. 대부분의 일반적인 컴퓨터는 데스크톱용 표준 아키텍처를 사용하지만 아이콘만 보고 설치 파일이 올바르다고 판단해서는 안 됩니다. 배포자가 해시 값을 제공한다면 설치 전에 대조하세요. Windows에서 출처 경고가 표시되면 무시하지 말고 다운로드 경로로 돌아가 파일을 확인해야 합니다.
- ✅ 클라이언트가 구독에 사용된 프로토콜을 명확히 지원함
- ✅ 설치 파일이 패널 또는 프로젝트의 공식 릴리스 경로에서 제공됨
- ✅ Windows에 표시된 파일 이름이 다운로드 안내와 일치함
- ✅ 클라이언트에 시스템 프록시, 규칙 기반 분할 라우팅 또는 TUN 모드가 있음
- ❌ 클라우드 저장소 재공유 파일, 메신저 첨부 파일 또는 출처가 낯선 다운로드 사이트에서 설치 프로그램을 받지 않음
- ❌ 인증서 오류를 없애려고 서버 인증서 검증을 바로 끄지 않음
설치 프로그램을 실행한 뒤에는 보통 “설치” 또는 “다음”을 눌러 완료하면 됩니다. 클라이언트에서 포터블 버전을 제공한다면 쓰기 권한이 있는 고정 폴더에 압축을 풀고, 임시 다운로드 폴더에 장기간 보관하지 마세요. 처음 실행할 때 Windows 방화벽에서 네트워크 액세스를 허용할지 물을 수 있습니다. 프로그램 이름이 방금 설치한 클라이언트와 같은지 확인한 뒤 현재 네트워크 환경에 맞게 권한을 부여하세요. 확실하지 않다면 먼저 개인 네트워크만 허용하고, 이후 방화벽 설정에서 조정할 수 있습니다.
구독 링크를 받아 처음으로 가져오기
계정 패널에 로그인한 뒤 “구독”, “원클릭 구독”, “클라이언트 설정” 또는 비슷한 의미의 메뉴를 찾으세요. 페이지에는 링크 복사, 클라이언트로 가져오기, QR 코드 표시 등의 방법이 제공되는 경우가 많습니다. Windows 데스크톱에서는 이후 업데이트에 필요한 주소를 유지할 수 있으므로 “구독 링크 복사”를 우선 사용하세요. 노드를 하나씩 복사하면 정적 설정만 얻을 수 있어 노드가 바뀌어도 자동으로 동기화되지 않습니다.
복사한 뒤 클라이언트를 열고 “구독”, “구성 파일” 또는 “구성 관리” 메뉴를 찾으세요. 일반적인 경로는 새 구독을 추가한 다음 이름 입력란에 알아보기 쉬운 이름을 적고 주소 입력란에 링크를 붙여 넣은 뒤 저장하는 방식입니다. 일부 클라이언트는 “클립보드에서 가져오기”를 제공하며, 클릭하면 링크를 바로 인식합니다. 성공하면 화면에 구독 항목이 나타나고 노드 목록에 지역, 회선 유형 또는 프로토콜 이름이 표시됩니다.
- 계정 패널에서 복사: 구독 메뉴 옆의 복사 버튼을 클릭하세요. “복사됨” 안내가 표시되면 다른 곳에 붙여 넣어 테스트하지 마세요.
- 클라이언트에서 추가: 구독 또는 구성 관리로 이동해 개별 로컬 노드가 아니라 원격 구독 추가를 선택하세요.
- 입력하고 저장: 전체 주소를 붙여 넣고 구독에 로컬 이름을 지정한 다음 저장 또는 확인을 클릭하세요.
- 업데이트 실행: 방금 만든 구독을 선택하고 업데이트를 클릭하세요. 노드 목록이 나타나거나 업데이트 시간이 바뀌면 클라이언트가 설정을 읽은 것입니다.
- 구성 선택: 일부 클라이언트는 가져온 뒤 해당 구성 파일을 별도로 활성화해야 합니다. 현재 구성 이름이 방금 가져온 구독과 일치하는지 확인하세요.
형식을 지원하지 않는다는 안내가 표시된다면 보통 클라이언트 유형이 맞지 않거나, 구독 형식이 현재 코어와 호환되지 않거나, 복사한 내용이 원격 구독 주소가 아닌 경우입니다. 이때는 계정 패널로 돌아가 해당 Windows 클라이언트 형식을 다시 선택하세요. 요청 실패가 표시되면 먼저 시스템에서 다른 프록시 도구를 종료하고 여러 클라이언트가 동시에 프록시 설정을 변경하지 않는지 확인한 뒤 다시 업데이트하세요.
가져오기를 완료한 뒤에도 “구독 업데이트”와 “클라이언트 업데이트”를 구분해야 합니다. 전자는 노드와 서비스에서 전달한 설정을 새로 고치고, 후자는 데스크톱 프로그램과 프록시 코어를 업그레이드합니다. 구독을 업데이트해도 클라이언트가 자동으로 업그레이드되지는 않으며, 클라이언트를 업그레이드해도 구독 새로 고침을 대신하지 않습니다. 프로토콜 호환성 문제를 확인할 때는 두 메뉴를 모두 점검해야 합니다.
용도에 맞게 노드 선택하기: 지연 시간만 보지 않기
노드 목록이 나타난 다음에는 지역을 무작정 클릭하지 말고 먼저 사용 목적을 정하세요. 웹 검색, 다운로드, 동영상, 원격 업무와 지연 시간이 중요한 상호작용은 각각 필요한 회선 조건이 다릅니다. 클라이언트에 표시되는 지연 시간은 대개 한 번 측정한 결과로, 로컬 네트워크, 측정 방식과 서버 응답의 영향을 받습니다. 초기 선별에는 유용하지만 실제 처리량, 안정성 또는 대상 웹사이트의 접속 품질을 단독으로 보여 주지는 않습니다.
노드 이름에는 “직접 연결”, “중계”, “IEPL”과 같은 설명이 자주 표시됩니다. 직접 연결은 로컬 네트워크가 해외 진입점에 바로 연결되는 방식으로 경로가 단순하지만, 국제 공용망의 변동이 사용 경험에 더 직접적으로 반영될 수 있습니다. 중계는 가까운 접속 지점에 먼저 연결한 뒤 서비스 측에서 출구로 전달하는 방식이며, 진입 경로와 라우팅을 더 관리하기 위한 목적이 있습니다. IEPL은 국제 이더넷 전용 회선을 뜻합니다. 서비스 제공자가 IEPL을 표시하더라도 백본 경로에 해당 전용 회선 자원을 사용한다는 의미일 뿐, 사용자 장치에서 출구까지 모든 구간이 공용망을 벗어난다는 뜻은 아닙니다.
| 회선 유형 | 연결 경로 | 주요 특징 | 선택 방법 |
|---|---|---|---|
| 직접 연결 | 로컬 네트워크가 대상 지역의 진입점에 직접 연결 | 구조가 단순하며 로컬 통신망과 국제 공용망의 영향을 더 많이 받음 | 먼저 대상 웹사이트를 테스트한 뒤 지속적인 접속 안정성을 확인 |
| 중계 | 로컬에서 중계 노드로 접속한 뒤 출구로 전달 | 진입 경로가 비교적 집중되어 일부 네트워크 환경의 변동을 줄일 수 있음 | 같은 지역의 직접 연결 노드와 교차 테스트하기에 적합 |
| IEPL | 서비스 측 백본 일부가 국제 이더넷 전용 회선을 사용 | 라우팅을 더 세밀하게 제어할 수 있지만 실제 대상 접속 결과를 기준으로 판단해야 함 | 지속적인 안정성이 중요한 작업에 사용하고 예비 회선을 남겨 두기 |
지역을 선택할 때는 먼저 대상 서비스가 있는 지역을 기준으로 검색한 뒤 지리적 거리를 고려하세요. 특정 지역의 콘텐츠에 접속해야 한다면 노드 이름의 “고속” 표시보다 출구 지역이 맞는지가 중요합니다. 일반 검색과 문서 접속은 가까운 지역부터 선택해 볼 수 있습니다. 동영상은 대상 플랫폼을 직접 열어 화질 전환과 지속적인 버퍼링 상태를 확인하세요. 원격 회의에서는 음성이 끊기지 않는지와 업로드 방향을 함께 살펴야 하며, 웹 다운로드 테스트만으로 판단해서는 안 됩니다.
- ✅ 먼저 대상 웹사이트나 앱을 정한 뒤 해당 출구 지역을 선택
- ✅ 같은 대상에서 직접 연결, 중계와 전용 회선 표시 노드를 비교
- ✅ 클라이언트 측정 결과만 보지 말고 실제 업무 페이지에 연속 접속
- ✅ 자주 사용하는 용도마다 예비 회선 하나를 확보
- ❌ 노드 이름의 홍보 문구를 성능 결론으로 받아들이지 않음
- ❌ 다운로드 중에는 연결이 끊길 수 있으므로 노드를 자주 바꾸지 않음
시스템 프록시, 규칙 기반 분할 라우팅 또는 TUN 모드 켜기
노드를 선택한 뒤 클라이언트에 “연결됨”이라고 표시되어도 Windows 트래픽이 해당 회선을 통과한다는 뜻은 아닙니다. 대부분의 클라이언트는 “시스템 프록시”, “시스템 프록시로 설정” 또는 비슷한 기능을 추가로 켜야 합니다. 시스템 프록시는 Windows의 프록시 설정을 변경하므로 브라우저와 시스템 설정을 따르는 앱은 일반적으로 프록시를 사용합니다. 시스템 프록시를 읽지 않는 앱은 계속 직접 연결될 수 있습니다.
규칙 기반 분할 라우팅은 어떤 요청을 프록시로 보낼지, 어떤 요청을 직접 연결로 둘지 결정합니다. 일반적인 모드에는 규칙, 전체와 직접 연결이 있습니다. 규칙 모드는 도메인, 주소 대역과 사전 설정 목록에 따라 판단하므로 일상적인 기본값으로 적합합니다. 전체 모드는 더 많은 트래픽을 현재 노드로 보내 “규칙 누락으로 직접 연결되는지”를 잠시 확인할 때 유용합니다. 직접 연결 모드는 노드를 거치지 않으며 로컬 네트워크 복구나 비교 테스트에 사용할 수 있습니다.
TUN 모드는 가상 네트워크 인터페이스를 만들어 더 낮은 계층에서 트래픽을 처리합니다. 따라서 시스템 프록시를 따르지 않는 앱도 포함할 수 있고 UDP를 다뤄야 하는 환경에도 적합합니다. 일반적으로 관리자 권한이 필요하며 다른 가상 네트워크 어댑터, 보안 소프트웨어, 기업 네트워크 정책 또는 기존 프록시 클라이언트와 충돌할 수 있습니다. 처음 사용할 때는 같은 종류의 도구를 종료한 뒤 TUN을 켜세요. 네트워크가 바로 끊기면 TUN을 끄고 라우팅, DNS와 가상 네트워크 어댑터 상태를 확인하세요.
시스템 프록시는 브라우저와 일반적인 데스크톱 앱에 적합하고, TUN은 시스템 프록시를 읽지 않거나 UDP가 필요하거나 트래픽을 일괄 처리해야 하는 프로그램에 적합합니다. 둘은 강도 차이가 아니라 서로 다른 트래픽 진입 방식입니다.
분할 라우팅 오류는 주로 두 가지 상황에서 발생합니다. 대상 도메인이 프록시 규칙과 일치하지 않거나, 원래 직접 연결해야 하는 로컬 서비스가 원격 노드로 전송되는 경우입니다. 전자는 잠시 전체 모드로 전환해 확인할 수 있습니다. 전체 모드에서는 정상이고 규칙 모드에서만 안 된다면 문제는 대개 규칙 일치에 있습니다. 후자는 규칙 모드로 되돌린 뒤 로컬 네트워크, 로컬 서비스 또는 명확히 직접 연결해야 하는 도메인을 직접 연결 규칙에 추가하세요. 규칙을 바꾼 뒤에는 설정을 저장하고 연결을 다시 시작해야 합니다. 이미 구성된 세션이 이전 경로를 계속 사용할 수 있기 때문입니다.
출구 주소, DNS와 실제 앱 트래픽 확인하기
연결 확인은 단계별로 진행해야 합니다. 먼저 클라이언트 로그에 지속적인 오류가 없는지 확인하고, 다음으로 출구 주소와 DNS를 점검한 뒤 실제 대상 앱을 엽니다. 클라이언트 아이콘 색상만 바뀐 것은 화면 상태일 뿐 완전한 확인 결과가 아닙니다.
- 연결 상태 확인: 노드를 선택하고 시스템 프록시 또는 TUN을 켜세요. 화면에 현재 노드가 표시되어야 하며 로그에 시간 초과, 인증 실패 또는 인증서 오류가 반복해서 나타나지 않아야 합니다.
- 출구 주소 확인: 네트워크 진단을 열어 연결 전후의 공인 출구 주소와 지역을 비교하세요. 전혀 바뀌지 않았다면 먼저 시스템 프록시, 브라우저 프록시 확장 프로그램과 분할 라우팅 모드를 확인하세요.
- DNS 확인: DNS 요청이 원치 않는 로컬 리졸버에서 계속 직접 처리되는지 확인하세요. 출구는 바뀌었지만 DNS 경로가 이상하다면 클라이언트의 DNS 제어 기능을 켜거나 현재 설정에 맞는 원격 DNS 설정을 사용하세요.
- 대상 서비스 테스트: 실제로 사용하려는 웹사이트나 앱을 열어 페이지 로딩, 로그인, 재생 또는 파일 요청을 완료하세요. 일반 테스트 페이지보다 대상 서비스의 사용 가능 여부가 더 중요한 판단 기준입니다.
- 연결 해제 후 비교: 연결을 끊고 진단 페이지를 새로 고쳐 출구가 복구되는지 확인하세요. 이렇게 해야 브라우저 캐시, 페이지 캐시 또는 남아 있는 프록시로 인한 오판을 배제할 수 있습니다.
DNS 누수는 앱 트래픽이 원격 회선을 통과하지만 도메인 조회는 원치 않는 로컬 경로에서 나가는 현상을 뜻합니다. 이로 인해 지역 판단이 일치하지 않거나 일부 웹사이트가 비정상적으로 로드될 수 있습니다. 클라이언트의 DNS 모드, 브라우저 내장 보안 DNS, 시스템 네트워크 어댑터 설정과 TUN의 DNS 제어 상태를 확인하세요. 여러 DNS 정책을 동시에 적용하지 마세요. 문제가 생겼을 때 실제로 어떤 계층이 적용되었는지 확인하기 어려워집니다.
브라우저는 되는데 특정 데스크톱 앱만 작동하지 않는다면 해당 앱이 시스템 프록시를 읽지 않거나 규칙이 처리하지 않는 UDP 트래픽을 사용할 가능성이 큽니다. 먼저 클라이언트 로그에서 해당 앱의 대상 도메인이 나타나는지 확인한 뒤 잠시 전체 모드로 전환해 비교하세요. 그래도 트래픽 기록이 없다면 TUN을 테스트합니다. 모든 앱에 접속할 수 없다면 노드 연결성, 구독 유효성 및 로컬 네트워크 제한으로 돌아가 점검해야 하며, 분할 라우팅 규칙을 계속 수정해서는 안 됩니다.
- ✅ 클라이언트 로그에서 연결이 구성되고 반복 오류가 없음
- ✅ 네트워크 진단에서 출구 지역이 선택한 회선과 일치함
- ✅ DNS 조회 경로가 현재 프록시 방식과 일치함
- ✅ 대상 웹사이트나 앱에서 실제 작업을 완료할 수 있음
- ✅ 연결을 끊으면 출구가 복구되고 연결 전후 결과를 재현할 수 있음
- ❌ 클라이언트 버튼의 색상 변화만으로 성공 여부를 판단하지 않음
시작 시 자동 실행, 자동 연결과 구독 업데이트 설정
확인이 끝난 뒤 자동화 기능을 설정하세요. 시작 시 자동 실행, 시작 후 연결과 구독 자동 업데이트는 서로 독립된 세 가지 설정입니다. 시작 시 자동 실행만 켜면 클라이언트가 작업 표시줄에 나타날 뿐 노드에는 연결되지 않을 수 있습니다. 자동 연결만 켜도 프로그램이 Windows와 함께 시작되지 않으면 작동하지 않습니다. 구독 업데이트는 원격 노드 목록을 새로 고치는 기능으로 앞의 두 설정과 관계가 없습니다.
클라이언트의 “설정”, “일반” 또는 “기본 설정”으로 이동해 “시작 시 실행”, “시스템 시작 시 실행”과 같은 항목을 찾으세요. 활성화한 뒤 Windows의 “설정 → 앱 → 시작 프로그램”에서 해당 클라이언트가 허용 상태인지 확인할 수 있습니다. Windows 버전에 따라 메뉴 이름이 조금 다를 수 있으며, 작업 관리자의 시작 앱 페이지에서도 확인할 수 있습니다.
그다음 “시작 후 연결”, “마지막 연결 복원” 또는 “시스템 프록시 자동 활성화”를 찾으세요. 회사 네트워크, 공용 네트워크와 가정용 네트워크를 자주 오간다면 우선 프로그램 자동 실행만 켜고 수동 연결을 유지하는 것이 좋습니다. 네트워크 환경이 고정되어 있다면 마지막 노드 복원을 켜세요. TUN을 사용할 때는 클라이언트가 시작 단계에서 필요한 권한을 얻을 수 있는지도 확인해야 합니다. 프로그램은 실행되었지만 가상 인터페이스가 구성되지 않을 수 있습니다.
구독 업데이트는 구독 관리에서 자동 새로 고침으로 설정하거나 수동 업데이트로 유지할 수 있습니다. 어떤 방식을 사용하든 수동 메뉴 위치를 알아 두세요. 구독을 선택하고 “구독 업데이트” 또는 “새로 고침”을 클릭하면 됩니다. 노드 이름, 지역 목록 또는 회선 설정이 바뀌면 먼저 구독을 업데이트한 뒤 노드를 다시 선택하세요. 업데이트 후 로컬 사용자 지정 규칙이 사라진다면 원격 설정이 덮어쓰는 위치에 규칙이 저장된 것일 수 있습니다. 클라이언트에서 제공하는 오버라이드, 병합 또는 로컬 규칙 영역에 개인 규칙을 저장하세요.
문제 유형별로 원인 계층 찾기
구독은 업데이트되지만 모든 노드 연결에 실패함
이는 클라이언트가 구독 주소에는 접속할 수 있지만 노드 연결 단계에 문제가 있다는 뜻입니다. 먼저 로그의 오류 유형을 확인하세요. 인증 실패는 일반적으로 설정이나 구독 상태를 가리킵니다. 인증서 오류가 있으면 시스템 시간, 서버 이름과 클라이언트 코어를 확인해야 하며 검증을 바로 꺼서는 안 됩니다. 시간 초과는 현재 네트워크, 노드 경로 또는 UDP 제한과 관련될 수 있습니다. Hysteria2와 TUIC만 실패하고 다른 프로토콜은 작동한다면 로컬 네트워크가 UDP를 처리하는 방식을 중점적으로 확인하세요.
브라우저는 접속되지만 데스크톱 앱은 계속 직접 연결됨
먼저 데스크톱 앱이 시스템 프록시를 지원하는지 확인하세요. 일부 앱은 자체 프록시 설정만 읽고, 일부는 독립적인 네트워크 스택을 사용합니다. 앱 설정에서 “시스템 프록시 사용”을 선택하거나 클라이언트의 TUN 모드로 전환해 트래픽을 처리할 수 있습니다. 활성화하기 전에 다른 가상 네트워크 도구를 종료해 기본 경로가 중복으로 변경되지 않게 하세요.
노드를 바꿔도 웹사이트에 이전 지역이 표시됨
브라우저가 이전 연결을 유지하거나 DNS 캐시가 아직 갱신되지 않았거나, 웹사이트 계정의 지역 설정이 출구 주소보다 우선하거나, 분할 라우팅 규칙이 해당 도메인을 직접 연결로 처리하는 것이 원인일 수 있습니다. 먼저 관련 탭을 닫고 다시 연 뒤 네트워크 진단 결과를 확인하세요. 출구는 이미 바뀌었는데 웹사이트 표시가 그대로라면 노드를 계속 바꾸지 말고 DNS, 사이트 계정 설정과 캐시를 점검하세요.
클라이언트를 종료한 뒤 인터넷이 정상적으로 되지 않음
대개 시스템 프록시가 복구되지 않았거나 TUN 가상 인터페이스와 라우팅 설정이 남아 있기 때문입니다. 클라이언트를 다시 열고 시스템 프록시와 TUN을 먼저 끈 다음 프로그램 메뉴에서 정상적으로 종료하세요. 그래도 복구되지 않으면 Windows 프록시 설정에서 수동 프록시가 꺼져 있는지 확인하고, 네트워크 어댑터에 비정상적으로 활성화된 가상 인터페이스가 있는지 점검하세요. 이름을 모르는 시스템 어댑터를 바로 삭제하지 말고 어느 클라이언트에 속하는지 먼저 확인하세요.
구독 업데이트 후 사용자 지정 내용이 사라짐
원격 구독을 업데이트하면 일반적으로 서비스에서 전달한 노드 설정이 다시 구성됩니다. 구독으로 생성된 설정을 직접 편집하면 다음 새로 고침 때 덮어써질 수 있습니다. 장기간 유지해야 하는 분할 라우팅 규칙, 노드 그룹 선택과 DNS 조정은 클라이언트에서 제공하는 오버라이드 또는 병합 설정에 저장하세요. 이러한 기능이 없다면 업데이트 전에 로컬 설정을 백업하고 노드 구독과 개인 규칙을 분리해 관리하세요.
이 단계를 완료하면 Windows에서 다시 확인할 수 있는 설정 기록이 만들어집니다. 클라이언트를 어디에서 다운로드했는지, 구독을 어디에서 새로 고치는지, 현재 앱의 트래픽을 시스템 프록시와 TUN 중 무엇이 처리하는지, 출구와 DNS가 예상과 일치하는지 알 수 있습니다. 이후 문제가 생기면 같은 순서로 점검하는 편이 여러 클라이언트를 바꾸는 것보다 대체로 빠르게 원인을 찾을 수 있습니다.