macOS VPN 설정 가이드: 설치부터 구독 가져오기까지 초보자용 완벽 안내
Mac에서 처음 설정하는 사용자를 위해 클라이언트 설치, 시스템 확장 권한 승인, 구독 가져오기, 작동 확인까지 네 단계로 안내하고, 시스템 권한 팝업을 거부했을 때의 해결 방법 등 가장 흔한 문제도 설명합니다.
이 macOS VPN 설정 가이드는 첫 설정에서 가장 헷갈리기 쉬운 과정을 다룹니다. 설치 패키지 선택, VPN 구성 또는 네트워크 확장을 요구하는 이유, 구독 링크 가져오기, 연결 버튼이 활성화된 뒤 실제로 원하는 회선을 통해 트래픽이 흐르는지 확인하는 방법을 설명합니다. 전체 과정은 복잡하지 않지만 클라이언트 모드, 시스템 권한, 분할 규칙이 서로 영향을 주므로 확인 단계를 건너뛰면 “연결됨으로 표시되지만 실제로는 적용되지 않는” 문제가 생길 수 있습니다.
macOS용 프록시 클라이언트는 서로 완전히 같지 않습니다. 일부는 시스템 프록시를 주로 설정해 macOS 프록시 구성을 따르는 앱만 제어하고, 일부는 Apple의 네트워크 확장으로 가상 네트워크 인터페이스를 만들어 더 넓은 트래픽을 처리하며, 두 모드를 모두 제공하는 클라이언트도 있습니다. 설치 전에 클라이언트 출처, 프로세서 아키텍처, 구독 형식을 확인하면 이후 문제 해결이 훨씬 수월합니다.
설치 전 준비: 클라이언트, 아키텍처, 구독 유형 확인
설치를 시작하기 전에 서비스 패널이나 공식 안내에서 권장 클라이언트를 확인하세요. 구독 링크는 설정을 가져오는 입구일 뿐, 모든 클라이언트가 이를 해석할 수 있다는 뜻은 아닙니다. 하나의 구독에 Shadowsocks, VMess, Trojan, VLESS, Hysteria2 또는 TUIC 프로토콜 노드가 포함될 수 있지만, 클라이언트마다 지원하는 프로토콜과 전송 방식이 다릅니다. 클라이언트에서 구독 주소가 열리더라도 모든 노드를 인식할 수 있다는 의미는 아닙니다.
Mac의 프로세서 아키텍처도 맞춰야 합니다. 최신 기종은 대체로 Apple 칩을 사용하고, 이전 기종은 Intel 프로세서를 사용할 수 있습니다. 다운로드 페이지에서 각각의 빌드를 제공한다면 “이 Mac에 관하여”에 표시된 프로세서와 일치하는 버전을 선택하세요. 범용 빌드를 제공하는 경우에는 보통 그대로 설치할 수 있습니다. 아키텍처를 잘못 선택하면 앱이 실행되지 않거나 실행 직후 종료되거나, 현재 기기와 호환되지 않는다는 시스템 메시지가 표시될 수 있습니다.
- ✅ 서비스 패널, 클라이언트 프로젝트 공식 웹사이트 또는 출처가 명확히 표시된 배포 페이지에서 설치 패키지를 받으세요.
- ✅ Mac의 프로세서 유형을 확인하고 알맞은 빌드 또는 범용 빌드를 선택하세요.
- ✅ 클라이언트가 구독에서 실제 사용하는 프로토콜과 전송 방식을 지원하는지 확인하세요.
- ✅ 가져오기 전에 구독 링크를 별도로 안전하게 보관하고, 공개 문서나 공개 채팅에 붙여 넣지 마세요.
- ❌ 출처가 불분명한 설치 패키지를 처리하려고 시스템 보안 검사를 끄지 마세요.
- ❌ 시스템 프록시나 가상 네트워크 인터페이스를 변경하는 클라이언트를 여러 개 동시에 실행하지 마세요.
구독 링크에는 계정 설정을 식별하는 토큰이 포함되는 경우가 많으므로 민감한 자격 증명으로 취급해야 합니다. 링크를 받은 뒤 브라우저에서 반복해서 열 필요가 없으며, 공개적으로 스크린샷을 공유해서도 안 됩니다. 링크가 실수로 노출됐다면 로컬 검색 기록만 삭제하지 말고 서비스 패널에서 구독을 새로 생성하거나 재설정하세요.
클라이언트 설치: 정상적인 macOS 보안 알림 이해하기
일반적인 설치 패키지는 디스크 이미지 또는 압축 아카이브 형태입니다. 디스크 이미지를 열었다면 앱을 “응용 프로그램” 폴더로 드래그한 뒤 해당 폴더에서 실행하세요. 압축 아카이브라면 압축을 푼 후에도 먼저 “응용 프로그램” 폴더로 이동하는 것이 좋습니다. 다운로드 폴더나 디스크 이미지 안에서 계속 실행하면 자동 업데이트, 권한 저장 또는 보조 구성 요소 설치에 문제가 생길 수 있습니다.
처음 실행할 때 macOS는 개발자 서명과 공증 상태를 확인합니다. 시스템이 실행을 차단하면 먼저 설치 패키지의 출처와 개발자 이름을 확인하세요. 문제가 없다고 판단되면 “시스템 설정”의 “개인정보 보호 및 보안” 영역에서 시스템이 제공하는 처리 방법을 확인할 수 있습니다. macOS 버전에 따라 메뉴 문구는 조금 다르지만 원칙은 같습니다. 방금 직접 설치했고 출처와 이름이 명확히 일치하는 앱만 허용하세요.
“앱 열기 허용”과 “VPN 구성 생성 허용”은 서로 다른 작업입니다. 전자는 앱 실행 여부를 결정하고, 후자는 클라이언트가 네트워크 터널을 만들 수 있는지를 결정합니다. 메뉴 막대에 앱 아이콘이 나타났다는 사실은 프로그램이 실행됐다는 뜻일 뿐, 네트워크 트래픽 처리에 필요한 권한을 얻었다는 의미는 아닙니다.
메뉴 막대 앱과 일반 창 앱의 차이
일부 macOS 클라이언트는 주로 메뉴 막대에 상주하므로, Dock 아이콘을 눌렀는데 큰 창이 나타나지 않아도 반드시 오류는 아닙니다. 화면 상단 메뉴 막대에 클라이언트 아이콘이 있는지 확인한 다음 아이콘 메뉴에서 기본 화면, 구성 목록 또는 연결 스위치를 여세요. 다른 클라이언트는 일반 창 형태로 작동하며 창을 닫아도 백그라운드에서 실행될 수 있습니다. 종료할 때는 창만 닫지 말고 클라이언트 메뉴의 “종료”를 사용하세요.
시스템 확장 권한: 팝업을 거부했을 때 해결하는 방법
네트워크 트래픽을 처리하기 위해 클라이언트가 VPN 구성 추가, 네트워크 확장 활성화 또는 관련 시스템 확장 승인을 요청할 수 있습니다. 표시되는 안내는 클라이언트 구현에 따라 달라집니다. Network Extension을 사용하는 클라이언트는 일반적으로 macOS의 시스템 확인 창을 표시하며, 일부는 “네트워크” 또는 “VPN 및 필터”에 구성 항목을 남깁니다. 이는 시스템이 네트워크 터널을 관리하는 정상적인 방식이지만, 현재 앱의 출처를 확인한 뒤에만 승인해야 합니다.
첫 팝업에서 거부를 선택했더라도 보통 시스템 전체를 삭제할 필요는 없습니다. 먼저 클라이언트를 완전히 종료한 뒤 “시스템 설정”을 열고 “개인정보 보호 및 보안”, “네트워크”, “VPN 및 필터” 등 관련 영역에 승인 대기 중인 확장이나 활성화되지 않은 VPN 구성이 있는지 확인하세요. 허용을 완료한 뒤 클라이언트를 다시 시작합니다. 시스템에서 다시 로그인하거나 Mac을 재시동하라고 하면 작업을 저장한 후 안내에 따르세요.
설정에 승인 대기 항목이 없다면 클라이언트로 돌아가 TUN, 강화 모드 또는 가상 네트워크 카드 모드를 껐다가 다시 활성화해 권한 요청을 재시도하세요. 여전히 알림이 나타나지 않을 때는 클라이언트가 만든 기존 VPN 구성을 삭제하고 앱을 종료한 뒤 다시 설치하는 방법을 고려할 수 있습니다. 삭제하기 전에 수동 규칙과 로컬 구성을 백업하고, 구독 링크도 안전한 위치에 보관하세요.
- 클라이언트를 완전히 종료하세요. 메뉴 막대 아이콘이 사라졌는지 확인해 백그라운드 프로세스가 네트워크 확장을 계속 점유하지 않도록 합니다.
- 시스템 설정을 확인하세요. 개인정보 보호, 보안, 네트워크 및 VPN 구성 관련 영역에서 승인 대기 또는 비활성화된 항목을 찾으세요.
- 요청을 다시 실행하세요. 클라이언트를 다시 열고 네트워크 확장이 필요한 연결 모드를 활성화하세요.
- 기존 구성 충돌을 처리하세요. 시스템에 같은 클라이언트가 남긴 만료된 구성이 있다면 기존 항목을 삭제한 후 다시 권한을 승인하세요.
- 마지막으로 재설치하세요. 재설치 전에 로컬 규칙을 기록해 권한 문제를 구성 손실 문제로 키우지 않도록 하세요.
기업에서 관리하는 Mac은 구성 프로파일로 VPN, 네트워크 확장 또는 시스템 확장을 제한할 수 있습니다. 이런 환경에서는 시스템 설정에 관련 옵션이 보여도 현재 사용자가 변경하지 못할 수 있습니다. 이때는 기기 관리 정책을 따라야 하며 제한을 우회해서는 안 됩니다. 개인 기기에서 VPN 구성을 계속 저장하지 못한다면 시스템 설정을 변경하는 데 필요한 권한이 현재 계정에 있는지 확인하세요.
구독 링크 가져오기: 노드를 수동으로 옮기지 말고 구성 업데이트하기
클라이언트 설치와 권한 승인이 끝나면 “구독”, “구성”, “Profiles” 또는 비슷한 이름의 페이지에서 URL 가져오기를 선택하고 서비스 패널에서 제공한 구독 링크를 붙여 넣으세요. 클라이언트마다 필드 이름은 구독 주소, 원격 구성 또는 구성 URL 등으로 다를 수 있지만, 본질적으로는 서비스 서버가 관리하는 노드 목록과 규칙 정보를 내려받는 기능입니다.
가져오기가 완료되면 먼저 구성 이름, 업데이트 시간, 노드 목록이 표시되는지 확인한 뒤 연결하세요. 클라이언트에 빈 구성만 표시되거나 형식을 인식할 수 없다는 메시지가 나오면 링크가 완전한지, 앞뒤에 공백이 들어가지 않았는지, 현재 클라이언트가 해당 구독 형식을 지원하는지부터 확인하세요. 각 노드를 서둘러 수동으로 복사하지 마세요. 전송 계층, 보안 계층, 서버 이름, 경로 또는 혼잡 제어 등의 매개변수를 빠뜨리기 쉽습니다.
일부 클라이언트는 “클립보드에서 단일 노드 가져오기”와 “구독 추가”라는 두 가지 진입점을 제공합니다. 전자는 독립된 공유 링크 하나를 가져올 때 적합하고, 후자만 업데이트 가능한 원격 구성을 만듭니다. 구독을 사용할 때는 후자를 선택해야 이후 회선 변경 사항이 구독 업데이트에 반영됩니다. 구독을 업데이트하기 전에는 연결을 잠시 끊고, 업데이트가 끝난 뒤 노드를 다시 선택하면 현재 세션이 만료된 기존 구성을 계속 참조하는 일을 피할 수 있습니다.
클라이언트 설정
→ 구독 또는 구성
→ 원격 구성 추가
→ 구독 링크 붙여넣기
→ 구독 업데이트
→ 회선 선택
→ 연결 설정구독 업데이트 실패 시 점검 순서
먼저 다른 프록시 도구를 잠시 끄고 시스템 시간이 자동으로 동기화되는지 확인한 뒤 다시 업데이트하세요. 시스템 시간이 크게 어긋나면 TLS 인증서 검증이 실패할 수 있고, 기존 프록시 규칙이 잘못되어 있으면 구독 요청이 사용할 수 없는 회선으로 전달될 수 있습니다. 클라이언트에서 로그를 볼 수 있다면 “구문 분석 실패”, “인증서 검증 실패”, “연결 시간 초과”, “지원되지 않는 프로토콜” 같은 명확한 오류를 찾고, 업데이트 버튼을 연속으로 누르지는 마세요.
처음에는 가져오기에 성공했지만 나중에 업데이트에 실패했다면 로컬 캐시와 원격 구독을 구분해야 합니다. 로컬 노드를 삭제해도 원격 주소는 복구되지 않으며, 여전히 사용할 수 있는 기존 구성을 잃을 수 있습니다. 먼저 오류 메시지를 복사하고 구독 링크가 잘리지 않았는지 확인한 다음 패널에서 주소를 다시 복사하는 것이 안전합니다. 로컬 구성이 손상됐다고 확신할 때만 삭제 후 구독을 다시 추가하세요.
회선 및 프로토콜 선택: 직결, 중계, IEPL 이해하기
노드 이름에는 지역, 진입 유형, 프로토콜 정보가 함께 표시되는 경우가 많습니다. 선택할 때 지역만 보지 마세요. 직결은 일반적으로 클라이언트가 출구 서버에 직접 연결하는 방식으로, 경로가 짧고 구조가 단순하지만 국제 구간 품질은 현지 통신사 라우팅과 시간대의 영향을 더 크게 받습니다. 중계는 가까운 진입 지점에 먼저 연결한 뒤 중계 네트워크를 통해 출구로 전달하는 방식으로, 일부 네트워크에서 라우팅 안정성을 개선할 수 있지만 전달 단계가 하나 더 늘어나므로 진입 지점 상태도 확인해야 합니다.
IEPL은 일반적으로 국제 이더넷 전용 회선 계열 연결을 뜻하며, 일반 공용 인터넷에서 무작위로 우회하는 대신 국제 구간에 전용 전송망을 사용하는 데 중점을 둡니다. 실제 제품의 명칭과 접속 구조는 다를 수 있으므로 “전용 회선”이라는 문구만 보고 모든 경로가 완전히 같다고 단정해서는 안 됩니다. 회선은 접속 대상, 현지 네트워크, 저녁 시간대 성능, 실제 패킷 손실을 함께 고려해 판단하고, 클라이언트에서 한 번 새로 고친 지연 시간만 비교하지 마세요.
| 프로토콜 또는 회선 | 주요 특징 | macOS에서 확인할 점 | 적합한 판단 방법 |
|---|---|---|---|
| Shadowsocks | 암호화 프록시 프로토콜로, 구성 구조가 비교적 단순하고 생태계 지원이 폭넓습니다. | 암호화 방식이 클라이언트에서 지원되는지 확인하고 시스템 프록시 또는 TUN 모드를 점검하세요. | 먼저 기본 연결성을 확인한 뒤 앱 유형에 따라 트래픽 처리 모드를 결정하기에 적합합니다. |
| VMess | 인증 및 전송 설정을 포함하며 WebSocket 같은 전송 방식과 함께 구성되는 경우가 많습니다. | 클라이언트가 구독에 포함된 전송 계층 매개변수를 완전히 지원해야 합니다. | 구문 분석 후 노드가 표시되는지 확인해야 하며, 구독 가져오기에 성공했다는 사실만 확인해서는 안 됩니다. |
| VLESS | 인증 구조가 간결하며 일반적으로 TLS, Reality 또는 다른 전송 구성과 함께 사용해야 합니다. | 서버 이름, 보안 계층, 전송 매개변수가 모두 필요합니다. | 구독을 이용해 자동으로 배포하는 것이 적합하며, 수동 설정으로 핵심 필드를 빠뜨리는 일을 줄일 수 있습니다. |
| Trojan | TLS 기반 암호화 전송 방식으로, 올바른 인증서와 서버 이름 구성이 필요합니다. | 시스템 시간, 인증서 검증, SNI 구성이 연결에 영향을 줍니다. | 실패하면 시스템 DNS를 반복해서 바꾸기보다 TLS 로그를 먼저 확인하세요. |
| Hysteria2 | QUIC와 UDP를 기반으로 하며, 혼잡 제어를 사용해 변동이 있는 경로에 대응합니다. | 현지 네트워크에서 UDP를 제한하면 핸드셰이크 실패 또는 성능 저하가 발생할 수 있습니다. | 먼저 UDP 사용 가능 여부를 확인한 뒤 지속적인 연결 안정성을 관찰하세요. |
| TUIC | 마찬가지로 QUIC와 UDP를 기반으로 하며 다중화와 전송 제어를 강조합니다. | 클라이언트 코어와 구독 매개변수가 서로 호환되어야 합니다. | 프로토콜 이름만으로 속도를 판단할 수 없으며, 동일한 네트워크 조건에서 비교해야 합니다. |
| 직결 | 클라이언트가 출구에 직접 연결하는 방식으로 구조가 단순하지만 공용 인터넷 라우팅의 영향을 크게 받습니다. | 기본 비교용 회선으로 사용하기에 적합합니다. | 접속 대상별로 연결 상태와 패킷 손실을 각각 관찰하세요. |
| 중계 또는 IEPL | 진입 지점과 제어된 전송망을 통해 일부 국제 경로를 개선하며, 실제 구조는 서비스 서버에 따라 결정됩니다. | 진입 지점의 접속 가능 여부와 출구 위치를 함께 확인해야 합니다. | 현지 네트워크와 시간대를 고정한 상태에서 직결과 비교하세요. |
프로토콜에는 환경을 배제한 고정적인 속도 순위가 없습니다. Hysteria2와 TUIC는 UDP 조건이 필요하고, Trojan·VLESS·VMess의 사용감은 전송 계층, 서버 구성, 실제 경로에 따라 달라지며, Shadowsocks도 클라이언트 구현과 암호화 방식의 영향을 받습니다. 처음 설정할 때는 호환성이 명확한 노드 하나로 연결을 확인한 뒤 다른 회선을 비교하세요. 프로토콜, 회선, DNS, 분할 규칙을 동시에 바꾸면 차이의 원인을 찾기 어렵습니다.
VPN 작동 확인: 출구 IP, DNS, 앱 트래픽 점검
클라이언트에 “연결됨”이라고 표시되는 것은 클라이언트가 터널이 설정됐다고 판단한다는 뜻일 뿐입니다. 실제 확인은 트래픽 결과를 통해 역으로 판단해야 합니다. 출구 IP가 바뀌었는지, DNS 요청이 예상한 해석 경로를 사용하는지, 대상 앱이 현재 프록시 또는 가상 네트워크 인터페이스를 따르는지 확인하세요. 연결 전에 로컬 출구 정보를 기록한 뒤, 연결 후에는 이 사이트의 내 IP 페이지를 열어 비교하는 것이 좋습니다.
출구 IP가 바뀌지 않았다면 먼저 클라이언트가 시스템 프록시 모드인지 TUN 모드인지 확인하세요. 시스템 프록시 모드는 macOS 프록시 설정을 따르는 앱에만 영향을 주며, 일부 명령줄 도구, 게임, 자체 네트워크 스택을 구현한 소프트웨어는 이를 우회할 수 있습니다. TUN 또는 강화 모드는 일반적으로 네트워크 확장을 통해 더 넓은 트래픽을 처리하지만 시스템 권한이 필요하고 다른 VPN, 필터 또는 보안 소프트웨어와 충돌할 수 있습니다.
DNS 확인도 빼놓을 수 없습니다. 출구 트래픽은 원격 회선을 통과하지만 DNS는 현지 네트워크가 계속 해석하면 DNS 유출이 발생하거나 해석 결과와 출구 지역이 일치하지 않을 수 있습니다. 신뢰할 수 있는 DNS 검사 도구로 해석 서비스의 소속을 확인하고, 클라이언트 로그에서 DNS 요청을 어느 모듈이 처리하는지 함께 확인하세요. 브라우저에서 별도의 보안 DNS를 활성화하면 해석 경로가 클라이언트 설정을 우회할 수 있으므로 문제를 점검할 때 브라우저 설정도 확인해야 합니다.
- ✅ 연결 전후의 출구 IP를 각각 확인하고 예상한 지역 변화가 발생했는지 확인하세요.
- ✅ DNS 해석 서비스가 클라이언트 설정 및 현재 분할 규칙과 일치하는지 점검하세요.
- ✅ 브라우저, 명령줄 도구, 실제 대상 앱을 각각 테스트하세요.
- ✅ 클라이언트 로그에 지속적인 재연결, 핸드셰이크 실패 또는 규칙 미적용이 있는지 확인하세요.
- ❌ 노드 옆의 지연 시간 숫자만으로 연결이 완전히 확인됐다고 판단하지 마세요.
- ❌ 캐시된 페이지와 DNS 결과를 사용하는 브라우저 탭 하나만 테스트하지 마세요.
터미널에서 현재 출구 확인하기
터미널에 익숙한 사용자는 신뢰할 수 있는 IP 조회 인터페이스에 접속해 출구를 확인할 수 있지만, 명령줄 도구가 시스템 프록시를 반드시 따르는 것은 아닙니다. 클라이언트에서 시스템 프록시만 켰다면 터미널과 브라우저의 결과가 다를 수 있습니다. 이는 반드시 회선이 작동하지 않는다는 뜻이 아니라 두 앱이 서로 다른 경로를 사용한다는 의미입니다. 터미널 트래픽도 회선을 통과시키려면 적절한 TUN 모드를 활성화하거나 클라이언트 문서에 따라 터미널용 프록시 환경을 설정하세요.
분할 규칙: 어떤 웹사이트는 회선을 사용하고 어떤 곳은 직결되는 이유
많은 클라이언트가 글로벌, 규칙, 직결 등의 모드를 제공합니다. 글로벌 모드는 처리 가능한 트래픽을 선택한 노드로 통일해 보내므로 처음 터널을 확인할 때 적합합니다. 규칙 모드는 도메인, IP, 프로세스 또는 규칙 집합에 따라 경로를 결정해 일상적인 사용에 더 적합합니다. 직결 모드는 일반적으로 원격 노드를 거치지 않아 현지 네트워크 복구나 비교 점검에 사용할 수 있습니다. 이러한 명칭의 의미는 클라이언트마다 조금 다를 수 있으므로 해당 안내를 기준으로 판단하세요.
구독을 처음 가져온 뒤 어떤 웹사이트의 출구는 바뀌었지만 다른 웹사이트는 여전히 현지 경로를 사용한다면, 먼저 현재 규칙 모드인지 확인하세요. 규칙에 따라 현지 서비스, 로컬 네트워크 주소 또는 특정 지역 도메인이 직결로 지정되어 있을 수 있습니다. 이는 반드시 오류는 아닙니다. 실제로 점검해야 할 문제는 대상 도메인이 잘못 매칭됐거나, DNS 해석 주소와 규칙이 일치하지 않거나, 앱이 클라이언트를 전혀 거치지 않는 경우입니다.
규칙을 수정할 때는 가장 구체적인 매칭 항목부터 적용하고 기본 대체 규칙을 유지하세요. 도메인 규칙은 안정적인 도메인에 적합하고, IP 규칙은 해석 결과에 의존하며, 프로세스 규칙은 클라이언트가 앱 프로세스를 식별할 수 있는지에 따라 달라집니다. 복잡한 서비스는 여러 도메인과 콘텐츠 전송 네트워크를 사용할 수 있으므로 메인 사이트 도메인만 추가하면 로그인, 미디어 또는 API 요청까지 처리하기에 부족할 수 있습니다.
글로벌 모드를 활성화했을 때 대상 앱이 정상으로 돌아오지만 규칙 모드로 전환하면 실패한다면, 회선 자체는 사용할 수 있고 문제는 규칙이나 DNS에 있을 가능성이 큽니다. 이때는 노드를 계속 바꾸기보다 규칙 매칭 로그를 확인하는 편이 효과적입니다. 규칙을 수정한 뒤에는 앱 내부 캐시를 삭제하거나 앱을 다시 시작해 기존 연결이 원래 경로를 계속 재사용하지 않도록 하세요.
일반적인 연결 장애: 증상으로 문제 범위 좁히기
클라이언트에는 연결됨으로 표시되지만 모든 웹페이지가 열리지 않음
먼저 직결 모드로 전환해 현지 네트워크 자체가 정상인지 확인한 뒤 회선으로 돌아와 선택한 노드가 최신 구독에 여전히 존재하는지 확인하세요. 이어서 클라이언트 로그에서 DNS, 핸드셰이크, 라우팅 오류를 확인합니다. 방금 TUN 모드를 활성화했다면 시스템이 네트워크 확장을 승인했는지, 시스템에 다른 VPN이나 필터가 관련 인터페이스를 점유하고 있지 않은지도 확인하세요.
브라우저는 접속되지만 다른 앱에는 변화가 없음
이는 대개 시스템 프록시가 처리하는 범위와 관련이 있습니다. 브라우저는 시스템 프록시를 따르지만 다른 앱은 직접 연결을 만들 수 있습니다. 먼저 클라이언트가 지원하는 TUN 모드로 확인할 수 있지만, 활성화 전에 작업을 저장하고 다른 네트워크 확장과 충돌하지 않는지 확인하세요. 특정 앱만 회선을 사용하게 하려면 클라이언트가 지원하는 프로세스 분할을 사용할 수도 있으나, 앱 업데이트 후 프로세스 이름이 바뀌었는지 확인해야 합니다.
구독은 업데이트되지만 노드에 연결할 수 없음
구독 요청과 노드 연결은 같은 경로가 아닙니다. 전자가 성공했다는 것은 설정 주소에 접근할 수 있다는 뜻일 뿐이고, 후자는 노드 프로토콜, 포트, 전송 계층, 현지 네트워크에 추가로 의존합니다. 먼저 구독에 포함된 다른 프로토콜 유형을 선택해 비교하세요. UDP 기반 노드만 실패한다면 현재 네트워크의 UDP 지원을 확인해야 합니다. TLS 계열 노드가 실패하면 시스템 시간, 서버 이름, 인증서 관련 로그를 점검하세요.
절전 모드에서 깨어난 후 연결이 끊김
Mac이 절전 모드에서 복귀하면 네트워크 인터페이스, 무선 네트워크 또는 주소가 바뀔 수 있어 기존 터널을 계속 재사용하지 못할 수 있습니다. 먼저 연결을 끊었다가 다시 연결하고, 여러 노드를 동시에 반복해서 클릭하지 마세요. 자주 발생한다면 네트워크 변경 후 자동 재연결 기능을 클라이언트가 제공하는지 확인하고, 이 기능이 시스템에 상주하는 다른 네트워크 도구와 동시에 라우팅을 재설정하지 않는지도 확인하세요.
클라이언트를 삭제했지만 시스템 프록시가 계속 남아 있음
앱이 비정상적으로 종료되면 시스템 프록시 설정이 제때 복원되지 않을 수 있습니다. macOS 네트워크 설정에서 현재 네트워크 서비스의 프록시 항목이 로컬 수신 주소를 가리키고 있는지 확인하세요. 클라이언트가 종료된 것을 확인한 뒤 남은 프록시 구성을 끄면 됩니다. VPN 네트워크 확장을 사용했다면 “VPN 및 필터”에서도 기존 구성이 활성화되어 있는지 확인하세요. 항목을 삭제하기 전 이름을 대조해 기업 또는 업무 환경에 필요한 구성을 실수로 지우지 않도록 하세요.
첫 연결 후 유지 관리: 구독 업데이트와 로컬 구성 보호
첫 연결을 완료한 후에는 현재 클라이언트, 처리 모드, 사용 가능한 회선을 기억해 나중에 비교할 수 있도록 하세요. 구독은 클라이언트의 업데이트 기능으로 관리하면 되며, 자주 삭제하고 다시 만들 필요가 없습니다. 클라이언트 업데이트 후 프로토콜 호환성 문제가 생기면 먼저 코어 또는 구성 형식이 변경됐는지 확인한 뒤 로컬 구성의 복원을 결정하세요. 구조가 다른 새 버전에 기존 구성 파일을 바로 덮어쓰지는 마세요.
로컬 사용자 지정 규칙, 우회 목록, DNS 설정은 별도로 백업하는 것이 좋지만, 구독 토큰은 공개 코드 저장소나 공유 가능한 스크린샷에 포함하지 마세요. 클라이언트를 바꿀 때도 이름이 같은 옵션의 동작이 완전히 같다고 가정해서는 안 됩니다. 예를 들어 두 클라이언트 모두 “규칙 모드”를 제공하더라도 기본 규칙 집합, DNS 가로채기 방식, 앱 처리 범위는 다를 수 있으므로 출구와 DNS를 다시 확인해야 합니다.
일상적인 사용 중 특정 회선만 일시적으로 연결되지 않는다면 먼저 구독을 업데이트하고 같은 유형의 다른 회선으로 전환하세요. 바로 클라이언트를 재설치할 필요는 없습니다. 앱 파일이 손상됐거나 네트워크 확장을 다시 등록하지 못하거나 로컬 구문 분석이 계속 실패할 때만 재설치가 합리적입니다. 재설치 후에도 이 글의 순서에 따라 다시 권한을 승인하고 가져온 뒤 확인해야 하며, 기존 권한이 자동으로 이어진다고 가정해서는 안 됩니다.
신뢰할 수 있는 macOS 구성은 “연결 버튼이 녹색으로 바뀌는 것”으로 끝나지 않습니다. 현재 트래픽이 어떤 모드로 처리되는지, 규칙이 어떻게 매칭되는지, DNS가 어디에서 해석되는지, 장애가 발생했을 때 어느 계층을 확인해야 하는지를 설명할 수 있어야 합니다. 설치, 권한, 구독, 확인을 나누어 처리하면 처음 설정과 이후 유지 관리가 모두 더 안정적으로 관리됩니다.