v2rayN을 실행하고 노드를 선택했는데도 macOS 브라우저에서 웹페이지가 열리지 않을 때 확인할 내용입니다. 먼저 요청이 로컬 프록시로 전달되는지 확인한 다음, 아웃바운드 연결과 도메인 조회를 점검하세요. 같은 URL로 테스트하고 매번 설정 하나만 변경하면 시스템 프록시 미적용, 포트 미수신, 잘못된 라우팅, DNS 오류, 브라우저 자체 설정 문제를 구분할 수 있습니다.
1. ‘연결됨’이 어느 단계의 상태인지 확인
클라이언트 창이 열리고 노드가 선택되어 있으며 지연 시간 테스트 결과가 나와도 브라우저가 해당 노드를 통해 웹사이트에 접속한다는 뜻은 아닙니다. V2Ray와 Xray는 프록시 코어이며, v2rayN은 설정을 관리하고 코어를 실행합니다. 시스템 프록시는 이 설정을 따르는 앱의 요청을 로컬 프록시로 전달합니다. 어느 단계에서든 연결이 끊기면 ‘클라이언트는 정상인데 웹페이지는 시간 초과’ 상태가 발생할 수 있습니다.
- 먼저 일반 네트워크를 확인하세요: 프록시 사용을 중지하고 평소 직접 접속할 수 있는 웹사이트를 열어 보세요. 여기서도 실패한다면 Wi-Fi, 인증 포털 또는 네트워크 자체부터 점검하세요.
- 다음은 코어입니다: v2rayN의 로그 창을 열고 실행 후 포트 충돌이나 설정 파싱 오류가 없는지 확인하세요. 메인 창이 보이는 것만으로 코어가 정상 실행됐다고 볼 수는 없습니다.
- 마지막으로 요청을 확인하세요: 대상 웹페이지를 새로고침하고 접속 로그에 해당 도메인 기록이 남는지 확인하세요. 접속 로그가 비활성화된 경우 기록이 없다는 사실만으로 요청이 코어에 전달되지 않았다고 단정할 수 없습니다.
2. macOS 시스템 프록시와 현재 네트워크 서비스 확인
시스템 프록시 설정은 네트워크 서비스별로 저장됩니다. Wi-Fi에서 설정이 올바르더라도 이더넷으로 전환하면 적용되지 않을 수 있으며, VPN이나 네트워크 관리 프로그램이 설정을 덮어쓸 수도 있습니다. 먼저 v2rayN의 ‘시스템 프록시’에서 ‘시스템 프록시 자동 설정’을 선택한 뒤 macOS 설정에서 실제 적용 상태를 확인하세요. 버전에 따라 메뉴 위치가 다를 수 있으니 현재 화면의 항목 이름을 기준으로 진행하세요.
-
네트워크 설정 열기
macOS ‘시스템 설정’ → ‘네트워크’ → 현재 사용 중인 Wi-Fi 또는 이더넷 서비스 → ‘세부사항’ → ‘프록시’로 이동하세요. 실제로 인터넷에 연결된 서비스를 확인해야 합니다.
-
프록시 주소 확인
수동 프록시는 보통 로컬 주소
127.0.0.1을 사용합니다. HTTP, HTTPS 또는 SOCKS 포트는 클라이언트에서 실제로 수신 중인 포트와 일치해야 합니다. 노드의 원격 서버 포트를 여기에 입력하지 마세요. -
프록시 적용 방식 구분
자동 프록시 구성을 사용한다면 구성 주소와 클라이언트 모드가 일치하는지 확인하세요. 수동 프록시라면 해당 옵션이 켜져 있는지 확인하세요. 출처를 알 수 없는 기존 자동 프록시 구성과 수동 설정이 함께 적용된 상태로 테스트하지 마세요.
-
요청 다시 보내기
설정을 저장한 뒤 대상 페이지를 다시 여세요. 변화가 없으면 브라우저를 완전히 종료했다가 다시 실행하고, 터미널에서
scutil --proxy를 실행해 유효한 설정의 주소, 포트, 활성화 상태를 확인하세요.
scutil --proxy 출력의 HTTPEnable, HTTPSEnable, SOCKSEnable 항목으로 수동 프록시가 켜져 있는지 확인할 수 있습니다. 자동 구성은 ProxyAutoConfigEnable과 구성 주소도 확인해야 합니다. 이 명령은 시스템 설정을 보여 주지만 모든 앱이 해당 설정을 따른다는 뜻은 아닙니다. 일부 터미널 도구와 브라우저는 별도의 프록시 설정을 사용합니다.
3. 로컬 포트가 수신 중인지 확인하고 프록시를 직접 테스트
먼저 v2rayN의 ‘설정’ → ‘매개변수 설정’에서 로컬 수신 포트를 확인하세요. 버전에 따라 항목 이름이 다를 수 있습니다. 아래 예시는 SOCKS를 지원하는 것으로 확인된 10808 포트를 사용하며, 모든 설치 환경에서 이 값으로 바꾸라는 뜻은 아닙니다. 프록시 입구가 HTTP만 지원한다면 해당 HTTP 프록시 테스트 방법을 사용하세요.
# 예시 포트에서 TCP 연결을 수신 중인지 확인
lsof -nP -iTCP:10808 -sTCP:LISTEN
# SOCKS 프록시를 통해 접속하고 대상 도메인은 프록시 측에서 조회
curl --noproxy "" --proxy socks5h://127.0.0.1:10808 \
--connect-timeout 5 --max-time 15 -I https://example.com/lsof에 결과가 표시되면 해당 프로세스가 현재 사용하는 코어인지도 확인하세요. 다른 프로그램이 같은 포트를 사용해도 결과가 나옵니다. 결과가 없다면 포트 입력이 맞는지, 코어가 종료되지 않았는지, 수신 주소가 예상한 값인지 확인하세요. 문제가 생겼다고 바로 LAN 수신을 허용하지 마세요. 브라우저에서 로컬 프록시에 접속하는 데는 보통 필요하지 않습니다.
테스트 URL에는 명령 설명을 위한 예약 예시 도메인을 사용합니다. 실제 점검에서는 접속이 가능한 것으로 확인된 HTTPS 주소로 바꾸세요. HTTP 응답 헤더를 받았다면 해당 요청에서 프록시 연결과 HTTPS 통신이 적어도 완료된 것입니다. 상태 코드가 403이더라도 연결 시간 초과와는 다른 상황입니다. URL 하나의 성공이 모든 사이트나 라우팅 규칙이 정상이라는 뜻은 아닙니다.
판별: 명령은 성공하지만 브라우저는 실패
현재 노드와 DNS 설정을 유지하고 프로토콜부터 바꾸지 마세요. 프록시 직접 연결이 된다면 시스템 프록시 적용 상태, 브라우저 자체 프록시, 확장 프로그램 설정을 먼저 확인하세요. 직접 연결도 실패한다면 아웃바운드 연결과 도메인 조회를 계속 점검하세요.
4. 라우팅 결과를 비교해 잘못된 분기 찾기
라우팅은 요청을 직접 연결, 프록시 또는 차단 중 어디로 보낼지 결정합니다. 규칙의 ‘직접 연결’은 사용할 수 있는 경로를 자동으로 선택한다는 뜻이 아닙니다. 대상 도메인이 잘못 직접 연결로 분류되면 현재 네트워크에서 접속할 수 없는 경우 요청이 실패합니다. 전역 프록시를 사용해도 모든 트래픽이 프록시를 거친다는 보장은 없습니다. 전역 프록시는 코어에 전달된 요청에만 영향을 줍니다.
| 비교 결과 | 우선 의심할 항목 | 다음 단계 |
|---|---|---|
| 규칙 모드에서는 실패하고 전역 프록시에서는 성공 | 도메인 또는 IP가 직접 연결이나 차단되는 아웃바운드로 분류됨 | 적용된 규칙과 아웃바운드 태그를 확인하고 수정한 뒤 규칙 모드로 복원 |
| 두 모드 모두 실패 | 로컬 프록시 입구, 노드 아웃바운드 또는 DNS | 프록시 직접 연결 명령을 실행하고 같은 시점의 오류 로그 확인 |
| 웹페이지는 열리지만 특정 앱에서는 실패 | 앱이 시스템 프록시를 사용하지 않거나 별도 설정이 있음 | 해당 앱의 프록시 설정을 확인한 뒤 TUN이 필요한지 판단 |
| 일부 도메인만 실패 | 사이트 제한, 라우팅 규칙 또는 특정 DNS 응답 | 다른 도메인과 비교해 노드 전체에 문제가 있다고 성급히 판단하지 않기 |
v2rayN의 라우팅 선택에서 ‘전역’으로 잠시 전환해 비교 테스트한 뒤 원래 모드로 복구하세요. 설정의 아웃바운드 태그가 proxy, direct 또는 block이라면 접속 로그에서 해당 태그를 확인하세요. 사용자 지정 설정에서는 다른 이름을 사용할 수 있으므로 태그 이름만 보고 동작을 추측하지 마세요.
5. 로컬 DNS, 프록시 측 DNS, 브라우저 DNS 구분
DNS 조회는 한 단계에서만 이루어지지 않습니다. macOS 리졸버, 브라우저의 보안 DNS, 코어 DNS, 프록시 서버 측 조회가 모두 관여할 수 있습니다. 시스템 DNS를 바꿔도 프록시 측 조회 결과는 달라지지 않을 수 있습니다. 브라우저의 보안 DNS를 켰다고 해서 노드 서버 주소가 반드시 올바르게 조회되는 것도 아닙니다.
다음 명령은 SOCKS 요청에서 대상 도메인을 조회하는 위치만 바꿉니다. 첫 번째 명령은 로컬에서 대상 도메인을 조회하고, 두 번째 명령은 대상 도메인을 프록시 측으로 전달합니다. 두 테스트에서 같은 노드, URL, 포트를 사용하고 로컬 프록시 입구가 SOCKS를 지원하는지 확인하세요.
# 로컬에서 대상 도메인 조회
curl --noproxy "" --proxy socks5://127.0.0.1:10808 \
--connect-timeout 5 --max-time 15 -I https://example.com/
# 프록시 측에서 대상 도메인 처리
curl --noproxy "" --proxy socks5h://127.0.0.1:10808 \
--connect-timeout 5 --max-time 15 -I https://example.com/
# macOS의 현재 DNS 리졸버 설정 확인
scutil --dns- 로컬 조회는 실패하고 프록시 측 조회는 성공: 시스템 리졸버, 네트워크에서 제공한 DNS, 로컬 캐시를 먼저 확인하세요. 이는 원인을 좁히기 위한 단서일 뿐, 한 번의 테스트만으로 DNS 변조를 확정할 수는 없습니다.
- 로컬 조회는 성공하고 프록시 측 조회는 실패: 코어와 서버 측 DNS 조회 경로, 원격 DNS 연결 가능 여부를 확인하고 관련 DNS 요청이 어느 아웃바운드로 전달되는지 살펴보세요.
- 둘 다 실패: 로컬 프록시 연결, 노드 연결, 대상 TLS 핸드셰이크 중 어느 단계에서 오류가 발생했는지 먼저 확인하세요. 모든 시간 초과를 DNS 문제로 단정하지 마세요.
- 브라우저에서만 실패: 보안 DNS의 기존 설정을 기록한 뒤 잠시 시스템 설정을 따르도록 변경하고 다시 테스트하세요. 테스트 후 필요에 따라 원래 설정을 복구하고 여러 DNS 설정을 한꺼번에 바꾸지 마세요.
DNS 설정을 변경한 뒤 sudo dscacheutil -flushcache와 sudo killall -HUP mDNSResponder를 실행해 macOS DNS 캐시를 갱신하고 브라우저를 다시 시작할 수 있습니다. 명령 실행에는 관리자 권한이 필요합니다. 네트워크 설정 자체가 잘못됐다면 캐시를 지워도 해결되지 않습니다. DNS나 TLS 문제를 우회하려고 인증서 검증을 끄지 마세요.
6. ‘시간 초과’만 보지 말고 원래 오류로 원인 찾기
오류가 발생했을 때 전체 메시지를 보관하고 로컬 연결 실패, 도메인 조회 실패, 인증서 오류를 구분하세요. 아래는 curl에서 자주 볼 수 있는 오류 접두부입니다. 실제 출력에는 포트, 호스트명, 인증서 관련 설명이 덧붙을 수 있으므로 뒤에 이어지는 세부 내용도 함께 확인하세요.
오류: curl: (7) Failed to connect
원인 및 해결: 지정한 주소에 연결하지 못했습니다. 뒤에 127.0.0.1이 표시되면 로컬 포트와 코어의 수신 상태를 먼저 확인하세요. 원격 주소라면 실제 요청 경로와 아웃바운드 연결을 계속 점검하세요.
오류: curl: (6) Could not resolve host
원인 및 해결: 로컬에서 대상 호스트명을 조회하지 못했습니다. URL 철자를 확인하고 scutil --dns로 DNS 리졸버를 점검한 뒤 socks5h 테스트 결과와 비교하세요.
오류: curl: (28) Operation timed out
원인 및 해결: 요청이 설정한 시간을 초과했지만 오류 메시지만으로는 어느 단계의 문제인지 알 수 없습니다. -v 옵션을 추가해 한 번 더 실행하고 로그에서 마지막으로 완료된 연결 단계를 확인하세요. 단순히 시간 초과를 늘려 문제를 감추지 마세요.
오류: curl: (60) SSL certificate problem
원인 및 해결: 인증서 검증에 실패했습니다. 먼저 macOS ‘시스템 설정’ → ‘일반’ → ‘날짜 및 시간’을 확인한 다음 대상 도메인, 인증서 체인, 네트워크 차단 여부를 점검하세요. 검증을 건너뛰는 옵션을 장기적인 해결책으로 사용하지 마세요.
로그를 공유하기 전 구독 링크, 인증 정보, 노드 주소, 접속 기록의 민감한 내용을 가리세요. 오류 유형, 발생 시각, 코어 이름, 필요한 버전 정보만 남기면 됩니다. VMess, VLESS, Trojan 등의 노드 프로토콜 매개변수는 서버 설정에 따라 달라집니다. 프로토콜, TLS 또는 SNI를 임의로 변경하면 새로운 핸드셰이크 오류가 생길 수 있습니다.
7. 브라우저 충돌 점검 및 복구 후 확인
프록시 직접 연결 테스트가 성공하면 브라우저를 점검하세요. 먼저 새 임시 브라우저 프로필로 테스트하고 모든 기록을 바로 삭제하지 마세요. 시크릿 창에서도 모든 확장 프로그램이 비활성화되는 것은 아닙니다. 특히 시크릿 모드 실행 권한을 받은 확장 프로그램은 계속 작동할 수 있습니다. 기업 관리 정책에 따라 프록시 설정이 고정되어 있을 수도 있습니다.
터미널에서는 접속되는데 브라우저에서 페이지가 열리지 않나요?
프록시 전환 확장 프로그램을 먼저 끄고 브라우저가 시스템 프록시를 따르는지 확인한 다음 임시 프로필에서 같은 URL에 접속하세요. Firefox는 ‘설정’ → ‘일반’ → ‘네트워크 설정’에서 시스템 프록시 설정 사용 여부를 확인해 이전 포트를 계속 사용하지 않도록 하세요.
노드를 바꾸니 해결됐는데 DNS도 바꿔야 하나요?
먼저 DNS를 변경하지 마세요. 같은 URL을 유지한 채 두 노드에서 프록시 직접 연결 테스트를 각각 실행하세요. 한 노드에서만 실패한다면 컴퓨터 전체의 DNS 설정을 바꾸기보다 해당 노드의 사용 가능 여부, 프로토콜 매개변수, 아웃바운드 로그를 먼저 확인하세요.
v2rayN을 종료한 뒤 오히려 인터넷이 전혀 안 되나요?
macOS에서 현재 네트워크 서비스의 ‘세부사항’ → ‘프록시’를 열고 이미 수신을 중단한 로컬 포트가 아직 설정되어 있는지 확인하세요. 남은 프록시 설정을 지운 뒤 직접 연결을 테스트하세요. 다음부터는 종료 전에 클라이언트에서 ‘시스템 프록시 해제’를 선택하세요.
Android에서도 연결됨으로 표시되는데 인터넷이 안 되나요?
v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용합니다. 먼저 시스템 VPN 권한, 다른 VPN의 사용 여부, 브라우저가 앱별 트래픽 분기에서 제외되었는지 확인하세요. macOS의 로컬 포트 설정을 Android에 그대로 적용하지 마세요.
- 평소 사용하는 규칙 모드로 복원한 다음 직접 연결할 웹사이트 하나와 프록시가 필요한 웹사이트 하나를 각각 테스트하세요.
- 임시 디버그 로그를 끄고 점검 전 기록한 브라우저 DNS 및 확장 프로그램 설정을 복원하세요. 문제가 발생한 원인이 설정에 있었다면 수정된 값을 유지하세요.
- 클라이언트와 브라우저를 다시 시작해 시스템 프록시가 정상 적용되는지 확인하세요. 그런 다음 클라이언트를 종료하고 시스템 프록시 설정이 제대로 해제되는지도 확인하세요.
- 유효한 로컬 포트, 라우팅 모드, 수정한 항목을 기록해 두세요. 같은 문제가 다시 생기면 모든 설정을 다시 바꾸는 대신 가장 최근의 변경 사항부터 확인하세요.