macOS에서 네트워크 클라이언트를 처음부터 설정할 때 중요한 것은 애플리케이션을 “응용 프로그램” 폴더로 옮기는 것만이 아닙니다. 설치 경로, 프로세서 아키텍처, 시스템 확장, VPN 구성, 구독 가져오기, 프록시 모드와 DNS 경로가 최종 결과에 영향을 줄 수 있습니다. 메뉴 막대에 “연결됨”이라고 표시되어도 클라이언트가 특정 연결 작업을 완료했다는 뜻일 뿐, 브라우저·터미널·다른 애플리케이션의 트래픽이 모두 예상한 경로를 통과한다고 단정할 수는 없습니다.
안정적인 순서는 먼저 설치 파일과 기기가 호환되는지 확인하고, 권한 팝업이 허용하는 범위를 이해한 뒤 구독을 가져오고 적절한 트래픽 처리 모드를 선택한 다음, 출구 IP·DNS·분할 라우팅 결과를 각각 점검하는 것입니다. 문제가 생겨도 같은 경로를 역순으로 확인해야 하며, 클라이언트를 반복해서 재설치하거나 노드를 계속 바꾸는 방식은 피하는 것이 좋습니다.
클라이언트·아키텍처·출처 확인하기
macOS 클라이언트는 보통 디스크 이미지, 설치 패키지 또는 압축 파일 형태로 제공됩니다. 디스크 이미지는 대개 애플리케이션 아이콘을 “응용 프로그램” 폴더로 드래그해야 하고, 설치 패키지는 시스템 설치 절차를 거칩니다. 압축 파일은 먼저 압축을 푼 다음 애플리케이션을 이동해야 합니다. 어떤 형식이든 서비스 제공업체의 계정 패널, 프로젝트 공식 릴리스 페이지 또는 클라이언트 내장 업데이트 경로에서 파일을 받아야 합니다.
Mac은 Apple Silicon을 사용할 수도 있고 Intel 프로세서를 사용할 수도 있습니다. 릴리스 페이지에서 아키텍처별 파일을 제공한다면 기기에 맞는 빌드를 내려받으세요. Universal로 표시된 빌드는 일반적으로 해당 아키텍처를 모두 포함합니다. 아키텍처가 맞지 않으면 애플리케이션이 열리지 않거나 호환성 변환 계층에 의존해 실행될 수 있습니다. “이 Mac에 관하여”에서 칩 또는 프로세서 정보를 확인한 뒤 다운로드 페이지의 표시와 대조하세요.
| 확인 항목 | 확인해야 할 내용 | 호환되지 않을 때의 증상 |
|---|---|---|
| 파일 출처 | 서비스 제공업체 계정 패널, 클라이언트 공식 릴리스 페이지 또는 앱 내 업데이트 메뉴 | 시스템이 개발자를 확인하지 못하거나 애플리케이션 동작이 공식 설명과 다름 |
| 프로세서 아키텍처 | Apple Silicon, Intel 또는 Universal 표시 | 애플리케이션이 실행되지 않거나 예기치 않게 종료되거나 추가 호환 환경을 요구함 |
| 설치 형식 | 디스크 이미지, 설치 패키지 또는 압축 파일에 맞는 설치 방법 | 애플리케이션이 다운로드 폴더에서 계속 실행되어 업데이트와 권한 상태가 뒤섞이기 쉬움 |
| 시스템 호환성 | 릴리스 노트에 기재된 최소 시스템 요구 사항과 알려진 제한 사항 | 네트워크 확장을 불러오지 못하고 설정 메뉴 위치가 안내와 다름 |
macOS가 출처를 확인할 수 없는 애플리케이션을 명확히 차단한다면 시스템 보안 기능을 끄는 방식으로 우회하지 마세요. 먼저 다운로드 주소, 개발자 정보와 릴리스 노트를 확인하고, 파일 출처를 확인할 수 없다면 신뢰할 수 있는 경로에서 다시 내려받으세요. 시스템의 “열기” 확인은 알려진 개발자의 애플리케이션을 처음 실행할 때 나타나는 안내를 처리하는 용도이며, 모든 경고에 적용하는 만능 해결책이 아닙니다.
- ✅ 설치 파일을 공식 경로에서 확인할 수 있고 파일명이 릴리스 노트와 일치합니다.
- ✅ 아키텍처 표시가 기기의 칩 유형과 일치하거나 Universal 빌드임이 명확합니다.
- ✅ 애플리케이션을 “응용 프로그램” 폴더로 옮겼으며 디스크 이미지나 다운로드 폴더에서 계속 실행하지 않습니다.
- ❌ 한 번 표시된 경고를 넘기기 위해 Gatekeeper 또는 시스템 무결성 보호 기능 전체를 끄지 마세요.
- ❌ 출처가 불분명하고 이름이 비슷한 클라이언트 사본을 여러 개 동시에 보관하지 마세요.
시스템 확장과 네트워크 권한 팝업 이해하기
클라이언트가 처음으로 시스템 프록시, TUN 또는 VPN 트래픽 처리를 활성화할 때 macOS에서 관리자 승인을 요구할 수 있으며, “VPN 구성 추가”, “네트워크 확장 허용” 또는 필터 관련 안내가 표시될 수 있습니다. 팝업 이름은 시스템 버전과 클라이언트 구현에 따라 달라지지만 목적은 비슷합니다. 애플리케이션이 시스템에서 관리하는 네트워크 경로를 만들도록 허용하는 것입니다.
“VPN 구성 추가”는 애플리케이션이 모든 개인 파일을 읽는다는 뜻이 아닙니다. 클라이언트가 시스템이 승인한 네트워크 구성을 만들고 조건에 맞는 트래픽을 해당 네트워크 확장으로 보내도록 허용하는 기능입니다. 관리자 인증은 이 시스템 수준 변경을 승인하는 데 사용됩니다. 이후 “시스템 설정”의 네트워크, VPN 및 필터 관련 영역에서 상태를 확인하거나 클라이언트에서 구성을 직접 제거할 수 있습니다.
일부 클라이언트는 Network Extension 프레임워크로 TUN을 구현하고, 일부는 주로 시스템 프록시를 수정하며, 두 방식 사이를 전환할 수 있는 클라이언트도 있습니다. 시스템에서 확장이 차단되었다는 안내가 나타나면 먼저 클라이언트를 켜 둔 상태로 “개인정보 보호 및 보안”에서 승인 대기 항목을 확인하세요. 승인한 뒤에는 보통 클라이언트로 돌아가 연결을 다시 활성화해야 하며, 애플리케이션에서 재시동을 명시적으로 요구할 때만 안내에 따르세요.
시스템 프록시와 TUN의 차이
시스템 프록시는 macOS의 HTTP, HTTPS 또는 SOCKS 프록시 설정을 기록합니다. 시스템 프록시를 따르는 브라우저와 애플리케이션은 요청을 클라이언트에 전달하지만, 자체 네트워크 스택을 사용하거나 시스템 프록시를 무시하거나 특수한 전송 방식을 사용하는 앱은 이를 거칠 수 있습니다. 이 모드는 변경 범위가 작아 웹 접근과 기본 분할 라우팅을 먼저 확인하기에 적합합니다.
TUN 모드는 가상 네트워크 인터페이스를 만들고 클라이언트가 더 넓은 범위의 IP 트래픽을 받은 뒤 규칙에 따라 프록시, 직접 연결 또는 차단을 결정하도록 합니다. 터미널 도구, 개발 환경, 시스템 프록시를 읽지 않는 애플리케이션까지 처리해야 할 때 더 적합하지만, 다른 VPN·필터·보안 소프트웨어 또는 기업용 네트워크 확장과 충돌하기도 쉽습니다.
| 트래픽 처리 방식 | 주요 적용 범위 | 일반적인 제한 | 적합한 점검 상황 |
|---|---|---|---|
| 시스템 프록시 | macOS 프록시 설정을 읽는 애플리케이션 | 일부 터미널 프로그램과 독립 네트워크 스택은 따르지 않을 수 있음 | 먼저 브라우저와 기본 규칙이 정상인지 확인 |
| TUN | 가상 인터페이스로 들어가 규칙에 따라 처리되는 트래픽 | 다른 네트워크 확장이나 필터와 충돌할 수 있음 | 브라우저는 정상인데 다른 애플리케이션에서 작동하지 않음 |
| 수동 프록시 | 프록시 주소를 개별 입력하는 특정 애플리케이션 | 설정이 분산되어 애플리케이션마다 상태가 다름 | 특정 애플리케이션의 프록시 기능을 분리해 확인 |
구독 가져오기 및 프로토콜·회선 필드 확인
권한 설정을 마친 뒤 서비스 제공업체의 계정 패널에서 구독 링크를 복사하고, 클라이언트의 “구독”, “구성”, “원격 구성” 또는 “Profiles” 메뉴로 가져오세요. 클라이언트마다 버튼 이름은 다르지만 기본 동작은 원격 주소를 저장하고 구성을 내려받아 노드를 분석하는 것입니다. 클립보드 가져오기를 지원한다면 클립보드에 완전한 링크만 있는지, 앞뒤 공백·줄바꿈·메신저가 덧붙인 문장 부호가 없는지 먼저 확인하세요.
가져오기가 완료되면 먼저 한 번 업데이트하여 노드, 정책 그룹과 규칙이 표시되는지 확인하세요. 구독 이름만 있고 선택할 회선이 전혀 없다면 다운로드 실패, 형식 비호환 또는 원격 콘텐츠 분석 오류일 가능성이 큽니다. 이때는 같은 링크를 반복해서 붙여 넣기보다 클라이언트 로그에서 HTTP 상태, 분석 오류와 구성 필드 안내를 확인하세요.
- 계정 패널에서 현재 유효한 구독 주소를 복사하고 공개 페이지에서 열거나 전달하지 마세요.
- 클라이언트의 구독 또는 원격 구성 메뉴로 들어가 주소를 붙여 넣고 저장하세요.
- 구성을 수동으로 업데이트하고 노드, 정책 그룹과 분할 라우팅 규칙이 모두 로드될 때까지 기다리세요.
- 현재 작업에 맞는 정책 그룹을 선택한 다음 구체적인 출구 회선을 고르세요.
- 시스템 프록시 또는 TUN을 활성화하고 메뉴 막대 상태가 시스템 설정의 네트워크 구성과 일치하는지 확인하세요.
- 출구 IP, DNS와 애플리케이션별 연결을 확인한 뒤 자동 업데이트 또는 로그인 시 자동 실행을 켜세요.
Shadowsocks, VMess, Trojan, VLESS, Hysteria2 및 TUIC
이 이름들은 서로 다른 프록시 프로토콜 또는 전송 방식을 뜻하며 회선 품질 등급이 아닙니다. Shadowsocks는 암호화 프록시 방식으로 트래픽을 전달하며 구성에는 보통 서버, 포트, 암호화 방식과 인증 정보가 포함됩니다. VMess와 VLESS는 호환 코어에서 처리되는 경우가 많고 서로 다른 전송 방식 및 TLS 설정과 조합할 수 있습니다. Trojan은 일반적으로 TLS 형태로 프록시 연결을 전달합니다. Hysteria2와 TUIC는 QUIC 계열 전송을 바탕으로 설계되며 클라이언트 코어와 네트워크 환경에 따라 요구 사항이 다릅니다.
프로토콜 이름만 보고 구독의 포트, 전송 계층, 보안 매개변수 또는 서버 이름을 직접 수정해서는 안 됩니다. 사용 가능 여부는 클라이언트 코어가 모든 필드를 지원하는지와 서버 구성이 일치하는지에 달려 있습니다. 클라이언트가 구독 형식을 지원한다고 해서 구독에 포함된 모든 프로토콜을 지원하는 것은 아닙니다. 가져온 뒤 “알 수 없는 유형” 또는 필드 분석 오류가 나타나면 해당 프로토콜을 지원하는 클라이언트 빌드를 사용하거나 서비스 제공업체가 제공하는 호환 구독 형식을 이용하세요.
직접 연결·중계·IEPL 전용 회선
직접 연결은 클라이언트가 대상 노드 입구에 바로 연결하는 방식으로 경로가 단순하지만, 품질은 현지 통신사와 입구 사이의 네트워크 경로에 더 크게 좌우됩니다. 중계 회선은 먼저 중계 노드에 접속한 뒤 출구로 전달되므로 서비스 제공업체가 일부 경로를 조정할 수 있습니다. IEPL 전용 회선은 국제 연결을 위한 전용 접속 형태이며, 조정과 출구 처리는 여전히 서버 측에서 담당합니다.
macOS 클라이언트에서는 이러한 차이가 대개 노드 구성에 이미 반영되어 있습니다. 클라이언트는 지정된 입구에 연결할 뿐, TUN을 켠다고 일반 직접 연결 회선이 전용 회선으로 바뀌지는 않습니다. 회선을 선택할 때는 구독의 회선 표시, 대상 지역과 실제 작업을 기준으로 삼고, 프로토콜 이름만으로 직접 연결·중계·IEPL 여부를 추측하지 마세요.
글로벌·규칙·직접 연결 모드 선택
일반적인 클라이언트는 글로벌, 규칙 및 직접 연결 모드를 제공합니다. 글로벌 모드는 클라이언트가 처리하는 트래픽을 모두 프록시 정책으로 보내 규칙 매칭 문제를 짧게 확인할 때 유용합니다. 규칙 모드는 도메인, IP, 프로세스 또는 규칙 집합에 따라 프록시와 직접 연결을 결정하며 일상적으로 가장 많이 사용됩니다. 직접 연결 모드는 처리 대상 트래픽을 바로 접속하게 하므로 로컬 네트워크를 복구하거나 문제가 프록시 경로에서 발생했는지 확인할 때 사용합니다.
“글로벌”은 클라이언트가 이미 처리 대상으로 받은 트래픽을 다루는 방식을 뜻할 뿐, 기기의 모든 연결이 클라이언트로 들어간다는 의미는 아닙니다. 현재 시스템 프록시만 활성화했다면 시스템 프록시를 읽지 않는 애플리케이션은 여전히 다른 경로를 사용할 수 있습니다. 반대로 TUN이 트래픽을 처리하더라도 규칙 모드에서는 로컬 웹사이트, 근거리 네트워크 리소스 또는 지정 애플리케이션을 직접 연결할 수 있습니다.
분할 라우팅 규칙에서는 매칭 순서를 확인해야 합니다. 구체적인 도메인 규칙이 포괄적인 규칙보다 먼저 적용되어야 하며, 마지막 기본 규칙은 앞선 조건에 일치하지 않는 요청을 처리합니다. 같은 도메인이 여러 규칙 집합에 있으면 클라이언트는 일반적으로 구성 순서상 먼저 일치하는 결과를 사용합니다. 규칙을 수정한 뒤에는 구성을 다시 불러오고 애플리케이션의 기존 연결을 정리해 이전 경로가 계속 사용되지 않도록 하세요.
- ✅ 브라우저가 대상 서비스에 접속할 때 예상한 정책 그룹과 일치하고 로그에서 해당 규칙을 확인할 수 있습니다.
- ✅ 로컬 웹사이트와 근거리 네트워크 리소스가 규칙에 따라 직접 연결되며 불필요하게 원격으로 전송되지 않습니다.
- ✅ 현재 처리 모드에서 터미널 도구가 브라우저와 일치하거나 설명 가능한 결과를 보여 줍니다.
- ❌ “글로벌 모드”를 모든 프로세스가 반드시 처리된다는 뜻으로 이해하지 마세요.
- ❌ 여러 클라이언트가 시스템 프록시를 동시에 수정하거나 겹치는 TUN 인터페이스를 만들게 하지 마세요.
출구 IP·DNS 및 애플리케이션별 결과 확인
연결 확인은 네트워크 계층에서 애플리케이션 계층으로 진행하세요. 먼저 출구 IP가 선택한 지역으로 바뀌었는지 확인하고, 다음으로 DNS 요청을 누가 처리하는지 점검한 뒤 브라우저·터미널·실제로 사용할 애플리케이션을 각각 열어 보세요. 이렇게 하면 “터널이 생성되지 않음”, “일부 애플리케이션만 처리됨”, “DNS 경로가 일치하지 않음”, “대상 서비스 자체의 제한”을 구분할 수 있습니다.
출구 IP 확인
연결 전후에 신뢰할 수 있는 IP 확인 페이지에서 공용 출구를 각각 확인하세요. 결과가 선택한 노드 지역과 일치해야 하며 브라우저 캐시, 이전 탭과 기존 장시간 연결의 영향을 배제해야 합니다. 기존 페이지를 닫고 다시 열거나 새로운 개인정보 보호 브라우징 창에서 요청을 보내세요. 클라이언트 로그에는 연결 성공으로 표시되지만 출구가 바뀌지 않는다면 시스템 프록시 또는 TUN이 실제로 켜졌는지 먼저 확인하고, 브라우저에 별도 프록시나 보안 DNS 기능이 설정되어 있지 않은지도 점검하세요.
DNS 누수 및 확인 경로 점검
DNS 누수는 일반적으로 업무 트래픽은 프록시를 통과하지만 도메인 조회는 예상과 다른 로컬 확인 서버로 전송되어 확인 경로와 출구 경로가 분리되는 현상을 뜻합니다. 시스템 프록시 모드에서는 애플리케이션이 시스템 DNS를 계속 사용할 수 있습니다. TUN 모드에서는 클라이언트가 더 많은 DNS 트래픽을 처리할 수 있지만 실제 처리 여부는 구성, 규칙과 애플리케이션 자체의 암호화 DNS 설정에 달려 있습니다.
점검할 때 특정 확인 서버 이름만 보지 마세요. 요청이 클라이언트 DNS 규칙과 일치하는지, 확인 결과가 변조되지 않았는지, 프록시 도메인이 터널을 만들기 전에 올바르게 확인되는지도 확인해야 합니다. 브라우저 내장 보안 DNS, 기업 네트워크 구성과 다른 네트워크 필터가 결과를 바꿀 수 있습니다. 불일치가 발견되면 중복된 DNS 처리 기능을 먼저 끄고 클라이언트 문서에 따라 시스템 확인, 원격 확인 또는 규칙 기반 확인 방식을 선택하세요.
scutil --proxy
scutil --dns
scutil --nwi
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"scutil --proxy로 현재 시스템 프록시 상태를 확인할 수 있고, scutil --dns는 시스템 확인 서버 구성을 살펴보는 데 사용하며, scutil --nwi는 네트워크 인터페이스 정보를 확인하는 데 도움이 됩니다. 명령 결과는 현재 시스템 구성만 보여 줄 뿐 특정 애플리케이션이 반드시 해당 설정을 따른다는 것을 단독으로 증명하지는 않으므로 클라이언트 로그와 실제 요청 결과를 함께 확인해야 합니다.
애플리케이션별 확인
브라우저가 정상이라고 해서 터미널, 개발 도구와 데스크톱 애플리케이션도 모두 정상이라는 뜻은 아닙니다. 브라우저는 대체로 시스템 프록시를 따르지만 별도 프록시 확장을 사용할 수도 있습니다. 터미널의 명령줄 프로그램은 환경 변수를 읽는 경우도 있고 직접 연결하는 경우도 있습니다. QUIC, 자체 DNS 또는 장시간 연결을 사용하는 애플리케이션은 결과가 다를 수 있습니다. 대상 애플리케이션에서 연결을 새로 만들고, 클라이언트 연결 로그에 해당 도메인·대상 IP·정책이 나타나는지 확인하세요.
자주 발생하는 권한 오류와 점검 순서
권한 오류는 남아 있는 확장, 중복 클라이언트 또는 동기화되지 않은 시스템 상태에서 발생하는 경우가 많습니다. 가장 효과적인 방법은 한 번에 하나의 변수만 처리하는 것입니다. 먼저 다른 네트워크 클라이언트와 필터 도구를 종료하고, 현재 애플리케이션이 “응용 프로그램” 폴더에 있는지 확인한 다음 시스템 설정에 기존 VPN 구성이나 네트워크 확장이 남아 있는지 점검하세요. 여러 클라이언트를 동시에 실행한 상태에서 허용 버튼을 반복해서 누르면 어떤 애플리케이션의 팝업인지 판단하기 어렵습니다.
승인했는데도 계속 권한을 요구함
애플리케이션 사본의 위치가 바뀌었거나 이전 버전의 확장이 남아 있거나 클라이언트가 설치 완료에 필요한 관리자 인증을 받지 못했을 때 흔히 발생합니다. 먼저 애플리케이션을 완전히 종료하고 디스크 이미지에서 실행 중인 사본을 삭제한 뒤 “응용 프로그램” 폴더 안의 정식 사본만 남기세요. 그다음 시스템 설정에서 VPN 및 필터 상태를 확인하고, 이전 클라이언트에 속하며 더 이상 사용하지 않는 구성을 제거한 후 현재 클라이언트를 다시 여세요.
시스템 설정에는 확장이 허용된 것으로 표시되지만 클라이언트가 여전히 로드되지 않았다고 보고한다면 해당 기능을 한 번 끈 뒤 다시 켜서 애플리케이션이 상태를 재확인하게 하세요. 클라이언트 릴리스 노트에서 명확히 요구할 때만 시스템을 재시동하세요. 애플리케이션을 바로 삭제해도 네트워크 확장과 VPN 구성이 제거되지 않을 수 있으므로 클라이언트가 제공하는 제거 또는 구성 삭제 기능을 사용하세요.
연결은 성공했지만 웹페이지가 열리지 않음
먼저 직접 연결 모드로 전환해 로컬 네트워크 자체가 정상인지 확인하세요. 직접 연결도 실패한다면 노드를 계속 바꾸기보다 현재 Wi-Fi, 기업 네트워크 인증과 시스템 DNS를 점검해야 합니다. 직접 연결은 정상이고 프록시만 실패한다면 노드 핸드셰이크, 구독 유효성, 프로토콜 호환성과 DNS 로그를 확인하세요. 특정 도메인만 실패한다면 분할 라우팅 규칙과 확인 결과를 점검하고 전체 회선을 사용할 수 없다고 바로 결론 내리지 마세요.
브라우저는 되지만 터미널에서 작동하지 않음
브라우저는 시스템 프록시를 읽지만 터미널 프로그램은 읽지 않는다는 뜻일 가능성이 큽니다. 클라이언트가 지원하는 TUN 모드를 켜서 비교하거나 명령줄 도구 문서에 따라 프록시 환경을 설정해 보세요. TUN을 켠 뒤 터미널이 정상화된다면 문제는 원격 회선이 아니라 처리 범위에 있습니다. 그래도 작동하지 않으면 해당 도구가 독립 DNS, UDP 또는 특수 네트워크 인터페이스를 고정해 사용하는지 확인하세요.
잠자기에서 깨어난 뒤 연결이 끊김
Mac이 깨어난 뒤 네트워크 인터페이스를 바꾸거나 주소를 다시 받거나 이전 연결을 복원할 수 있습니다. 먼저 클라이언트의 연결을 끊었다가 다시 연결해 라우팅, DNS와 가상 인터페이스를 다시 불러오세요. 문제가 계속되면 클라이언트에 자동 연결 복구 옵션이 있는지 확인하고 다른 도구가 깨어난 뒤 시스템 프록시를 덮어쓰지 않는지도 점검하세요. 반복된다면 잠자기 전후 로그를 저장해 인터페이스와 DNS 상태 변화를 비교할 수 있습니다.
- ✅ 다른 VPN, 프록시 클라이언트와 네트워크 필터 도구를 종료하고 현재 클라이언트만 실행하세요.
- ✅ 시스템 설정에서 현재 VPN 구성과 네트워크 확장이 클라이언트 이름과 일치하는지 확인하세요.
- ✅ 구독을 업데이트하고 분석 로그를 확인한 뒤 프로토콜과 호환되는 클라이언트로 바꿀 필요가 있는지 판단하세요.
- ✅ 직접 연결, 시스템 프록시와 TUN을 각각 비교해 문제가 회선에 있는지 처리 범위에 있는지 확인하세요.
- ❌ 애플리케이션 재설치, 구성 삭제, 노드 변경과 DNS 수정을 동시에 진행하지 마세요. 문제를 추적할 단서가 사라집니다.
- ❌ 핸드셰이크 실패, DNS 실패와 규칙 오매칭을 모두 “클라이언트 고장”으로 묶지 마세요.
안정적으로 사용하기 전 마무리 점검
구성이 정상임을 확인한 뒤 로그인 시 자동 실행, 구독 자동 업데이트와 네트워크 변경 후 자동 재연결을 사용할지 결정하세요. 자동화 기능은 검증된 구성 위에서 설정해야 하며, 그렇지 않으면 시스템 시작 시 잘못된 규칙이나 유효하지 않은 확장이 반복해서 로드될 수 있습니다. 구독 업데이트로 노드 이름과 정책 내용이 바뀔 수도 있으므로 업데이트 후 기존 정책 그룹이 여전히 예상한 회선을 가리키는지 확인하세요.
필요한 장애 기록을 남겨 두면 이후 원인을 찾는 데 도움이 됩니다. 클라이언트 버전, macOS 버전, 트래픽 처리 모드, 선택한 정책, 오류 발생 시간과 개인정보를 가린 로그 일부를 기록하세요. 로그를 제출하기 전 구독 주소, 인증 필드, 서버 인증 정보와 개인 경로를 삭제해야 합니다. 문제를 설명할 때 “어떤 애플리케이션에서 어떤 모드로 어느 단계가 실패했는지”를 명확히 쓰면 “연결할 수 없음”이라고만 쓰는 것보다 정확한 판단을 받기 쉽습니다.
기기가 학교 또는 기업의 관리 대상이라면 구성 프로파일이 VPN, 프록시 또는 네트워크 확장을 제한할 수 있습니다. 이러한 제한은 일반 관리자 승인으로 해제되지 않는 경우가 많으므로 기기 관리자의 네트워크 정책을 따라야 합니다. 개인 기기에서는 사용하지 않는 클라이언트가 남긴 프록시 설정과 네트워크 확장을 정기적으로 정리해 여러 네트워크 구성 요소가 같은 경로를 두고 충돌하지 않도록 하세요.