macOS VPN 처음부터 시작하기: 설치·가져오기·권한 설정

macOS에서 VPN을 설정할 때 중요한 것은 클라이언트에 구독 링크를 붙여 넣는 것만이 아닙니다. 클라이언트 선택과 설치, 네트워크 확장 허용, 시스템 프록시와 가상 네트워크 인터페이스의 차이 이해, 구독 가져오기 및 업데이트, 적합한 회선 선택, DNS와 분할 설정 확인까지 전체 과정을 살펴봐야 합니다. 일부 단계만 완료하면 “클라이언트에는 연결됨으로 표시되지만 브라우저에 접속할 수 없는” 문제나 “일부 앱이 여전히 로컬 네트워크를 사용하는” 문제가 발생하기 쉽습니다.

이 글에서는 특정 클라이언트 이름에 의존하지 않는 설정 방법을 소개합니다. 클라이언트마다 버튼 위치는 다르지만 기본 단계는 대체로 같습니다. 먼저 프로세서 아키텍처와 클라이언트 호환성을 확인하고, 시스템 권한을 승인한 다음 서비스 제공업체의 구독을 가져옵니다. 마지막으로 주소, DNS, 분할 설정과 앱 동작을 통해 연결을 확인합니다. 문제가 생기면 데이터를 따라 단계별로 점검해야 하며, 클라이언트를 반복해서 삭제하고 다시 설치하는 방식은 피하는 것이 좋습니다.

설치 전에 클라이언트 유형과 작동 모드부터 확인하기

macOS의 프록시 클라이언트는 크게 시스템 프록시 방식과 가상 네트워크 인터페이스 방식으로 나눌 수 있습니다. 시스템 프록시 방식은 macOS의 프록시 설정을 변경해 시스템 프록시를 따르는 브라우저와 앱의 요청을 로컬 클라이언트로 전달합니다. 가상 네트워크 인터페이스 방식은 일반적으로 시스템 네트워크 확장을 통해 더 많은 트래픽을 인계받고, 규칙에 따라 프록시 또는 직접 연결을 선택합니다. 많은 클라이언트가 두 모드를 모두 제공하지만 필요한 권한, 호환성 및 문제 해결 방법은 서로 다릅니다.

웹 접속만 처리한다면 시스템 프록시 모드가 상태를 확인하기 쉽습니다. 클라이언트의 프록시 스위치를 끄면 시스템 프록시 설정이 복원되어야 하고, 켜면 시스템 프록시를 지원하는 앱이 규칙 판단을 거치게 됩니다. 시스템 프록시를 읽지 않는 앱, 일부 명령줄 프로그램 또는 더 복잡한 DNS 경로까지 처리해야 한다면 가상 네트워크 인터페이스 모드를 고려할 수 있습니다. 이 모드가 본질적으로 더 빠르다는 뜻은 아닙니다. 처리하는 트래픽 범위가 넓고 네트워크 확장 권한과 라우팅 설정에 더 크게 의존한다는 의미입니다.

프로세서 아키텍처와 설치 출처 확인하기

클라이언트를 다운로드할 때는 먼저 ‘이 Mac에 관하여’에서 칩 정보를 확인한 뒤 현재 기기 아키텍처에 맞는 버전을 선택하세요. 범용 빌드는 서로 다른 아키텍처와 호환되는 경우가 많지만, 별도로 제공되는 빌드는 기기에 맞춰야 합니다. 클라이언트는 프로젝트 공식 배포 페이지, 서비스 제공업체 패널의 공식 다운로드 경로 또는 시스템 앱 스토어에서 받아야 하며 출처가 불분명한 재패키징 버전은 피하세요.

웹에서 다운로드한 앱을 처음 열 때 macOS에서 개발자 출처 확인을 요구할 수 있습니다. 시스템이 명확하게 차단한다면 먼저 다운로드 출처와 서명 정보를 확인하고, 시스템 보안 검사를 장기간 해제하는 것을 설치 절차로 삼지 마세요. 일부 클라이언트는 처음 실행할 때 시스템 프록시를 설정하거나 네트워크 확장을 만들고 구성을 저장하기 위한 보조 구성 요소를 설치합니다. 이때 시스템에서 Mac 관리자 자격 증명을 요구할 수 있는데, 이는 로컬 권한 승인 절차이며 구독 서비스 로그인 비밀번호와는 다릅니다.

