노드를 가져와 연결까지 마쳤지만, 국내 서비스는 직접 연결하고 나머지 트래픽은 규칙에 따라 프록시로 보내고 싶은 Android 사용자에게 적합합니다. 먼저 ‘LAN 및 중국 IP 우회’ 프리셋을 기준으로 설정한 뒤 필요한 도메인 예외만 추가하고, 로그와 비교 테스트로 출구를 확인합니다. 라우팅, 앱별 프록시, DNS의 역할을 구분해 모든 연결 문제를 하나의 옵션 탓으로 돌리지 않도록 설명합니다.
먼저 확인할 점: 어떤 트래픽이 라우팅되는가
v2rayNG는 Xray 코어로 프록시 연결을 처리합니다. 선택한 노드는 프록시 연결 대상 서버를 정하고, 라우팅 규칙은 각 요청이 해당 출구를 사용할지 결정합니다. VMess, VLESS 같은 노드 프로토콜이 ‘국내는 직접 연결, 해외는 프록시’ 동작을 자동으로 정해 주지는 않습니다. 구독 업데이트에 성공해도 원하는 라우팅 정책이 설정됐다는 뜻은 아닙니다.
이 글은 Android VPN 모드를 기준으로 설명합니다. 앱 트래픽은 먼저 v2rayNG로 들어온 뒤 코어가 직접 연결, 프록시 또는 차단을 선택합니다. 앱별 프록시를 사용하면 제외된 앱은 이 처리 경로를 우회할 수 있습니다. 앱 자체의 네트워크 설정이나 다른 VPN 서비스도 테스트 결과에 영향을 줍니다.
먼저 구분하기: 앱 적용 범위와 요청의 경로
앱별 프록시
- Android 앱별로 VPN 처리 대상에 포함할지 정합니다.
- 같은 앱에서 사이트별로 나누기보다 특정 앱을 제외할 때 적합합니다.
- 테스트할 브라우저가 처리 대상에 포함되어 있어야 합니다.
라우팅
- 코어에 들어온 요청을 도메인, IP 등의 조건으로 분류합니다.
- 같은 브라우저에서 직접 연결 사이트와 프록시 사이트를 함께 이용할 수 있습니다.
- 사용자 지정 전체 설정은 자체 규칙을 정의할 수 있어 화면의 프리셋을 그대로 따르지 않을 수 있습니다.
먼저 테스트 앱이 VPN 처리 대상인지 확인한 뒤 라우팅을 점검하세요. 그렇지 않으면 ‘프록시 로그가 없다’는 사실만으로 직접 연결 규칙이 적용됐다고 단정할 수 없습니다.
프리셋 선택: 되돌릴 수 있는 기준부터 설정하기
메인 화면의 사이드 메뉴에서 ‘설정’으로 들어가 라우팅 관련 항목을 열고 ‘사전 정의 규칙’을 찾습니다. 버전에 따라 ‘라우팅 설정’이 사이드 메뉴의 독립 항목으로 표시되거나 옵션 이름이 ‘라우팅 모드’일 수 있습니다. 메뉴 구성이 다르면 ‘사전 정의 규칙’과 아래 옵션 이름을 기준으로 찾으세요. 노드 선택 메뉴를 라우팅 설정으로 혼동하지 마세요.
LAN 및 중국 IP 우회
권장LAN과 중국 IP는 프리셋에 따라 직접 연결하고, 나머지 트래픽은 일반적으로 프록시 출구로 보냅니다. 실제 분류는 적용된 규칙 데이터와 생성된 설정에 따라 달라지므로 자주 쓰는 사이트에서 확인해야 합니다.
추천 환경: 국내 서비스와 중국 사이트, 해외 서비스를 함께 이용하는 일상적인 환경
LAN 우회
LAN은 직접 연결하고 나머지 트래픽은 일반적으로 프록시로 보냅니다. 공인망 요청의 경로를 중국 IP 분류에 따라 결정하지 않습니다.
추천 환경: 지역별 분류의 영향을 줄이거나 문제를 임시로 비교·점검하려는 경우
전역 프록시
처리 대상에 포함된 트래픽을 주로 프록시로 보냅니다. 모든 앱을 VPN으로 처리한다는 뜻은 아니며, DNS·앱 제외 목록·사용자 지정 설정의 영향도 그대로 받습니다.
추천 환경: 라우팅 규칙이 문제인지 잠시 확인할 때. 테스트가 끝나면 평소 사용하는 프리셋으로 되돌리세요.
-
현재 설정 기록하기
현재 ‘사전 정의 규칙’, ‘도메인 전략’, 사용자 지정 규칙을 저장하고 앱별 프록시가 켜져 있는지 기록합니다. 되돌릴 기준을 먼저 마련하고 노드, DNS, 라우팅을 동시에 변경하지 마세요.
-
프리셋 선택하기
‘설정’ → 라우팅 관련 설정 → ‘사전 정의 규칙’에서 ‘LAN 및 중국 IP 우회’를 선택합니다. 사이드 메뉴에 ‘라우팅 설정’이 있다면 해당 항목에서 같은 이름의 옵션을 찾으세요.
-
도메인 전략 확인하기
‘도메인 전략’을 찾아 현재 값을 기록합니다. 처음 설정한다면 기본값을 유지하세요. IP 규칙으로 매칭을 보완해야 하는 경우에만 아래 내용을 참고해
IPIfNonMatch를 검토하세요. -
재시작 후 테스트하기
저장한 뒤 연결을 중지했다가 다시 시작해 새 설정을 불러옵니다. LAN 관리 페이지, 중국 사이트, 해외 사이트 순으로 열어 접속 여부를 기록한 다음 예외 규칙을 추가하세요.
LAN 직접 연결: 이름보다 주소 범위가 정확합니다
라우터, 프린터, NAS에는 사설 IP 주소를 사용하는 경우가 많습니다. 이 요청을 원격 프록시 서버로 보내면 대개 휴대폰이 연결된 가정 내 네트워크에 접근할 수 없습니다. 프리셋의 사설 IP 규칙이 이런 문제를 해결하지만, 192.168.1.1 하나만 추가할 것이 아니라 실제 주소 범위를 포함하는지 확인해야 합니다.
관련 데이터 파일을 지원하는 설정에서는 geoip:private를 사용해 사설 및 기타 로컬 용도 주소를 분류할 수 있습니다. 실제 범위는 사용하는 데이터에 따라 다릅니다. IPv6 LAN도 별도로 확인하세요. 예를 들어 고유 로컬 주소는 fc00::/7입니다. IPv4 주소 범위 세 개만 작성해서는 모든 로컬 통신을 처리할 수 없습니다.
- 먼저 IP로 테스트: 해당 주소가 실제 게이트웨이인 경우
http://192.168.1.1에 접속하세요. 예시 주소가 모든 라우터의 기본 주소라고 가정하지 마세요. - 그다음 기기 이름으로 테스트: IP에는 연결되지만 기기 이름으로 접속되지 않으면 LAN DNS나 이름 검색을 먼저 확인하세요. 직접 연결 라우팅만으로 이름 해석 문제가 해결되지는 않습니다.
- 기기 검색과 연결을 구분: 화면 미러링이나 프린터 검색에는 멀티캐스트 같은 기능이 사용됩니다. 웹페이지 하나가 열린다는 이유만으로 기기 검색도 정상이라고 볼 수 없습니다.
- 네트워크 격리 확인: 게스트 Wi-Fi나 무선 클라이언트 격리로 기기 간 통신이 차단될 수도 있습니다. 프록시 규칙을 바꿔도 라우터의 격리 정책은 해제되지 않습니다.
도메인 예외: 구체적인 규칙을 분류 규칙보다 앞에 배치
Xray는 설정된 순서대로 라우팅 규칙을 확인하며, 처음 조건에 맞는 규칙이 연결 경로를 결정합니다. 따라서 ‘특정 도메인은 반드시 프록시 사용’ 같은 규칙은 범위가 넓은 중국 직접 연결 분류보다 앞에 두어야 합니다. 화면에서는 프록시, 직접 연결, 차단 항목이 서로 다른 입력란에 표시될 수 있습니다. 입력란의 시각적 위치가 실제 규칙 순서와 일치하지 않을 수 있으므로 내보낸 설정이나 로그로 확인하세요.
| 표기 | 매칭 범위 | 사용 사례 |
|---|---|---|
full:api.example.com | 정확히 일치하는 도메인만 매칭 | 다른 하위 도메인에는 영향을 주지 않고 특정 엔드포인트만 조정 |
domain:example.com | 해당 도메인과 모든 하위 도메인 매칭 | 사이트 전체를 직접 연결하거나 프록시로 연결 |
geosite:cn | 데이터 파일의 cn 도메인 분류와 매칭 | 중국 사이트를 넓은 범위로 분류 |
geoip:cn | 데이터 파일의 중국 IP 분류와 매칭 | 대상 IP를 기준으로 추가 판정 |
아래는 Xray 규칙 일부를 보여 주는 예시이며, 그대로 가져올 수 있는 전체 노드 설정이 아닙니다. example.com은 문법 설명용 도메인이므로 실제로 사용할 때는 대상 사이트의 도메인으로 바꾸세요. proxy, direct, block은 현재 설정에 실제로 존재하는 아웃바운드 태그와 일치해야 합니다.
{
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"domain": ["full:ads.example.com"],
"outboundTag": "block"
},
{
"type": "field",
"domain": ["full:api.example.com"],
"outboundTag": "proxy"
},
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["geoip:cn"],
"outboundTag": "direct"
}
]
}
DNS와 분류: 해외 사이트가 직접 연결되는 것처럼 보이는 이유
‘해외 사이트’는 코어가 직접 식별할 수 있는 서비스 속성이 아닙니다. 도메인이 분류 목록에 포함될 수도 있고, CDN을 통해 중국 IP로 해석될 수도 있습니다. 같은 서비스에서도 로그인, 이미지, API가 서로 다른 도메인을 사용할 수 있습니다. 따라서 사이트의 기본 도메인이 프록시를 사용하더라도 모든 하위 요청이 같은 출구를 사용하는 것은 아닙니다.
AsIs: 라우팅 단계에서 현재 확인 가능한 대상 정보로 매칭하며, IP 규칙을 위해 도메인을 별도로 해석하지 않습니다. 연결 과정 전체에서 DNS 조회가 일어나지 않는다는 뜻은 아닙니다.IPIfNonMatch: 도메인이 규칙에 일치하지 않으면 해석을 시도한 뒤 확인된 IP로 다시 매칭합니다. IP 분류를 보완할 수 있지만, 중국 CDN으로 해석된 도메인이 직접 연결로 분류될 수도 있습니다.IPOnDemand: IP 정보가 필요한 규칙을 만났을 때 해석을 시작할 수 있습니다. 규칙 위치에 따라 해석 시점이 달라지므로 비교 기록 없이 임의로 변경하지 않는 것이 좋습니다.
특정 서비스를 반드시 프록시로 보내야 한다면 지역 전체의 프록시 범위를 넓히기보다 해당 도메인에 정확한 프록시 예외 규칙을 추가하세요. 브라우저가 자체 암호화 DNS를 사용하면 코어에서 확인할 수 있는 도메인 정보가 달라질 수 있습니다. 스니핑으로 일부 연결의 도메인 정보를 보완할 수 있지만 프로토콜과 암호화 방식에 따라 제한되므로 항상 성공하는 식별 방법으로 간주해서는 안 됩니다.
광고 도메인: 적은 범위부터 차단하기
광고 차단 규칙은 허용 규칙보다 앞에 두는 것이 좋지만, 먼저 확인된 개별 도메인부터 적용하세요. 일부 규칙 데이터에는 geosite:category-ads-all 분류가 포함되어 있습니다. 사용하기 전에 현재 데이터 파일에 해당 분류가 실제로 있는지 확인하세요. 분류가 없으면 광고가 덜 차단되는 데 그치지 않고 설정을 불러오지 못할 수도 있습니다.
- 먼저
full:을 사용해 광고 호스트 하나를 명확히 차단하고, 연결을 다시 시작한 뒤 페이지 표시, 로그인, 재생 기능을 확인하세요. - 이미지 CDN, 결제 API, 인증 서비스가 함께 사용하는 기본 도메인 전체를 차단하지 마세요. 같은 도메인에 필수 리소스가 있을 수 있습니다.
- 잘못 차단된 항목이 있으면 가장 최근에 추가한 규칙부터 되돌리세요. 허용 목록이 필요하다면 정확한 허용 규칙을 해당 광범위 차단 규칙보다 앞에 두세요.
- 광고와 본문이 같은 도메인을 사용하면 도메인 라우팅만으로 페이지 경로별 콘텐츠를 구분할 수 없습니다. 도메인 차단을 완전한 웹페이지 필터링 도구처럼 사용하지 마세요.
‘광고는 사라졌는데 페이지가 계속 로딩되는’ 문제가 생기면 로그에서 실패한 도메인을 확인하고 규칙을 하나씩 되돌리세요. 규칙을 한꺼번에 많이 가져온 뒤 첫 화면만 확인하면 로그인, 인증 코드, 동영상 재생 과정에서 발생한 오차단을 찾기 어렵습니다.
라우팅 확인: 로그, 출구, 되돌리기
규칙을 저장한 뒤 v2rayNG 연결을 중지했다가 다시 시작하고, 테스트 앱의 기존 연결도 종료하세요. 이미 연결된 세션은 이전 경로를 계속 사용할 수 있으며 브라우저 캐시 때문에 새 요청 없이 페이지가 정상인 것처럼 보일 수도 있습니다. 아래는 확인 절차이며, 미리 검증 결과를 단정하는 내용이 아닙니다.
| 테스트 대상 | 예상 결과 | 문제가 있을 때 확인할 항목 |
|---|---|---|
| 실제 라우터 관리 IP | LAN으로 직접 연결되고 관리 페이지에 접속 가능 | 사설 IP 규칙, Wi-Fi 격리, 실제 게이트웨이 |
| 자주 이용하는 중국 사이트 | 규칙에 따라 직접 연결 출구 사용 | 도메인 분류, IP 분류, 앞에 배치된 예외 규칙 |
| 프록시 사용을 명시한 도메인 | 로그에 프록시 아웃바운드 태그 표시 | 규칙 순서, 누락된 하위 도메인 |
| 새로 추가한 차단 도메인 | 요청 실패 또는 차단 아웃바운드 표시 | 캐시, 기존 연결, VPN 처리 범위 포함 여부 |
메인 화면 사이드 메뉴의 ‘로그’에서 새 연결을 확인하세요. 현재 로그 수준에 라우팅 정보가 표시되지 않으면 정보 수준으로 잠시 높인 뒤 문제를 다시 재현해 대상 주소와 실제 아웃바운드 태그를 확인하고, 점검이 끝나면 원래 수준으로 되돌리세요. 로그에 필요한 정보가 없으면 ‘연결 성공’만으로 어떤 규칙이 적용됐는지 추측해서는 안 됩니다. 로그를 공유하기 전에 노드 주소, 구독 링크, 개인 접속 기록을 삭제하세요.
- 변수 고정: 같은 노드, 같은 Wi-Fi, 같은 테스트 앱을 유지하고 매번 규칙 하나만 변경하세요.
- 출구 확인: IP 조회 사이트에 먼저 직접 연결 규칙을 명시하고 결과를 기록한 다음, 프록시로 바꿔 비교하세요. 한 번의 조회 결과로 확인할 수 있는 것은 해당 사이트의 그 요청 경로뿐입니다.
- 전역 프록시와 비교: 라우팅 모드에서는 사이트 접속에 실패하지만 전역 프록시에서는 성공한다면 해당 사이트의 규칙과 DNS를 우선 확인하세요. 두 모드 모두 실패하면 노드와 서버 연결 상태를 추가로 점검하세요.
- 업데이트 후 재확인: geo 데이터나 구독을 업데이트한 뒤 자주 이용하는 사이트를 다시 확인하세요. 분류가 바뀌면 라우팅에 영향을 줄 수 있으며, 구독 업데이트가 규칙 데이터베이스 업데이트를 뜻하지는 않습니다.
- 문제가 생기면 즉시 되돌리기: 시작에 실패하거나 여러 사이트에서 문제가 생기면 기존 프리셋과 사용자 지정 규칙을 복원한 뒤 하나씩 다시 추가하세요. 확인되지 않은 변경 사항을 겹쳐 적용하지 마세요.
최종 설정에는 세 가지가 명확해야 합니다. VPN 처리 대상 앱, 직접 연결 또는 프록시를 명시한 대상, 규칙에 일치하지 않을 때 사용하는 출구입니다. 안정적인 프리셋으로 대부분의 요청을 처리하고 정확한 예외 규칙을 소수만 추가하는 편이 광범위한 규칙을 계속 쌓는 것보다 관리하기 쉽습니다.