Mac VPN을 처음 설정할 때 실제로 막히기 쉬운 부분은 노선 자체보다 클라이언트 버전, macOS 네트워크 확장 권한, 구독 가져오기 방식, 시스템 프록시 모드가 서로 맞지 않는 경우입니다. 먼저 설치 파일의 출처와 칩 아키텍처를 확인하고 시스템 권한을 허용한 뒤 구독을 가져오고 노선을 선택한 다음, 출구 주소·DNS·분할 라우팅 결과를 확인하는 순서가 올바릅니다.
macOS는 네트워크 구성을 변경하는 소프트웨어에 명확한 권한 경계를 적용합니다. 클라이언트는 VPN 구성 추가, 네트워크 확장 활성화 또는 트래픽을 넘겨받는 백그라운드 구성 요소 설치를 요청할 수 있습니다. 시스템 팝업이 표시되었다고 설치에 실패한 것은 아닙니다. 오히려 팝업을 무시하거나 반복 설치하거나 같은 종류의 클라이언트를 동시에 실행할 때 연결 버튼 무반응, 시스템 프록시 잔류와 네트워크 중단이 발생하기 쉽습니다.
설치 전에 클라이언트 유형부터 확인하기
구독 서비스가 특정 클라이언트 하나를 뜻하는 것은 아닙니다. 구독 링크에는 서버, 포트, 프로토콜과 전송 매개변수 등의 구성이 저장되고, 클라이언트가 이를 해석해 연결을 만듭니다. 클라이언트를 잘못 선택하면 링크가 유효해도 “구독을 인식할 수 없음”, “노선 목록이 비어 있음” 또는 일부 프로토콜 연결 불가 문제가 발생할 수 있습니다.
| 클라이언트 유형 | 적합한 상황 | 주요 기능 | 설치 전에 확인할 사항 |
|---|---|---|---|
| 규칙 기반 클라이언트 | 웹사이트, 앱 대상 또는 도메인별로 트래픽을 분할 라우팅해야 하는 경우 | 규칙 모드, 전체 모드, 직접 연결 모드, 구독 업데이트 | 구독 형식이 해당 구성 코어와 호환되는지 |
| 단일 프로토콜 클라이언트 | 구성이 간단하고 특정 프로토콜만 사용하는 경우 | 서버 수동 추가, QR 코드 또는 링크 가져오기 | 구독에 해당 클라이언트가 지원하는 프로토콜이 포함되어 있는지 |
| 범용 코어 클라이언트 | 구독에 여러 최신 프로토콜이나 복잡한 라우팅이 포함된 경우 | 다중 프로토콜, DNS 규칙, 라우팅 규칙, 가상 네트워크 인터페이스 모드 | 그래픽 인터페이스와 하위 코어가 신뢰할 수 있는 배포 경로에서 제공되는지 |
Mac에서 사용하는 프로세서 아키텍처도 확인해야 합니다. 최신 기기는 대체로 Apple 칩을 사용하고, 구형 기기는 Intel 프로세서일 수 있습니다. 다운로드 페이지에서 설치 파일을 따로 제공한다면 “이 Mac에 관하여”에 표시된 칩 정보와 일치하는 버전을 선택하세요. 범용 설치 파일은 두 아키텍처를 모두 포함할 수 있지만 일반적으로 파일 크기가 더 큽니다.
일반적인 구독에는 Shadowsocks, VMess, Trojan, VLESS, Hysteria2 또는 TUIC가 포함될 수 있습니다. 이들은 단순한 “속도 등급”이 아닙니다. Shadowsocks는 구성이 비교적 간단하고, VMess는 오래된 프록시 프로토콜 생태계에 속합니다. VLESS는 보통 전송 계층과 보안 계층 매개변수와 함께 사용하며, Trojan은 TLS 연결과 함께 구성되는 경우가 많습니다. Hysteria2와 TUIC는 QUIC 및 UDP 기반이므로 네트워크 환경에서 UDP 전송이 안정적으로 허용되지 않으면 TCP 기반 노선보다 성능이 떨어질 수 있습니다.
- ✅ 서비스 관리 화면 또는 클라이언트 프로젝트의 공식 배포 경로에서 설치 파일을 다운로드하세요.
- ✅ “이 Mac에 관하여”에서 칩 유형을 확인한 뒤 해당 아키텍처를 선택하세요.
- ✅ 설치 전에 다른 프록시 또는 VPN 클라이언트를 종료해 시스템 네트워크 설정을 동시에 변경하지 않도록 하세요.
- ✅ 현재 사용할 수 있는 구독 링크를 보관하되 다른 사람에게 전달하지 마세요.
- ❌ 일반적인 설치 안내를 통과하려고 시스템 무결성 보호를 끄지 마세요.
- ❌ 여러 시스템 프록시, 가상 네트워크 인터페이스 또는 네트워크 필터링 도구를 동시에 활성화하지 마세요.
macOS 설치와 시스템 권한 허용 완료하기
일반적인 설치 방식에는 디스크 이미지, 앱 설치 파일과 앱 스토어 버전이 있습니다. 디스크 이미지는 보통 앱을 “응용 프로그램” 폴더로 드래그해야 하고, 설치 파일은 마법사를 통해 앱과 필요한 구성 요소를 기록합니다. 앱 스토어 버전은 시스템이 서명 확인과 업데이트를 담당합니다. 어떤 방식을 사용하든 처음 실행할 때 macOS의 보안 확인이 표시될 수 있습니다.
앱이 열리지 않을 때는 먼저 안내 메시지 유형을 확인하세요
시스템에서 앱이 인터넷에서 다운로드되었다고 안내하면 출처를 신뢰할 수 있는지 확인한 후 열어도 됩니다. 개발자를 확인할 수 없다는 메시지가 표시되면 반복해서 클릭하지 말고 공식 다운로드 페이지로 돌아가 설치 파일을 확인하세요. 시스템 설정의 “개인정보 보호 및 보안”에는 방금 차단된 앱과 열기 허용 옵션이 표시될 수 있으며, 이 작업은 방금 직접 실행한 앱 이름과 일치해야 합니다.
앱이 바로 종료되면 먼저 아키텍처가 맞는지 확인하고 시스템 버전이 클라이언트 요구 사항을 충족하는지 점검하세요. 디스크 이미지 창에서 앱을 바로 실행하면 업데이트나 보조 구성 요소 기록에 실패할 수 있으므로 먼저 “응용 프로그램” 폴더로 복사한 다음 런치패드나 Finder에서 열어야 합니다.
VPN 구성 추가 허용하기
시스템 VPN 프레임워크나 네트워크 확장을 사용하는 클라이언트는 처음 연결할 때 VPN 구성 추가를 요청하는 경우가 많습니다. macOS에는 어떤 앱이 요청했는지도 표시됩니다. 허용해야 시스템이 해당 네트워크 인터페이스나 터널을 만들 수 있습니다. 거부하면 클라이언트 화면은 열리더라도 연결이 즉시 끊기거나 시작 중 상태에 계속 머물 수 있습니다.
일부 클라이언트는 완전한 터널 대신 시스템 프록시를 사용합니다. 이 경우 Wi-Fi 또는 유선 네트워크 서비스의 프록시 설정을 변경하며 시스템 VPN 목록에는 표시되지 않을 수 있습니다. 다른 클라이언트는 가상 네트워크 인터페이스 모드를 제공해 일반적인 utun 인터페이스를 만들고 시스템 프록시 설정을 따르지 않는 앱의 트래픽까지 넘겨받습니다. 두 방식 모두 타당하지만 적용 범위는 다릅니다.
네트워크 확장이 차단되었을 때 처리 방법
먼저 시스템 설정의 “개인정보 보호 및 보안”을 열어 현재 클라이언트와 연결된 확장 허용 항목이 있는지 확인하세요. 네트워크 설정의 VPN, 필터 또는 관련 확장도 확인할 수 있습니다. 허용을 완료한 후 클라이언트를 종료하고 다시 실행하세요. 시스템에서 Mac을 재시동하라고 명확히 요구할 때만 재시동하면 되며, 매번 다시 설치할 필요는 없습니다.
- 실행 중인 다른 네트워크 프록시 클라이언트를 종료하세요.
- 새 클라이언트를 “응용 프로그램” 폴더에 설치하고 처음 실행하세요.
- macOS 팝업에 표시된 앱 이름을 확인한 뒤 VPN 구성 또는 네트워크 확장 추가를 허용하세요.
- 클라이언트로 돌아가 권한 대기 상태에 더 이상 머물지 않는지 확인하세요.
- 아직 구독을 가져오기 전에는 전체 트래픽 제어를 임의로 활성화하지 마세요.
구독 링크 가져오기와 업데이트 방식 이해하기
구독 링크는 보통 서비스 관리 화면에서 생성됩니다. 일반적인 제품 홈페이지 링크가 아니라 클라이언트가 읽을 수 있는 구성 진입점입니다. 링크를 가진 사람은 누구나 그 안의 노선 구성을 확인할 수 있으므로 비밀번호처럼 보관해야 합니다. 전체 링크를 공개 속도 측정 페이지, 포럼 게시물 또는 스크린샷에 붙여 넣지 마세요.
클라이언트마다 메뉴 이름은 “구독 추가”, “URL에서 가져오기”, “원격 구성” 또는 “구성 제공자” 등으로 표시될 수 있습니다. 붙여 넣은 후 구독에 알아보기 쉬운 이름을 지정하고 업데이트를 실행하세요. 성공하면 노선 목록이나 정책 그룹이 표시되어야 하며, 펼칠 수 없는 텍스트 기록 하나만 보여서는 안 됩니다.
구독 관리 화면 → 구독 링크 복사
클라이언트 → 원격 구독 추가
링크 붙여넣기 → 저장
구독 업데이트 → 노선 선택
규칙 모드 활성화 → 연결 설정가져오기에 실패하면 먼저 복사한 내용의 앞뒤에 공백이나 줄바꿈이 없는지 확인한 다음, 클라이언트가 서비스에서 제공하는 구독 형식을 지원하는지 확인하세요. 브라우저에서 링크가 열린다고 해서 클라이언트가 반드시 해석할 수 있는 것은 아닙니다. 브라우저에 인코딩된 텍스트가 표시되어도 링크가 손상된 것은 아닙니다. 실제로 확인해야 할 것은 클라이언트 업데이트 로그의 HTTP 상태, 형식 해석 및 프로토콜 지원 안내입니다.
구독 업데이트와 노선 연결은 서로 독립된 작업입니다. 구독 업데이트는 최신 구성을 가져오고, 노선 연결은 그중 하나의 노드를 사용해 세션을 설정합니다. 이미 가져온 이전 구성은 계속 연결될 수 있지만 노선 변경 사항은 반영되지 않습니다. 반대로 구독 업데이트에 성공했다고 해서 선택한 노선이 현재 네트워크에 반드시 적합한 것은 아닙니다.
수동 구성과 구독 가져오기의 차이는 무엇인가요
수동 구성은 단일 노선을 점검할 때 적합하며 서버 주소, 포트, 인증 정보, 전송 방식과 보안 매개변수를 직접 입력해야 합니다. 구독 가져오기는 일상적인 사용에 적합하고 노선이 변경될 때 한 번에 업데이트할 수 있습니다. 문제를 해결할 때는 단일 구성으로 프로토콜 작동 여부를 확인할 수 있지만, 여러 구성을 장기간 복사해 두는 것은 권장하지 않습니다. 이후 매개변수 변경을 놓치기 쉽기 때문입니다.
업데이트 후 노선 이름이 바뀐 이유는 무엇인가요
서비스에서 지역 표시, 진입 방식 또는 노선 그룹을 조정했을 수 있습니다. 클라이언트가 원격 구독을 업데이트하면 해당 구독의 기존 내용을 새 구성으로 덮어씁니다. 원격 노드 매개변수를 직접 수정했다면 다음 업데이트에서 변경 사항이 사라질 수 있습니다. 오래 유지해야 하는 사용자 지정 분할 라우팅은 원격 노드를 직접 수정하지 말고 클라이언트가 지원하는 로컬 재정의 또는 규칙 영역에 추가하세요.
노선, 프록시 모드와 분할 라우팅 규칙 선택하기
연결하기 전에 직접 연결, 중계 및 IEPL 전용 회선을 구분해야 합니다. 직접 연결은 로컬 네트워크에서 원격 서버에 바로 접속하므로 경로가 단순하지만 네트워크 간 경로와 국제 출구 변화가 품질에 직접 영향을 줍니다. 중계 노선은 먼저 중국 본토 또는 인접 지역의 진입점에 연결한 뒤 중계 네트워크를 통해 출구로 전달하므로 라우팅 최적화에 유리한 경우가 많습니다. IEPL 전용 회선은 진입점과 출구 사이에서 전용 국제 이더넷 회선 자원을 사용하는 방식으로, 일반 공용 인터넷 중계와는 다른 개념입니다. 다만 로컬 네트워크에서 진입점까지, 출구에서 대상 서비스까지의 네트워크 경로는 여전히 존재합니다.
노선 유형이 실제 사용 환경에 맞는 선택을 대신할 수는 없습니다. 업무용 소프트웨어, 웹 브라우징, 파일 동기화와 실시간 회의는 네트워크 요구 사항이 서로 다릅니다. 웹페이지는 짧은 순간의 흔들림을 어느 정도 견디지만 실시간 음성 및 회의는 지속적인 안정성을 더 중시하고, 파일 전송은 대역폭과 장시간 연결에 더 크게 의존합니다. 먼저 대상 지역에 맞는 노선을 선택하고 현재 네트워크에서 연결 안정성을 관찰하세요. 노선 이름만 보고 판단하지 마세요.
| 모드 | 트래픽 처리 방식 | 적합한 용도 | 일반적인 문제 |
|---|---|---|---|
| 규칙 모드 | 도메인, 주소 범위 또는 규칙 그룹에 따라 프록시와 직접 연결을 결정 | 일상적인 사용, 국경 간 업무, 국내외 서비스 병행 | 규칙이 오래되면 새 도메인을 잘못 판단할 수 있음 |
| 전체 모드 | 클라이언트가 넘겨받을 수 있는 트래픽이 선택한 노선을 일괄적으로 통과 | 규칙 때문에 접속이 실패하는지 임시로 확인 | 로컬 서비스가 우회 경로를 사용하거나 로컬 네트워크 접속에 영향을 줄 수 있음 |
| 직접 연결 모드 | 원격 노선을 통한 전달을 중지 | 로컬 네트워크를 비교 테스트하고 종료 전에 연결 상태를 복원 | 국제 노선이 적용되었는지 확인하는 데 사용할 수 없음 |
초보자는 먼저 규칙 모드를 사용하는 것이 좋습니다. 일반적으로 자주 사용하는 로컬 서비스는 직접 연결하고, 국제 노선이 필요한 대상은 규칙에 따라 전달합니다. 특정 웹사이트가 열리지 않으면 잠시 전체 모드로 전환해 비교하세요. 전체 모드에서는 작동하지만 규칙 모드에서 작동하지 않는다면 대부분 분할 라우팅 규칙 문제입니다. 두 모드 모두 작동하지 않으면 노선, 프로토콜, DNS 또는 로컬 네트워크를 확인해야 합니다.
시스템 프록시 모드는 주로 macOS 프록시 설정을 따르는 앱에 적용됩니다. 일부 명령줄 도구, 게임, 가상 머신 또는 자체 네트워크 스택을 구현한 소프트웨어는 시스템 프록시를 우회할 수 있습니다. 가상 네트워크 인터페이스 모드는 더 넓은 IP 트래픽을 넘겨받을 수 있지만 기업 보안 소프트웨어, 컨테이너 네트워크 및 다른 VPN과 충돌하기도 쉽습니다. 활성화 여부는 구체적인 앱 요구 사항에 따라 결정하세요.
연결 후 출구, DNS와 실제 트래픽 경로 확인하기
클라이언트에 “연결됨”이라고 표시되는 것은 터널이나 프록시 프로세스가 시작되었다는 뜻일 뿐, 모든 트래픽이 예상대로 전달된다는 의미는 아닙니다. 완전한 검증에는 최소한 출구 주소, 대상 웹사이트 접속, DNS 확인과 분할 라우팅 결과가 포함되어야 합니다. 테스트할 때는 연결 로그와 트래픽 카운터의 변화를 관찰할 수 있도록 클라이언트 화면을 열어 두세요.
- 대상 노선에 연결하고 클라이언트가 계속 재연결하거나 인증 오류를 내지 않는지 확인하세요.
- IP 조회 페이지를 열어 출구 지역이 선택한 노선과 일치하는지 확인하세요.
- 직접 연결되어야 하는 서비스와 국제 노선을 거쳐야 하는 서비스를 각각 방문하세요.
- DNS 테스트를 실행해 조회 요청이 예상한 리졸버로 전달되는지 확인하세요.
- 직접 연결 모드로 전환해 다시 비교하고 결과가 실제 노선 변경으로 인한 것인지 확인하세요.
DNS 누출은 앱 트래픽이 프록시나 터널을 통과하지만 도메인 조회는 예상과 다른 로컬 경로에서 처리되는 현상입니다. 접속 도메인의 조회 요청이 노출되거나 지역 판정이 일치하지 않을 수 있습니다. 해결 방법은 무작정 노드를 바꾸는 것이 아니라 클라이언트의 DNS 모드, 시스템 DNS, 브라우저의 암호화 DNS 설정과 분할 라우팅 규칙이 서로 충돌하는지 확인하는 것입니다.
macOS에서는 터미널을 통해 시스템이 현재 인식하는 DNS 구성과 기본 경로를 확인할 수 있습니다. 명령 출력에 여러 리졸버가 포함되는 경우가 많은데, 이는 Wi-Fi, 가상 인터페이스, 네트워크 확장 및 도메인별 조회 규칙이 동시에 존재할 수 있기 때문입니다. 항목이 여러 개 보인다는 이유만으로 누출이라고 판단하지 말고 연결 전후의 변화와 실제 DNS 테스트 결과를 함께 확인하세요.
scutil --dns
route -n get default시스템 프록시를 사용하는 클라이언트는 기본 경로를 반드시 변경하지 않으므로 기본 게이트웨이가 로컬 라우터로 유지되는 것은 정상일 수 있습니다. 가상 네트워크 인터페이스 모드에서는 utun 인터페이스와 관련 경로가 추가될 수 있습니다. 명령 결과는 반드시 클라이언트 작동 모드와 함께 해석해야 하며, “기본 경로가 바뀌지 않았다”는 사실만으로 연결 실패라고 판단해서는 안 됩니다.
- ✅ 출구 지역이 현재 선택한 노선과 일치합니다.
- ✅ 규칙 모드에서 로컬 서비스와 국제 서비스 모두 예상대로 접속됩니다.
- ✅ DNS 테스트 결과가 클라이언트의 DNS 정책과 일치합니다.
- ✅ 클라이언트 연결을 끊은 후 시스템 네트워크가 정상적으로 복구됩니다.
- ❌ 메뉴 막대 아이콘이나 연결 시간만 보고 적용 여부를 판단하지 마세요.
- ❌ 여러 클라이언트에서 시스템 프록시와 가상 네트워크 인터페이스를 동시에 활성화하지 마세요.
일반적인 문제의 점검 순서
연결을 클릭하자마자 끊어지는 경우
먼저 클라이언트 로그에 인증 실패, 프로토콜 미지원, 인증서 검증, 네트워크 연결 불가 또는 권한 부족이 나타나는지 확인하세요. 인증 실패는 보통 구독 업데이트가 필요하고, 프로토콜 미지원은 호환되는 클라이언트로 바꿔야 합니다. 인증서 및 서버 이름 관련 오류는 검증을 꺼서 장기간 우회해서는 안 됩니다. 권한 부족이라면 시스템 설정으로 돌아가 네트워크 확장을 확인하세요.
모든 노선에서 시간 초과가 발생하는 경우
먼저 현재 네트워크 연결을 끊었다가 다시 활성화한 뒤 다른 프로토콜의 노선을 시도하세요. QUIC 기반 Hysteria2 또는 TUIC는 모두 실패하지만 TCP 기반 노선은 작동한다면 현재 네트워크가 UDP를 제한하거나 방해하고 있을 수 있습니다. 호텔, 학교 및 기업 네트워크에서는 브라우저에서 포털 인증을 먼저 완료해야 할 수도 있으며, 인증 전에는 클라이언트가 외부 연결을 설정하기 어렵습니다.
모든 프로토콜이 실패한다면 직접 연결 모드로 전환해 일반 웹페이지에 접속할 수 있는지 확인하세요. 직접 연결도 작동하지 않는다면 구독을 반복해서 업데이트하기보다 먼저 로컬 네트워크를 해결해야 합니다. 직접 연결은 정상인데 모든 노선이 실패한다면 시스템 시간, 클라이언트 코어, 구독 유효성 및 보안 소프트웨어 충돌을 확인하세요.
브라우저는 되지만 다른 앱이 연결되지 않는 경우
대개 트래픽을 넘겨받는 범위와 관련된 문제입니다. 브라우저는 시스템 프록시를 따르지만 대상 앱은 프록시를 우회할 수 있습니다. 먼저 클라이언트가 가상 네트워크 인터페이스 모드를 제공하는지, 또는 앱·프로세스·대상 주소별 라우팅을 지원하는지 확인하세요. 가상 네트워크 인터페이스를 활성화하기 전에는 다른 VPN을 종료해 라우팅 테이블과 네트워크 확장이 서로 덮어쓰지 않도록 하세요.
연결을 끊은 뒤에도 인터넷에 접속할 수 없는 경우
클라이언트가 비정상 종료되면 시스템 프록시 설정이 남을 수 있습니다. 같은 클라이언트를 다시 열어 정상적으로 연결을 끊는 편이 앱을 바로 삭제하는 것보다 효과적인 경우가 많습니다. 그래도 복구되지 않으면 macOS 네트워크 설정에서 현재 네트워크 서비스의 프록시 항목이 계속 활성화되어 있는지 확인하세요. 조직 관리 정책에 문제가 없는지 확인한 후 잔류 프록시를 해제하고 Wi-Fi에 다시 연결하세요.
구독 업데이트 후 노드가 사라지는 경우
먼저 잘못된 구독 그룹을 선택한 것은 아닌지 확인한 다음 업데이트 로그를 확인하세요. 원격 응답이 비어 있거나 형식 변환에 실패했거나 클라이언트 코어가 지원하지 않는 경우 노선 목록이 일시적으로 비어 있을 수 있습니다. 기존 구성을 즉시 삭제하지 마세요. 먼저 로컬 설정을 내보내거나 사용자 지정 규칙을 기록한 후 구독을 다시 가져오세요. 링크가 변경되었다면 서비스 관리 화면에서 새 링크를 복사해야 합니다.
일상적인 사용과 구독 보안
구성을 완료한 후 클라이언트를 자주 다시 설치할 필요는 없습니다. 일상적인 관리는 클라이언트에서 구독을 업데이트하고, 네트워크가 바뀌면 적합한 노선을 다시 선택하며, 시스템 업데이트 후 네트워크 확장이 계속 허용되어 있는지 확인하는 정도입니다. 클라이언트 코어를 업데이트할 때는 사용자 지정 로컬 재정의 규칙을 먼저 저장해 분할 라우팅 설정이 덮어써지지 않도록 하세요.
구독 링크에는 접속 구성이 포함되어 있으므로 공개적으로 공유해서는 안 됩니다. 다른 Mac에서 사용해야 한다면 자신의 사용자 패널에서 다시 복사하고 신뢰할 수 있는 방식으로 전달하세요. 링크가 유출되었다고 의심되면 로컬 클라이언트만 삭제하지 말고 서비스 관리 화면에서 구독을 업데이트하거나 재설정하세요. 앱을 삭제해도 이미 노출된 원격 링크가 무효화되지는 않습니다.
공용 Wi-Fi에서는 먼저 접속 지점 이름을 확인하고 네트워크 포털 인증을 완료한 뒤 클라이언트를 실행하세요. 연결 후에도 브라우저에 표시되는 HTTPS 인증서 오류를 주의해야 합니다. VPN은 트래픽 경로를 바꿀 뿐 잘못된 인증서를 자동으로 신뢰할 수 있게 만들지는 않습니다. 인증서 경고가 나타나면 계정 정보나 업무 자료를 계속 제출하지 마세요.
장기간 사용할 규칙은 업무 서비스, 코드 저장소, 클라우드 콘솔과 로컬 리소스를 그룹별로 정리할 수 있습니다. 로컬 네트워크 프린터, 파일 공유와 기기 검색은 보통 직접 연결이 필요하고, 국제 협업 도구는 도메인 또는 주소 규칙에 따라 노선을 선택할 수 있습니다. 규칙이 복잡할수록 수정 후 비교 테스트를 진행해 로컬 리소스가 잘못된 원격 노선으로 전달되지 않도록 해야 합니다.
- ✅ 클라이언트를 반복 설치하지 말고 정기적으로 클라이언트에서 구독을 업데이트하세요.
- ✅ 시스템 업데이트 후 VPN 구성, 네트워크 확장과 필터 상태를 확인하세요.
- ✅ 사용자 지정 규칙을 수정한 후 직접 연결 대상과 프록시 대상에 각각 접속해 테스트하세요.
- ✅ 구독 유출이 의심되면 사용자 패널에서 구독 정보를 업데이트하세요.
- ❌ 공개 문서, 스크린샷 또는 문의 내용에 구독 링크를 넣지 마세요.
- ❌ 브라우저에 표시되는 HTTPS 인증서 오류를 무시하지 마세요.
위 과정을 완료하면 Mac VPN의 상태를 설명할 수 있어야 합니다. 클라이언트가 어떤 방식으로 트래픽을 넘겨받는지, 시스템에서 어떤 권한을 허용했는지, 구독이 어떻게 업데이트되는지 알고 출구 주소·DNS·분할 라우팅 테스트로 결과를 확인할 수 있어야 합니다. 문제가 생기면 네트워크, 권한, 구독, 프로토콜, 노선, DNS 순서로 점검하는 편이 반복해서 재설치하는 것보다 빠르고 시스템에 프록시 잔여 설정을 남길 가능성도 적습니다.