주요 프로토콜과 클라이언트 호환성 이해하기

구독에는 Shadowsocks, VMess, Trojan, VLESS, Hysteria2 또는 TUIC 등의 프로토콜이 포함될 수 있습니다. 프로토콜 이름은 클라이언트와 원격 노드 사이에서 세션을 설정하는 방식을 나타낼 뿐 회선 품질을 의미하지는 않습니다. 노드를 해석하고 연결하려면 클라이언트가 해당 프로토콜을 구현해야 합니다. 구독 텍스트를 가져올 수 있다고 해서 포함된 모든 노드를 지원한다는 뜻은 아닙니다.

구독은 업데이트되지만 특정 유형의 노드만 계속 시작되지 않는다면 먼저 클라이언트 코어가 해당 프로토콜과 전송 조합을 지원하는지 확인하세요. 현재 네트워크에서 Hysteria2 또는 TUIC만 실패하고 다른 프로토콜은 연결된다면 로컬 라우터, 공용 네트워크 또는 상위 네트워크가 UDP를 제한하고 있을 가능성이 있습니다. 이 경우 구독 전체가 무효라고 단정해서는 안 됩니다.

macOS 네트워크 확장 및 프록시 권한 승인하기

클라이언트에서 가상 네트워크 인터페이스를 처음 활성화하면 macOS에 VPN 구성 추가 또는 네트워크 확장 허용을 요청하는 시스템 대화상자가 표시되는 경우가 많습니다. 승인하기 전에 요청을 시작한 앱 이름을 확인하세요. 허용하면 시스템 설정의 네트워크 또는 VPN 관련 영역에 해당 구성이 표시됩니다. 클라이언트를 종료한 뒤에도 구성이 남아 있는지는 구현 방식에 따라 다르지만, 구성이 존재한다고 해서 트래픽이 전송 중이라는 뜻은 아닙니다. 클라이언트 상태와 실제 연결 결과를 함께 확인해야 합니다.

권한 대화상자를 닫거나 거부하면 클라이언트가 계속 시작 중으로 표시되거나 인터페이스를 만들 수 없다는 메시지가 나타날 수 있습니다. 먼저 클라이언트를 종료한 뒤 시스템 설정의 개인정보 보호 및 보안, 네트워크, VPN 또는 필터 관련 영역에서 승인 대기 항목이 있는지 확인하세요. 시스템 설정의 정확한 명칭은 macOS 버전과 클라이언트 구현에 따라 달라질 수 있으므로, 특정 메뉴 이름을 기계적으로 찾기보다 앱 이름, 네트워크 확장 상태와 관련 스위치를 확인하는 것이 중요합니다.

시스템 프록시 모드에서 확인할 항목

시스템 프록시를 활성화하면 macOS 네트워크 설정에서 현재 네트워크 서비스의 프록시 상태를 확인할 수 있습니다. 클라이언트는 보통 프록시 주소를 로컬 루프백 주소로 지정하고, 클라이언트가 수신 대기 중인 로컬 포트를 사용합니다. 이 포트를 원격 서버 포트로 직접 변경하지 마세요. 로컬 포트는 앱이 먼저 실행 중인 클라이언트에 요청을 전달하도록 하는 역할을 합니다.

클라이언트를 종료한 뒤 웹페이지가 갑자기 열리지 않는다면 시스템 프록시가 제대로 복원되지 않았을 수 있습니다. 클라이언트를 다시 시작한 다음 시스템 프록시 스위치를 정상적으로 끄는 편이 네트워크 서비스를 바로 삭제하는 것보다 안전한 경우가 많습니다. 시스템 설정에서 HTTP, HTTPS 또는 SOCKS 프록시가 더 이상 수신 대기하지 않는 로컬 주소를 가리키고 있지 않은지도 확인하세요. 남은 프록시 설정을 지운 뒤 클라이언트를 거치지 않는 기본 네트워크를 테스트합니다.

가상 네트워크 인터페이스 모드에서 확인할 항목

가상 네트워크 인터페이스 모드는 네트워크 확장이 관리하는 논리 인터페이스를 만들고 조건에 맞는 트래픽을 클라이언트로 보냅니다. 활성화할 때는 기본 라우팅, DNS 또는 네트워크 필터 규칙을 변경하는 다른 도구를 동시에 실행하지 않는 것이 좋습니다. 여러 네트워크 확장이 같은 데이터 경로를 차지하려 할 수 있기 때문입니다. 연결이 반복해서 끊겼다 재연결되거나 네트워크가 계속 전환되거나 잠자기 후 복귀하지 않는다면 먼저 현재 클라이언트만 남긴 뒤 연결을 다시 설정하세요.

