구독 그룹과 서버 필터링
구독 그룹은 v2rayN에서 여러 제공업체나 자체 구독을 관리하는 기본 수단입니다. 많은 사용자가 처음에는 구독을 하나만 추가하고 모든 노드를 한곳에 섞어 둡니다. 노드 수가 수십 개를 넘어서면 특정 지역의 노드를 찾기가 매우 어려워집니다. 구독 그룹은 이 문제를 해결합니다. 서로 다른 출처의 노드를 독립된 그룹에 넣어 그룹 간 간섭을 막고, 업데이트, 필터링, 지연 테스트를 그룹 단위로 수행합니다.
v2rayN 메인 화면에서 "구독 그룹" 메뉴를 열고 "구독 그룹 설정"으로 들어갑니다. 여기서 새 그룹을 만들고 이름을 지정할 수 있습니다. 예를 들어 "주력 제공업체", "예비 자체 구축", "업무 전용" 등이 있습니다. 각 그룹에는 하나 이상의 구독 주소를 바인딩할 수 있습니다. 바인딩이 완료되면 v2rayN은 해당 구독에서 가져온 노드를 이 그룹에 귀속시키고, 메인 화면의 서버 목록은 그룹별로 트리 구조로 표시됩니다. 특정 그룹을 펼치면 해당 그룹의 모든 노드를 볼 수 있습니다.
그룹의 또 다른 실용적인 기능은 독립적인 자동 업데이트 간격입니다. 구독 그룹 설정에서 각 그룹에 업데이트 간격을 따로 설정할 수 있습니다. 예를 들어 주력 제공업체는 12시간마다, 예비 자체 구축은 24시간마다 업데이트하도록 설정할 수 있습니다. v2rayN은 이 간격에 따라 백그라운드에서 자동으로 구독을 가져오므로 수동으로 새로고침을 클릭할 필요가 없습니다. 이렇게 하면 특정 구독이 일시적으로 실패해도 다른 그룹의 정상적인 업데이트에는 영향을 주지 않습니다.
서버 필터링은 구독 그룹의 자연스러운 확장입니다. 노드 수가 많을 때 서버 목록 위의 필터 상자에서 프로토콜 유형(VMess / VLESS / Trojan / Shadowsocks)별로 필터링하거나 지연, 지역, 그룹별로 정렬할 수 있습니다. 필터링된 보기에서 한 번에 모두 선택한 다음 일괄적으로 지연 테스트를 수행할 수 있습니다. 지연 테스트 시 "설정 - 매개변수 설정"에서 테스트 URL을 평소에 자주 방문하는 주소로 변경하는 것이 좋습니다. 예를 들어 자주 사용하는 웹페이지나 생성형 204 페이지로 바꾸면 측정된 지연이 실제 사용 경험에 더 가까워집니다. 일부 노드는 기본 테스트 URL에 대해 특별한 처리를 하므로 다른 대상 주소로 바꾸면 오판을 피할 수 있습니다.
구독 그룹과 서버 필터링을 결합하면 매우 실용적인 워크플로를 만들 수 있습니다. 먼저 구독 출처별로 그룹을 나누고, 그룹 내에서 프로토콜이나 지연으로 필터링한 다음, "설정"의 "서버 정렬"로 필터링 결과를 고정합니다. 일상적으로 사용할 때는 해당 그룹을 펼쳐 지연이 가장 낮은 노드를 선택하면 됩니다.
구독 그룹을 구성 파일 수준에서 이해하고 싶다면 v2rayN의 guiConfig.json에 subItem 배열이 있으며, 각 요소는 구독 항목을 나타냅니다. 다음은 구독 항목의 기본 필드를 보여주는 간단한 예시입니다.
{
"subItem": [
{
"id": "a1b2c3d4",
"remarks": "주력 제공업체",
"url": "https://example.com/subscribe?token=xxxx",
"enabled": true,
"autoUpdateInterval": 12
},
{
"id": "e5f6g7h8",
"remarks": "예비 자체 구축",
"url": "https://home.example.net/sub",
"enabled": true,
"autoUpdateInterval": 24
}
]
}url 필드는 구독 링크이고, remarks는 표시 이름이며, enabled는 해당 구독이 업데이트에 참여하는지 여부를 제어하고, autoUpdateInterval은 시간 단위의 자동 업데이트 간격입니다. 이 파일을 수동으로 편집하기 전에 v2rayN을 먼저 종료하고 편집이 끝난 후 다시 열어 GUI가 변경 사항을 덮어쓰지 않도록 하는 것이 좋습니다.
라우팅 규칙 실전
라우팅 규칙은 트래픽이 어디로 갈지 결정합니다. 직접 연결, 프록시 경유, 또는 차단입니다. 대부분의 사용자에게 기본 "중국 본토 우회" 규칙으로 충분합니다. 하지만 더 세밀한 분기가 필요하다면(예: 특정 도메인은 강제로 프록시, 특정 IP 대역은 강제로 직접 연결) 라우팅 규칙을 직접 편집해야 합니다.
라우팅 규칙은 두 가지 데이터 집합에 의존합니다. geosite는 도메인 집합이고, geoip는 IP 집합입니다. 예를 들어 geosite:cn은 중국 본토의 일반적인 도메인을 포함하고, geoip:cn은 중국 본토 IP 대역을 포함합니다. v2rayN에 내장된 규칙 템플릿은 이 두 집합을 기반으로 조합됩니다. "설정 - 라우팅 설정"에서 "전역 프록시", "로컬 네트워크 우회", "중국 본토 우회" 등의 내장 템플릿을 바로 선택할 수 있습니다.
내장 템플릿이 요구 사항을 충족하지 못하면 config.json의 routing 부분을 편집할 수 있습니다. 라우팅 규칙은 배열이며 위에서 아래로 순서대로 일치합니다. 첫 번째로 일치하는 규칙이 적용되고 이후 규칙은 실행되지 않습니다. 따라서 규칙의 배열 순서가 매우 중요합니다. 일반적으로 직접 연결 규칙을 맨 앞에 두고 프록시 규칙을 맨 뒤에 두어 폴백으로 사용합니다.
다음은 "중국 본토 직접 연결, 해외 프록시"의 전형적인 규칙 그룹입니다.
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{ "type": "field", "domain": ["geosite:cn"], "outboundTag": "direct" },
{ "type": "field", "ip": ["geoip:cn"], "outboundTag": "direct" },
{ "type": "field", "domain": ["geolocation-!cn"], "outboundTag": "proxy" }
]
}
}domainStrategy는 도메인 일치 순서를 제어합니다. 기본값은 AsIs로 도메인만 일치시킵니다. IPIfNonMatch로 변경하면 도메인이 어떤 도메인 규칙에도 일치하지 않을 때 v2ray가 해당 도메인의 IP를 먼저 해석한 다음 그 IP로 geoip 규칙을 일치시킵니다. 이렇게 하면 geosite에 등록되지 않은 도메인도 커버할 수 있지만, 첫 방문 시 DNS 해석이 한 번 더 발생하는 비용이 있습니다.
세 가지 규칙의 논리는 다음과 같습니다. 먼저 중국 본토 도메인을 일치시켜 직접 연결로 보내고, 다음으로 중국 본토 IP를 일치시켜 직접 연결로 보내며, 마지막으로 "중국 본토가 아닌 지리적 위치의 도메인"을 일치시켜 프록시로 보냅니다. 여기서 geolocation-!cn은 v2ray에 내장된 특수 도메인 집합으로, "중국을 제외한 지리적 위치가 커버하는 도메인"과 동일합니다.
규칙이 적용되지 않을 때는 다음 순서로 확인합니다. 첫째, outboundTag의 값이 존재하는지 확인합니다. v2rayN의 기본 프록시 아웃바운드 태그는 proxy이고, 직접 연결 아웃바운드는 direct입니다. 사용자 지정 아웃바운드에서 태그를 변경했다면 라우팅 규칙도 함께 수정해야 합니다. 둘째, 규칙 순서를 확인합니다. 특정 규칙이 더 광범위한 규칙 뒤에 있으면 영원히 일치하지 않을 수 있습니다. 셋째, domainStrategy를 확인합니다. 도메인이 어떤 도메인 규칙에도 일치하지 않고 IPIfNonMatch가 활성화되어 있지 않으면 해당 도메인은 geoip 일치를 거치지 않아 누락될 수 있습니다. 넷째, 도메인이 실제로 geosite에 있는지 확인합니다. 일부 흔하지 않은 도메인은 등록되어 있지 않으므로 수동으로 규칙에 추가해야 합니다. 예: "domain": ["example.com", "geosite:cn"].
라우팅 규칙과 구독 그룹을 함께 사용하면 매우 세밀한 트래픽 스케줄링을 구현할 수 있습니다. 특정 그룹의 노드를 "업무 전용"으로 지정하고 라우팅 규칙에서 업무 관련 도메인을 이 그룹의 프록시 아웃바운드로 보내는 것입니다. 이는 수동으로 노드를 전환하는 것보다 더 안정적입니다.
중국 본토/해외 분기에 대한 더 완전한 구성 예시는 이 사이트의 블로그 게시물 《v2rayN 라우팅 규칙 설정 실전: 중국 본토 직접 연결, 해외 프록시의 완전한 분기 방안》을 참조하세요.
DNS 최적화
DNS 해석은 네트워크 접근의 첫 단계입니다. 프록시 환경에서 DNS 해석 결과는 트래픽 방향에 영향을 줄 수 있습니다. DNS가 오염되면 프록시 노드가 정상이어도 "연결은 되는데 웹페이지가 열리지 않는" 상황이 발생할 수 있습니다. 따라서 DNS 최적화는 고급 설정에서 매우 중요한 부분입니다.
v2rayN의 DNS 설정은 "설정 - 매개변수 설정"에 있습니다. 화면에는 일반적으로 "원격 DNS"와 "로컬 DNS" 두 개의 입력란이 있습니다. 원격 DNS는 프록시 네트워크를 통해 해외 도메인을 해석하고, 로컬 DNS는 직접 연결 네트워크를 통해 중국 본토 도메인을 해석합니다. 일반적인 원격 DNS로는 1.1.1.1과 8.8.8.8이 있고, 일반적인 로컬 DNS로는 223.5.5.5(알리바바)와 119.29.29.29(텐센트)가 있습니다.
DNS 쿼리를 더 세밀하게 제어하고 싶다면 config.json의 dns 부분을 편집할 수 있습니다. 다음은 도메인별로 DNS 쿼리를 분기하는 예시입니다.
{
"dns": {
"servers": [
{ "address": "1.1.1.1", "domains": ["geosite:geolocation-!cn"] },
{ "address": "223.5.5.5", "domains": ["geosite:cn"] },
{ "address": "8.8.8.8" }
]
}
}이 구성의 의미는 다음과 같습니다. 중국 본토가 아닌 지리적 위치의 도메인(geosite:geolocation-!cn)은 1.1.1.1로 해석하고, 중국 본토 도메인(geosite:cn)은 223.5.5.5로 해석하며, 기타 일치하지 않는 도메인은 8.8.8.8을 폴백으로 사용합니다. 여기서 domains 필드는 선택 사항이며, 작성하지 않으면 해당 서버가 기본 폴백으로 사용됩니다.
DNS 누출 방지는 또 다른 중요한 주제입니다. 시스템 프록시가 모든 트래픽을 관리하지 않으면 일부 브라우저 확장 프로그램이나 백그라운드 앱이 프록시를 우회하여 시스템 DNS에 직접 쿼리를 보내 해석 결과가 오염될 수 있습니다. 해결 방법은 두 가지입니다. 첫째, TUN 모드(다음 장에서 소개)를 사용하여 모든 트래픽을 관리합니다. 둘째, v2rayN의 DNS 설정에서 "DNS 누출 방지" 관련 옵션을 체크하여 DNS 쿼리도 프록시 채널에 포함시킵니다.
DNS를 구성할 때 주의할 점: 원격 DNS 자체도 프록시를 거쳐야 합니다. 그렇지 않으면 원격 DNS도 오염됩니다. v2rayN은 기본적으로 원격 DNS의 트래픽을 프록시 아웃바운드로 보내며, 이는 라우팅 규칙의 DNS 분기 로직에 의존합니다. 라우팅 규칙을 수동으로 편집했다면 DNS 트래픽을 프록시로 보내는 규칙을 반드시 유지해야 합니다. 그렇지 않으면 원격 DNS가 해외 도메인을 해석하지 못할 수 있습니다.
TUN 모드
TUN 모드는 v2ray 클라이언트의 고급 기능입니다. 가상 네트워크 카드를 생성하여 시스템의 모든 네트워크 트래픽을 관리합니다. 여기에는 시스템 프록시 설정을 따르지 않는 앱, UDP 트래픽, 명령줄 도구가 포함됩니다. 일반 사용자에게 TUN 모드는 "켜면 모든 프로그램이 프록시를 사용한다"는 의미이며, 앱별로 프록시를 설정할 필요가 없습니다.
적용 시나리오는 주로 세 가지입니다. 첫째, 전역 프록시가 필요한 경우입니다. 일부 앱은 시스템 프록시만 인식하지만 시스템 프록시가 모든 것을 처리하지 못합니다. 둘째, UDP 트래픽입니다. 게임, 음성 통화 등은 시스템 프록시가 일반적으로 UDP를 전달하지 않습니다. 셋째, 명령줄 도구입니다. git, curl 등은 기본적으로 Windows 시스템 프록시 설정을 읽지 않습니다.
v2rayN에서 TUN 모드를 켜는 것은 간단합니다. "설정 - 매개변수 설정"을 열고 "TUN 모드 사용" 스위치를 체크합니다. 처음 켤 때 Windows는 UAC 사용자 계정 컨트롤 프롬프트를 표시합니다. 가상 네트워크 카드를 만들려면 관리자 권한이 필요하기 때문입니다. macOS에서는 관리자 비밀번호를 입력하거나 커널 확장을 승인해야 합니다. 켜면 v2rayN이 가상 네트워크 카드를 만들고 시스템 기본 라우팅을 이 카드로 자동으로 지정합니다.
TUN 모드와 시스템 프록시의 차이를 명확히 설명해야 합니다. 시스템 프록시는 "프록시 설정을 적극적으로 읽는" 앱에만 적용됩니다. 브라우저, 일부 다운로드 도구는 읽지만 많은 앱은 읽지 않습니다. TUN 모드는 네트워크 카드 수준에서 관리하므로 모든 트래픽이 가상 네트워크 카드를 거칩니다. 따라서 적용 범위가 더 넓습니다. 하지만 TUN 모드에는 비용도 있습니다. 성능 오버헤드가 시스템 프록시보다 약간 높습니다. 모든 트래픽이 가상 네트워크 카드를 한 번 거쳐야 하기 때문입니다. 또한 구성이 잘못되면 로컬 네트워크 접근에 영향을 줄 수 있습니다.
TUN 모드를 켠 후에도 라우팅 규칙은 계속 적용됩니다. 즉, TUN 모드에서도 분기를 계속할 수 있습니다. 중국 본토 트래픽은 직접 연결, 해외 트래픽은 프록시로 보냅니다. TUN 모드는 단지 "트래픽 진입점"을 제공할 뿐이며, 구체적인 방향은 여전히 라우팅 규칙이 결정합니다.
다음은 v2rayN의 config.json에서 TUN 부분의 예시입니다.
{
"tun": {
"enable": true,
"stack": "system",
"dns": "1.1.1.1"
}
}stack은 네트워크 스택의 구현 방식입니다. Windows에서는 system을 권장합니다. 시스템 내장 네트워크 스택을 사용하여 호환성이 가장 좋습니다. macOS에서는 gvisor를 권장합니다. 일부 커널 확장 충돌을 피할 수 있습니다. TUN 모드를 켠 후 네트워크가 불안정하면 stack 매개변수를 전환해 볼 수 있습니다. dns 필드는 TUN 모드에서 사용할 DNS 서버를 지정합니다. 여기서 1.1.1.1은 프록시를 거치는 원격 DNS이고, 223.5.5.5로 작성하면 직접 연결을 사용합니다. 이는 분기 요구 사항에 따라 달라집니다.
TUN 모드를 사용할 때 흔한 오해가 있습니다. TUN을 켠 후 DNS 구성이 잘못되면 모든 도메인 해석이 실패하여 "연결은 되는데 아무것도 열리지 않는" 상황이 발생합니다. 이때는 TUN 모드를 끄고 DNS 구성을 확인한 다음 다시 켜세요. 또한 TUN 모드는 일부 VPN 소프트웨어, 게임 가속기와 충돌할 수 있습니다. 동시에 사용하면 라우팅 테이블이 서로 덮어쓰는 현상이 발생합니다. 전역 관리 도구는 하나만 유지하는 것이 좋습니다.
TUN 모드와 다음 장에서 다룰 FakeDNS는 완벽한 조합입니다. TUN이 모든 트래픽을 관리하고 FakeDNS가 DNS 해석을 관리하며, 둘이 함께 작동하면 진정한 "누출 없는 프록시"를 구현할 수 있습니다.
FakeDNS
FakeDNS는 v2ray 코어의 DNS 모듈 기능입니다. 모든 DNS 쿼리를 가로채서 실제 DNS 서버에 요청하지 않고, 가짜 내부 IP(일반적으로 예약된 대역 내)를 직접 반환합니다. 실제 도메인 해석은 트래픽이 실제로 연결할 때로 미뤄지며, v2ray가 라우팅 규칙에 따라 프록시 또는 직접 연결을 결정합니다.
FakeDNS의 핵심 가치는 세 가지입니다. 첫째, DNS 쿼리가 외부로 누출되지 않습니다. 모든 쿼리가 로컬에서 가로채지므로 외부 네트워크는 어떤 도메인을 조회했는지 알 수 없습니다. 둘째, 도메인 해석 속도가 더 빠릅니다. DNS 서버 응답을 기다릴 필요 없이 로컬에서 가짜 IP를 직접 반환하고, 이후 연결은 v2ray의 프록시 채널이 처리합니다. 셋째, DNS 오염을 피할 수 있습니다. 실제 DNS 서버에 쿼리하지 않으므로 오염 자체가 발생할 수 없습니다.
v2rayN에서 FakeDNS를 활성화하려면 일반적으로 config.json의 dns 부분을 수동으로 편집해야 합니다. v2rayN의 GUI가 모든 FakeDNS 옵션을 노출하지 않을 수 있으므로 고급 사용자는 구성 파일을 직접 편집하는 경향이 있습니다. 다음은 FakeDNS를 활성화하는 예시입니다.
{
"dns": {
"servers": ["1.1.1.1"],
"queryStrategy": "UseIP",
"fakeDns": {
"enabled": true
}
}
}fakeDns.enabled를 true로 설정하면 v2ray가 모든 DNS 쿼리를 가로챕니다. queryStrategy는 쿼리 전략을 제어하며, UseIP는 IP 레코드만 조회하여 불필요한 AAAA 쿼리를 피합니다. 주의할 점은 FakeDNS가 실제 IP가 필요한 일부 앱과 호환되지 않는다는 것입니다. 예를 들어 P2P 다운로드 소프트웨어, 로컬 네트워크 장치 발견 등이 있습니다. 이러한 앱에 문제가 발생하면 FakeDNS 구성에서 관련 도메인을 제외하거나 FakeDNS를 끄세요.
FakeDNS와 TUN 모드를 함께 사용할 때 가장 효과적입니다. TUN 모드가 모든 트래픽을 관리하고 FakeDNS가 모든 DNS 쿼리를 관리하며, 둘이 결합되어 완전한 "투명 프록시" 환경을 형성합니다. 이 조합에서는 시스템의 어떤 앱도 별도로 프록시를 설정할 필요가 없습니다. 브라우저, 채팅 도구, 게임이 모두 자동으로 프록시를 사용하고 DNS 쿼리도 누출되지 않습니다.
하지만 FakeDNS에는 주의할 점이 하나 있습니다. 가짜 IP를 반환하기 때문에 일부 앱이 가짜 IP를 캐시하여 이후 연결이 실패할 수 있습니다. 예를 들어 앱이 도메인을 해석하여 가짜 IP를 얻은 다음 v2ray가 종료되면 앱이 가짜 IP로 연결을 시도하여 실패합니다. 따라서 구성을 전환하거나 v2ray를 종료할 때 관련 앱을 재시작하여 DNS 캐시를 지우는 것이 좋습니다.
가볍게 프록시만 사용하고 "누출 없음"을 추구하지 않는다면 FakeDNS를 사용하지 않아도 됩니다. FakeDNS는 프라이버시에 대한 요구가 있거나 DNS 오염 문제를 자주 겪는 사용자에게 더 적합합니다.
다중 구독 관리
다중 구독 관리는 v2rayN의 기본적이면서도 과소평가되기 쉬운 기능입니다. 하나의 v2rayN 인스턴스에 여러 구독 그룹을 구성할 수 있으며, 각 그룹은 독립적으로 업데이트, 활성화, 이름 지정이 가능합니다. 이는 "다중 제공업체" 및 "자체 구축 + 제공업체" 혼합 사용에 큰 편의를 제공합니다.
가장 흔한 시나리오는 "주력 제공업체 + 예비 제공업체"입니다. 주력 제공업체의 구독은 일상적인 사용을 담당하고, 예비 제공업체는 주력 노드가 모두 실패했을 때 전환합니다. 구독을 하나만 사용하면 주력 제공업체에 문제가 생겼을 때 기다릴 수밖에 없습니다. 여러 구독 그룹을 구성하면 예비 제공업체의 노드가 항상 목록에 있으므로 전환은 클릭 한 번이면 됩니다.
또 다른 시나리오는 "자체 구축 노드 + 유료 제공업체"입니다. 자체 구축 노드는 안정적이지만 수가 적고, 유료 제공업체 노드는 많지만 품질이 고르지 않습니다. 둘을 다른 그룹에 넣고 라우팅 규칙에서 자체 구축 노드를 우선하고 제공업체 노드를 폴백으로 사용할 수 있습니다. 이렇게 하면 자체 구축 노드가 일시적으로 사용 불가능해도 자동으로 제공업체 노드로 전환됩니다.
구독 그룹 설정에서 각 그룹에 "사용" 상태를 설정할 수 있습니다. 활성화되지 않은 그룹은 자동으로 업데이트되지 않지만, 이미 가져온 노드는 서버 목록에 그대로 유지됩니다. 특정 기간 동안 어떤 그룹을 사용하고 싶지 않지만 삭제하고 싶지 않다면 해당 그룹의 업데이트 스위치를 일시적으로 끌 수 있습니다.
구독 업데이트 실패는 흔한 문제입니다. 확인 순서는 다음과 같습니다. 첫째, 네트워크에서 구독 링크에 접근할 수 있는지 확인합니다. 일부 제공업체의 구독 도메인이 통신사에 의해 차단되어 프록시를 거쳐야 구독을 가져올 수 있습니다. 둘째, 구독 링크가 만료되었는지 확인합니다. 많은 제공업체의 구독 링크는 기한이 있으며 만료 후 다시 생성해야 합니다. 셋째, 사용자 지정 User-Agent가 필요한지 확인합니다. 일부 제공업체는 구독 요청의 User-Agent에 대한 요구 사항이 있으며, v2rayN은 구독 그룹 설정에서 각 구독에 대해 별도로 User-Agent를 지정할 수 있습니다. 넷째, 구독 형식이 호환되는지 확인합니다. 일부 구독은 Clash 형식이며 v2rayN에 내장된 변환기가 가져올 때 자동으로 변환합니다. 하지만 변환이 실패하면 구독 내용이 완전한지 확인해야 합니다.
구독 중복 제거도 다중 구독 관리의 실용적인 포인트입니다. 여러 구독 간에 중복 노드가 자주 나타나며, v2rayN은 노드 ID나 주소를 기준으로 중복을 제거할 수 있습니다. 구독 그룹 설정에서 "중복 제거" 관련 옵션을 체크하면 중복 노드는 하나만 유지되어 서버 목록이 한꺼번에 늘어나는 것을 방지합니다.
구독 링크의 노드가 너무 많으면 "서버 필터링" 기능과 결합하여 프로토콜, 지역, 지연별로 필터링하고 자주 사용하지 않는 노드를 숨길 수 있습니다. 이렇게 하면 다중 구독의 유연성을 유지하면서도 목록을 관리하기 어렵지 않게 만들 수 있습니다.
다중 구독 관리와 라우팅 규칙을 결합하면 더 고급스러운 사용법도 가능합니다. 예를 들어 "업무 그룹"의 노드를 기본 프록시로, "가정 그룹"의 노드를 예비로 지정한 다음 라우팅 규칙에서 도메인이나 IP별로 다른 아웃바운드를 지정할 수 있습니다. 이러한 구성은 네트워크 환경을 명확하게 계획한 사용자에게 적합합니다.
사용자 지정 아웃바운드
아웃바운드는 v2ray 클라이언트가 연결을 시작하는 대상입니다. v2rayN에는 기본적으로 두 개의 아웃바운드가 내장되어 있습니다. 하나는 "프록시"로 현재 선택된 노드를 가리키고, 다른 하나는 "직접 연결"로 freedom 프로토콜을 사용하여 어떤 프록시도 거치지 않습니다. 이 두 아웃바운드로 대부분의 사용 시나리오를 커버할 수 있습니다.
하지만 일부 고급 시나리오에서는 사용자 지정 아웃바운드가 필요합니다. 예를 들어 특정 앱은 Shadowsocks 출구로, 다른 앱은 SOCKS 출구로 보내고 싶거나, 특정 프로토콜(예: HTTP)의 트래픽을 다른 프록시로 전달하고 싶을 수 있습니다. 이는 모두 config.json의 outbounds 배열을 편집하여 구현할 수 있습니다.
다음은 Shadowsocks 아웃바운드를 추가하는 예시입니다.
{
"outbounds": [
{
"tag": "proxy",
"protocol": "shadowsocks",
"settings": {
"servers": [
{
"address": "1.2.3.4",
"port": 8388,
"method": "aes-256-gcm",
"password": "your-password"
}
]
}
},
{
"tag": "direct",
"protocol": "freedom"
}
]
}이 구성은 두 개의 아웃바운드를 정의합니다. proxy는 Shadowsocks 프로토콜을 사용하여 주소 1.2.3.4, 포트 8388의 서버에 연결합니다. direct는 freedom 프로토콜을 사용하여 직접 연결을 나타냅니다. tag 필드가 매우 중요합니다. 라우팅 규칙의 outboundTag가 이 태그를 참조하기 때문입니다. tag를 다른 이름으로 변경하면 라우팅 규칙도 함께 수정해야 합니다.
사용자 지정 아웃바운드와 라우팅 규칙의 결합이 핵심 활용법입니다. 예를 들어 라우팅 규칙에 다음과 같은 규칙을 작성할 수 있습니다.
{
"type": "field",
"domain": ["example.com"],
"outboundTag": "proxy"
}이렇게 하면 example.com에 접근하는 트래픽이 proxy 아웃바운드로 이동합니다. 여러 사용자 지정 아웃바운드가 있다면(예: Shadowsocks 아웃바운드와 HTTP 아웃바운드) 도메인별로 트래픽을 다른 출구로 분배하여 "멀티 라인" 효과를 낼 수 있습니다.
v2rayN에서 config.json을 수동으로 편집하는 것이 사용자 지정 아웃바운드를 추가할 수 있는 유일한 방법입니다. 편집 전에 v2rayN을 종료하고 원본 구성 파일을 백업한 다음 편집하는 것이 좋습니다. 편집이 끝난 후 다시 열면 구성에 문법 오류가 있을 때 v2rayN이 로드 실패를 알려줍니다. 이때 백업으로 복원하면 됩니다. 주의할 점은 v2rayN의 GUI가 다른 설정을 저장할 때 config.json을 덮어쓸 수 있다는 것입니다. 따라서 수동으로 구성을 편집했다면 v2rayN의 "자동 저장" 관련 옵션을 끄거나 편집 후 즉시 재시작하여 GUI가 덮어쓰지 않도록 하는 것이 좋습니다.
VMess와 VLESS의 프로토콜 차이 및 자신의 노드에 적합한 프로토콜을 선택하는 방법에 대해서는 이 사이트의 블로그 게시물 《VMess와 VLESS의 차이점: 두 프로토콜의 적용 시나리오를 1분 만에 이해하기》를 참조하세요.
고급 튜닝 및 문제 해결
구성이 완료된 후 연결이 불안정하거나 인터넷에 접속할 수 없는 것은 흔한 문제입니다. 이 장에서는 흔한 오류 시나리오와 튜닝 방향을 한곳에 정리하여 쉽게 찾아볼 수 있도록 합니다.
연결 불안정 시 확인 절차
첫째, 노드 지연을 확인합니다. 서버 목록에서 노드를 선택하고 마우스 오른쪽 버튼으로 "서버 실제 연결 지연 테스트"를 클릭합니다. 지연이 매우 높거나 시간 초과되면 다른 노드로 바꿔 보세요. 둘째, 로컬 포트 충돌을 확인합니다. v2rayN은 기본적으로 10808과 10809를 로컬 SOCKS/HTTP 포트로 사용합니다. 다른 프로그램이 점유하면 연결이 실패합니다. 명령 netstat -ano | findstr 10808로 점유 프로세스를 확인한 다음 "설정 - 매개변수 설정"에서 로컬 포트를 변경할 수 있습니다. 더 자세한 단계는 블로그 《10808 포트가 점유되었을 때: 충돌 프로세스 찾기 및 v2rayN 로컬 포트 변경》을 참조하세요. 셋째, 시스템 프록시 설정을 확인합니다. 시스템 프록시가 가리키는 포트와 v2rayN이 실제로 수신하는 포트가 다르면 브라우저가 연결할 수 없습니다. 넷째, 라우팅 규칙을 확인합니다. 라우팅 규칙이 모든 트래픽을 직접 연결로 보내면 프록시는 당연히 적용되지 않습니다.
시작 시 크래시 및 즉시 종료
v2rayN이 시작되자마자 종료되는 경우는 일반적으로 런타임 라이브러리 누락이나 보안 소프트웨어 차단과 관련이 있습니다. Windows에서는 .NET 런타임이 완전히 설치되었는지 먼저 확인하세요. 설치했는데도 여전히 크래시가 발생하면 보안 소프트웨어(Windows Defender, 타사 백신 등)가 v2rayN 또는 v2ray 코어 파일을 위협으로 격리했는지 확인하세요. v2rayN 설치 디렉터리를 화이트리스트에 추가하거나 시스템 드라이브가 아닌 경로에 다시 압축 해제하세요. 더 자세한 확인 절차는 블로그 《v2rayN이 열리지 않을 때: 시작 크래시와 즉시 종료의 런타임, 권한 확인 절차》를 참조하세요.
연결됐지만 인터넷에 접속할 수 없음
이것은 가장 혼란스러운 문제입니다. 클라이언트는 연결됨을 표시하지만 웹페이지가 열리지 않습니다. 다음 순서로 하나씩 확인하세요. 첫째, 노드가 실제로 사용 가능한지 확인합니다. 지연을 테스트하고 프록시가 필요 없는 중국 본토 사이트에 접속해 보세요. 접속되면 네트워크가 기본적으로 통하는 것입니다. 둘째, 시스템 시간을 확인합니다. 프록시 프로토콜은 시간 동기화에 민감하며, 시간 편차가 90초를 초과하면 연결이 거부됩니다. 셋째, DNS를 확인합니다. DNS 구성이 잘못되면 도메인 해석이 실패하여 "IP는 ping이 되는데 도메인이 열리지 않는" 상황이 발생합니다. 넷째, 시스템 프록시 설정을 확인합니다. 일부 앱은 시스템 프록시를 강제로 사용합니다. 시스템 프록시가 잘못된 포트를 가리키면 인터넷이 끊깁니다. 다섯째, 라우팅 규칙을 확인합니다. 규칙에서 접근하는 도메인을 직접 연결로 보냈는데 직접 연결 네트워크가 해당 도메인에 접근할 수 없다면 "연결은 되는데 열리지 않는" 상황이 발생합니다. 전체 확인 체크리스트는 블로그 《V2Ray 연결됐지만 인터넷에 접속할 수 없음? 노드, DNS, 시스템 프록시를 이 체크리스트로 하나씩 확인》을 참조하세요.
성능 튜닝 방향
연결은 안정적이지만 속도가 만족스럽지 않다면 다음 튜닝을 시도해 볼 수 있습니다. Mux(다중화)를 활성화합니다. Mux는 여러 TCP 연결을 하나의 연결로 다중화하여 핸드셰이크 횟수를 줄이고 지연을 낮추지만 CPU 사용량을 약간 증가시킵니다. 모바일 네트워크나 고지연 회선에서는 Mux가 일반적으로 도움이 됩니다. 전송 계층 프로토콜 선택도 중요합니다. WebSocket은 호환성이 좋지만 오버헤드가 약간 크고, gRPC는 긴 연결 시나리오에서 더 나은 성능을 보입니다. 이러한 설정은 v2rayN의 노드 구성에서 조정할 수 있습니다.
로그 확인
v2rayN의 로그 창("로그 보기")은 연결 과정의 오류 정보를 기록합니다. 연결이 실패하면 로그에 일반적으로 명확한 오류 원인이 표시됩니다. 예: "connection refused", "timeout", "certificate verify failed" 등. 로그를 읽는 법을 배우면 문제 해결 시간을 크게 줄일 수 있습니다. 로그 수준은 "설정 - 매개변수 설정"에서 조정할 수 있으며, "디버그"로 설정하면 더 자세한 정보를 볼 수 있습니다. 문제 해결 후에는 "정보" 또는 "경고"로 되돌려 로그 파일이 너무 커지는 것을 방지하세요.
위의 튜닝 및 문제 해결 방법은 v2rayN 데스크톱 버전과 v2rayNG 안드로이드 버전에 모두 적용됩니다. 안드로이드에서 문제가 발생하면 구독이 업데이트되었는지, 노드가 사용 가능한지, 시스템 절전 정책에 의해 제한되는지 우선적으로 확인하세요.
기본 조작에 아직 익숙하지 않다면 빠른 시작 튜토리얼로 돌아가 구독 가져오기와 노드 선택 과정을 먼저 진행한 후 이 페이지의 각 장을 읽는 것이 좋습니다. 이 페이지의 각 장은 독립적인 주제이므로 필요에 따라 참조할 수 있습니다.