구독 링크를 가져오고 업데이트 결과 확인하기

구독 링크는 일반적으로 서비스 패널에서 생성되며, 클라이언트는 이 주소를 통해 노드, 프로토콜 매개변수와 그룹 정보를 가져옵니다. 가져올 때는 클라이언트의 ‘URL에서 가져오기’, ‘구독 추가’ 또는 유사한 메뉴를 사용하세요. 전체 링크를 단일 서버 주소로 입력하면 안 됩니다. 일부 클라이언트는 클립보드에서 링크를 자동 인식하지만, 인식 후에도 구독 이름과 노드 목록이 정상적으로 표시되는지 확인해야 합니다.

구독 링크를 복사할 때 앞뒤 공백, 줄바꿈 또는 메신저가 추가한 이스케이프 문자가 함께 들어가지 않도록 주의하세요. 브라우저에 인코딩된 텍스트가 표시된다고 해서 구독에 문제가 있는 것은 아닙니다. 많은 구독은 사람이 읽는 웹페이지가 아니라 클라이언트가 해석하는 데이터입니다. 브라우저가 로그인 페이지나 오류 페이지로 이동한다면 링크가 완전하지 않거나 자격 증명이 만료되었거나 현재 네트워크가 요청을 변경했을 가능성이 있습니다.

가져온 뒤 바로 연결하지 말고 먼저 설정 확인하기

• 구독 이름이 서비스 패널의 해당 항목과 일치하는지 확인하세요.
• 노드 목록이 비어 있지 않고 지역 이름과 프로토콜 유형이 표시되는지 확인하세요.
• 클라이언트가 지원하지 않는 필드나 프로토콜을 보고하는지 확인하세요.
• 수동 업데이트를 한 번 실행해 인증 또는 파싱 오류 없이 완료되는지 확인하세요.
• 자동 업데이트가 직접 관리하는 로컬 분할 규칙을 덮어쓰지 않는지 확인하세요.

구독 업데이트는 서버에서 관리하는 노드 정보를 교체합니다. 클라이언트에서 구독 내 노드를 편집할 수 있더라도 수동 변경 사항은 다음 업데이트에서 사라질 수 있습니다. 사용자 지정 규칙이 필요하다면 클라이언트의 로컬 오버라이드, 규칙 세트 또는 구성 병합 기능을 사용해 서버 노드와 로컬 정책을 분리하는 편이 적절합니다.

구독 링크는 자격 증명처럼 취급해야 합니다. 공개된 구독 주소는 다른 사람이 구성을 가져가게 만들 수 있고 서버의 보안 조치를 유발할 수도 있습니다. 다른 Mac에서 사용해야 한다면 자신의 서비스 패널에서 다시 복사하고 공개 단축 링크나 온라인 변환 도구를 거치지 마세요. 기존 클라이언트의 사용을 중단하기 전에는 저장된 구독과 캐시 구성도 먼저 삭제할 수 있습니다.

노드 선택: 지역보다 중요한 것은 경로

가져오기에 성공한 뒤에는 먼저 대상 서비스와 가까운 지역에 있고 경로가 명확한 노드를 선택해 테스트하세요. 노드 이름의 국가나 도시는 보통 접속 지점을 나타내지만 로컬 환경에서 해당 지점까지의 전체 경로를 보여주지는 않습니다. 실제 사용 경험은 로컬 통신망, 진입 지점, 중계 방식, 출구 혼잡도와 대상 웹사이트의 라우팅에도 영향을 받습니다.

직접 연결 회선은 클라이언트가 원격 노드에 비교적 직접 연결하는 방식으로 경로가 단순하지만, 국제 구간의 품질은 공용 네트워크에 더 크게 좌우됩니다. 중계 회선은 가까운 진입 지점에 먼저 연결한 다음 중계 네트워크를 통해 출구로 전달해 일부 네트워크 환경에서 경로 안정성을 높이는 데 목적이 있습니다. IEPL 전용 회선은 국제 전송을 전용 경로에 배치해 일반 공용 네트워크 직접 연결과 다른 방식으로 라우팅합니다. 그렇다고 모든 네트워크에서 모든 앱이 반드시 더 빠른 것은 아니므로 현재 접속 네트워크와 대상 지역을 함께 확인해야 합니다.

회선을 선택할 때 클라이언트의 지연 시간 표시만 보지 마세요. 지연 시간 테스트는 진입 지점, 프록시 핸드셰이크 또는 특정 테스트 주소를 측정할 수 있으며, 실제 웹사이트와 TLS 세션을 설정하고 리소스를 다운로드하며 지속적으로 전송하는 과정과는 다릅니다. 더 신뢰할 수 있는 방법은 같은 지역의 여러 회선을 차례로 선택해 대상 웹사이트를 열고 로그인한 뒤 일정 시간 연속 작업을 수행해 안정적인 회선을 남기는 것입니다.

분할 규칙 설정으로 모든 트래픽이 같은 경로를 사용하지 않게 하기

분할 규칙은 특정 도메인, 주소 또는 앱 요청을 프록시로 보낼지, 직접 연결할지 또는 차단할지를 결정합니다. macOS를 일상적으로 사용할 때는 전역 프록시보다 규칙 모드가 로컬 서비스와 국제 웹사이트의 호환성을 유지하기 쉽습니다. 전역 모드는 짧은 진단에 적합합니다. 규칙 모드에서는 접속되지 않지만 전역 모드에서는 접속된다면 문제는 대개 노드 자체가 아니라 규칙 매칭, DNS 확인 또는 규칙 세트 업데이트에 있습니다.

규칙 판단의 기준으로는 도메인 접미사, 전체 도메인, 대상 주소 범위와 프로세스 정보가 흔히 사용됩니다. 도메인 규칙은 읽기 쉽지만 클라이언트가 도메인 정보를 확보할 수 있어야 합니다. 요청이 너무 일찍 주소로 변환되면 이후에는 주소 규칙으로만 처리될 수 있습니다. 프로세스 규칙은 클라이언트 권한과 구현에 의존하며, 모든 시스템 프록시 방식 클라이언트가 모든 앱을 안정적으로 식별할 수 있는 것은 아닙니다.

설정할 때는 먼저 구독과 함께 제공되는 기본 규칙을 사용해 기본 연결이 정상인지 확인한 뒤 로컬 오버라이드를 추가하세요. 처음부터 출처가 불분명한 대규모 규칙 세트를 여러 개 가져오면 중복 규칙, 우선순위 충돌과 만료된 도메인 때문에 문제 해결이 어려워집니다. 회사 인트라넷, 로컬 프린터 서비스 또는 LAN 기기를 직접 연결로 유지해야 한다면 로컬 주소와 내부 도메인의 직접 연결 경로를 명확히 남겨 두세요.

시스템 프록시와 명령줄 앱의 차이

브라우저는 대체로 시스템 프록시를 따르지만 터미널의 명령줄 도구는 자체 환경 변수나 구성 파일을 읽거나 완전히 직접 연결할 수 있습니다. 따라서 브라우저에 접속된다고 해서 터미널 트래픽도 클라이언트를 거친다고 볼 수는 없습니다. 클라이언트가 로컬 HTTP 또는 SOCKS 수신 주소를 제공한다면 각 도구의 문서에 따라 프록시 환경을 설정하세요. 테스트가 끝나면 임시로 설정한 환경 변수를 삭제해 클라이언트를 종료한 뒤에도 명령이 사용하지 않는 포트를 가리키지 않도록 합니다.

일부 데스크톱 앱은 자체 네트워크 스택을 구현해 시스템 프록시를 무시할 수 있습니다. 이런 앱에서는 브라우저 설정을 계속 바꾸기보다 먼저 가상 네트워크 인터페이스 모드를 시도하세요. 모드를 전환한 뒤 정상화된다면 노드와 구독 자체는 대체로 사용할 수 있고, 차이는 해당 앱이 시스템 프록시를 따르는지 여부에서 비롯된 것입니다.

DNS 경로와 발생 가능한 DNS 누출 확인하기

DNS는 도메인 이름을 주소로 변환합니다. 클라이언트가 이미 연결된 상태라도 도메인이 적절하지 않은 로컬 리졸버에서 처리되면 출구 지역과 일치하지 않는 결과가 반환되거나 도메인을 확인하지 못하거나 분할 규칙이 올바른 도메인 정보를 얻지 못할 수 있습니다. DNS 누출은 일반적으로 프록시 정책으로 처리되어야 할 조회 요청이 로컬 네트워크가 지정한 리졸버로 전송되어 예상과 다른 해석 경로가 발생하는 것을 뜻합니다.

시스템 프록시 모드에서 DNS를 프록시가 처리하는지는 클라이언트 구현, 브라우저 설정과 프로토콜 기능에 따라 달라집니다. 가상 네트워크 인터페이스 모드는 일반적으로 DNS를 일괄 관리하기 쉽지만 macOS의 암호화 DNS, 기업 네트워크 설정 또는 다른 필터 확장과 충돌할 수도 있습니다. 문제를 확인할 때는 추가 DNS 변경 도구를 잠시 비활성화하고 클라이언트 기본 설정만 남긴 뒤 도메인 확인이 정상화되는지 관찰하세요.

대상 웹사이트가 지역에 따라 다른 주소를 반환한다면 DNS 출구와 프록시 출구가 일치하지 않아 연결 결과에 영향을 줄 수 있습니다. 이때 클라이언트에서 원격 DNS, 규칙 DNS 또는 가상 주소 매핑 같은 기능을 활성화했는지 확인하세요. 가상 주소 모드는 도메인에 내부 매핑 주소를 할당한 뒤 클라이언트가 도메인을 복원하고 규칙을 적용합니다. 이러한 주소를 실제 원격 주소로 간주해 장기 구성에 저장해서는 안 됩니다.

연결 후 확인 절차 진행하기

클라이언트에 ‘연결됨’이 표시된다는 것은 로컬 구성 요소와 특정 원격 세션이 설정되었을 가능성을 보여줄 뿐이며 종단 간 확인을 대신할 수 없습니다. 확인 과정에는 기본 네트워크, 출구 변경, 대상 서비스, DNS와 잠자기 후 복귀 상태를 모두 포함해야 합니다. 한 번에 하나의 변수만 변경해야 문제가 노드, 프로토콜, 규칙 또는 로컬 권한 중 어디에서 비롯되는지 판단할 수 있습니다.

• 클라이언트를 끈 상태에서 자주 사용하는 사이트에 정상적으로 접속되는지 확인하세요.
• 클라이언트를 켠 뒤 대상 웹사이트에 연결되고 리소스가 모두 로드되는지 확인하세요.
• 같은 지역의 다른 회선으로 전환해 특정 노드의 문제인지 비교하세요.
• 규칙 모드와 전역 모드를 각각 테스트해 분할 설정이 장애에 관여하는지 판단하세요.
• 브라우저를 종료했다가 다시 열어 기존 연결과 DNS 캐시의 영향을 배제하세요.
• Mac을 한 번 잠자기 상태로 전환했다가 깨워 네트워크 확장이 세션을 다시 설정할 수 있는지 확인하세요.

웹페이지의 첫 화면은 열리지만 로그인, 이미지 또는 동영상 리소스가 실패한다면 해당 리소스가 다른 도메인에서 제공되는지 확인하세요. 기본 도메인은 프록시 규칙에 맞았지만 정적 리소스 도메인은 잘못 직접 연결되었을 수 있습니다. 이때 도메인 규칙을 보완하거나 규칙 세트를 업데이트하세요. 첫 화면이 열린다는 이유만으로 구성이 완전하다고 판단해서는 안 됩니다.

노드를 바꾼 뒤에도 대상 웹사이트에 이전 지역 결과가 계속 표시된다면 브라우저 세션, 사이트 캐시, 계정 지역 설정 또는 기존 연결이 아직 유지되고 있을 수 있습니다. 먼저 새 개인정보 보호 창에서 비교한 뒤 사이트 데이터를 삭제할지 결정하세요. 지역 콘텐츠는 출구 주소만으로 결정되지 않으므로 출구가 바뀌었다고 해서 대상 서비스의 계정 설정이 즉시 변경된다고 보장할 수는 없습니다.

일반적인 문제: 데이터 경로를 따라 단계별로 해결하기

클라이언트가 열리지 않거나 시스템에서 차단됨

먼저 앱 출처, 기기 아키텍처와 시스템 호환 요구 사항을 확인하세요. 앱 파일이 손상되었다면 원래 배포 경로에서 다시 다운로드합니다. 시스템에서 개발자 또는 서명 문제를 표시한다면 출처를 확인한 뒤 시스템이 제공하는 보안 설정에 따라 처리하세요. 출처를 확인할 수 없는 설치 파일을 우회하기 위해 시스템 검사를 영구적으로 끄지 마세요.

구독 가져오기는 성공했지만 노드 목록이 비어 있음

먼저 수동 업데이트를 실행하고 오류 메시지를 확인하세요. 인증 실패라면 서비스 패널에서 구독 주소를 다시 발급받아야 할 수 있습니다. 파싱 실패는 오래된 클라이언트 버전, 호환되지 않는 구독 형식 또는 불완전한 링크 복사 때문에 발생할 수 있습니다. 브라우저에서 링크를 열었을 때 로그인 페이지가 표시된다면 현재 복사한 것이 구독 주소인지 패널 페이지 주소인지도 확인하세요.

연결을 눌러도 계속 시작 중으로 표시됨

시스템 프록시 모드에서는 로컬 수신 포트를 다른 프로그램이 사용하고 있지 않은지 확인하세요. 가상 네트워크 인터페이스 모드에서는 네트워크 확장 권한과 기존 VPN 구성을 확인합니다. 그런 다음 구독에 포함된 다른 프로토콜 회선으로 바꿔 보세요. UDP에 의존하는 프로토콜만 실패한다면 현재 네트워크가 UDP를 제한하는지 고려하고 다른 프로토콜과 비교 테스트하세요.

연결 후 모든 웹사이트에 접속할 수 없음

먼저 클라이언트를 끄고 기본 네트워크가 복구되는지 확인한 다음 남아 있는 시스템 프록시를 점검하세요. 다시 연결한 뒤 전역 모드로 테스트합니다. 전역 모드도 실패하면 노드, 프로토콜, 시스템 시간과 네트워크 확장을 중점적으로 확인하고, 전역 모드는 되지만 규칙 모드가 실패하면 규칙과 DNS를 확인하세요. 클라이언트 재설치, 구독 교체와 DNS 변경을 동시에 진행하면 원인을 비교할 조건이 사라집니다.

일부 앱이 프록시를 거치지 않음

해당 앱이 시스템 프록시를 따르는지 확인하세요. 따르지 않는다면 가상 네트워크 인터페이스 모드를 테스트하거나 앱 자체에서 지원하는 프록시 설정을 사용합니다. 기업 관리 기기에는 조직이 배포한 네트워크 필터 또는 VPN 정책이 있을 수 있으며, 이런 설정은 일반 사용자가 덮어쓸 수 없는 경우가 많으므로 허용되는 네트워크 방식을 기기 관리 담당자에게 확인해야 합니다.

잠자기 후 복귀하면 연결이 복구되지 않음

먼저 클라이언트에서 연결을 끊었다가 다시 연결하고, 바로 강제 종료하지 마세요. 문제가 반복되면 여러 네트워크 확장이 동시에 활성화되어 있는지 확인하고 클라이언트 공식 사이트에서 제공하는 안정 버전으로 업데이트하세요. 무선 LAN에서 다른 접속 방식으로 전환하면 기존 세션과 라우팅이 무효화될 수 있으므로 클라이언트가 연결을 다시 만들어야 합니다.

최종 점검: 유지 관리하기 쉬운 구성으로 정리하기

설치가 끝난 뒤에는 많은 규칙을 쌓는 것보다 단순하고 재현 가능한 구성 하나를 유지하는 것이 중요합니다. 클라이언트는 구독을 받고 정책을 실행하며, 구독은 노드 매개변수를 배포하고, 로컬 규칙은 개인 기기의 예외를 처리합니다. 이 세 부분을 분리하면 업데이트할 때 서로 덮어쓸 가능성이 줄어듭니다. 문제가 발생해도 클라이언트, 서비스 설정 또는 로컬 네트워크 중 어디를 확인해야 하는지 명확해집니다.

일상적으로는 구독을 정기적으로 수동 업데이트하고 결과를 확인할 수 있지만 구성을 자주 삭제할 필요는 없습니다. 클라이언트 업그레이드 후 문제가 생기면 먼저 네트워크 확장 권한이 유지되는지 확인한 다음 구성 마이그레이션과 프로토콜 코어가 변경되었는지 살펴보세요. 공용 네트워크로 전환할 때는 자주 사용하는 웹사이트로 기본 네트워크를 먼저 확인한 뒤 클라이언트를 켜면 접속 네트워크 문제와 프록시 구성 문제를 더 빠르게 구분할 수 있습니다.