이 페이지는 설정을 체계적으로 찾아볼 수 있도록 정리한 자료이며, 첫 연결 절차를 대신하지 않습니다. 아직 설치, 가져오기, 연결 확인을 마치지 않았다면 먼저 입문 가이드에 따라 기본 설정으로 연결한 다음 해당 장을 확인하세요. 설치 파일과 아키텍처 선택은 클라이언트 다운로드 페이지에서 확인할 수 있습니다. 클라이언트 인터페이스는 업데이트될 수 있으므로 이 문서에서는 코어 매개변수의 원래 이름을 유지합니다. 메뉴 위치는 실제 인터페이스를 따르며, 코어가 다른 설정을 그대로 섞어 사용하면 안 됩니다.
구독 그룹과 서버 필터
구독 주소, 서버 항목, 활성 설정 구분하기
구독 그룹에는 설정 출처와 업데이트 옵션이 저장되고, 서버 항목에는 실제 연결 매개변수가 저장됩니다. 활성 설정은 현재 코어를 시작할 때 사용하는 항목입니다. 이 셋은 서로 다른 객체입니다. 목록에서 그룹을 바꾸면 보이는 항목만 달라지는 경우가 많으며, 현재 사용 중인 서버까지 바뀌는 것은 아닙니다. 목록에서 항목을 선택해도 활성 서버로 설정되지 않을 수 있습니다. 변경 후에는 클라이언트에 표시된 현재 서버를 확인하고 연결을 끊었다가 다시 연결해 새 설정을 검증하세요.
처음 정리할 때는 ‘주 구독’, ‘예비 구독’, ‘수동 설정’처럼 출처별로 그룹을 만드세요. v2rayN의 구독 그룹 설정이나 v2rayNG의 구독 설정에 메모와 구독 주소를 입력한 다음 해당 그룹을 업데이트합니다. 공유 링크에는 하나 또는 여러 개의 연결 매개변수만 포함되며, 자동 업데이트 기능은 제공되지 않습니다. 가져오기 방식의 차이는 공유 링크와 구독 주소 안내를 참고하세요. 단일 서버 링크를 구독 주소 입력란에 넣지 마세요.
메모로 필터링하고 프로토콜 항목은 수정하지 않기
서버 필터는 우선 목록에 적용되며 네트워크 라우팅과는 다릅니다. ‘예비’를 검색해도 표시되는 항목만 줄어들 뿐, 특정 웹사이트가 예비 서버를 사용하도록 바뀌지는 않습니다. 먼저 일반 키워드로 검색 범위를 확인하세요. 인터페이스에서 정규식을 지원한다고 명시한 경우에만 정규식을 사용합니다. 예를 들어 ^(办公|备用)-은 메모가 지정한 접두사로 시작한다는 뜻입니다. 모든 검색창에서 이 표현을 사용할 수 있다고 가정하면 안 됩니다. 포함 및 제외 필터를 함께 사용할 수 있는지도 실제 목록에서 확인해 사용 가능한 항목이 모두 숨겨지지 않도록 하세요.
필터 기준으로는 일시적인 지연 시간이나 자주 바뀌는 정렬 순서보다 안정적인 메모 접두사를 사용하는 편이 좋습니다. 구독을 업데이트하면 메모, 순서, 항목 수가 바뀔 수 있으며, 이름이 같아도 주소, 포트, 전송 설정이 다를 수 있습니다. 중복 여부는 이름만 보지 말고 서버 주소, 프로토콜, 포트, 전송 매개변수를 비교해 판단하세요. 사용자 이름, 식별자, 키는 민감한 연결 정보이므로 스크린샷이나 로그를 공유하기 전에 가리고, 구독 주소에 포함된 액세스 토큰도 함께 처리해야 합니다.
| 작업 | 변경되는 항목 | 확인할 사항 |
|---|---|---|
| 구독 그룹 전환 | 목록에 표시되는 범위 | 활성 서버가 기존 항목인지 여부 |
| 구독 업데이트 | 그룹 내 서버 설정 | 수동 변경 사항이 덮어쓰이는지 여부 |
| 메모 필터링 | 표시되는 서버 목록 | 필터 입력란의 정규식 지원 여부 |
| 활성 서버로 설정 | 다음 연결에 사용할 설정 | 코어가 다시 로드되었는지 여부 |
업데이트 실패 시 기존 항목을 먼저 보존하기
구독을 업데이트하기 전에 기존 항목을 삭제하고 새 항목을 가져오는 방식인지 확인하세요. 항목 보존 정책은 클라이언트와 업데이트 방식에 따라 다르므로 검증되지 않은 동작에 의존하면 안 됩니다. 중요한 수동 항목은 별도로 내보내 백업하고, 업데이트 시 다시 생성될 그룹에 넣지 마세요. 업데이트 후 목록이 비었다면 응답 내용이 클라이언트에서 지원하는 구독 형식인지, 주소가 만료되지 않았는지, 로그인 페이지가 반환되지 않았는지, 요청을 보낸 네트워크를 사용할 수 있는지 확인하세요.
‘현재 프록시를 사용할 수 없어 현재 프록시를 통해 구독을 업데이트할 수 없습니다’라는 순환 오류가 발생하면 구독을 가져오는 경로와 서버 연결 경로를 구분하세요. 제공처의 정책이 허용되고 로컬 네트워크에서 접근할 수 있는 경우에만 프록시를 거치지 않는 업데이트 방식을 사용하세요. 원래 상태를 잃을 수 있으니 전역 설정을 반복해서 바꾸지 마세요. 도메인 해석, 연결 수립, 콘텐츠 해석 중 어느 단계에서 실패했는지 기록한 다음 기존 설정을 복구하고 하나씩 다시 시도하세요. 업데이트 성공은 설정을 가져왔다는 뜻일 뿐, 모든 항목의 연결을 보장하지는 않습니다.
마지막으로 반복 가능한 점검 절차를 마련하세요. 그룹 이름을 확인하고 필터 조건을 지운 뒤, 업데이트 전후의 주소와 주요 매개변수를 비교하고 활성 서버를 직접 선택합니다. 일괄 테스트를 하기 전에 실제 웹페이지에 접속해 보세요. 테스트는 연결과 트래픽을 발생시키며, 짧은 간격으로 대량 실행하면 서버 측 제한에 걸릴 수 있습니다. 정렬 순서에 의존하기보다 검증된 예비 설정을 몇 개 보관해 두는 편이 장애 복구에 유리합니다.
라우팅 규칙 실전: 먼저 매칭한 뒤 아웃바운드 선택
규칙 순서와 기본 아웃바운드 확인
Xray 라우팅 규칙은 일반적으로 위에서 아래로 확인하며, 조건에 맞으면 지정된 아웃바운드로 요청을 전달합니다. 목록을 깔끔하게 정리하는 것보다 규칙 순서가 중요합니다. 정확한 도메인, 특정 앱 진입점, 특수 대상은 범위가 넓은 지역 규칙보다 앞에 배치하세요. 수정 전에는 기존 아웃바운드 태그를 확인하고 direct, proxy, block이 실제로 정의되어 있는지 점검하세요. 태그는 대소문자를 구분하는 참조 이름이지 고정 예약어가 아닙니다. 존재하지 않는 태그를 입력해도 해당 연결이 자동으로 생성되지는 않습니다.
일반적으로 한 규칙에서 서로 다른 조건 필드를 지정하면 모든 조건을 충족해야 합니다. 같은 필드에 값을 여러 개 지정하면 그중 하나만 일치해도 됩니다. 예를 들어 domain과 port를 함께 지정하면 도메인 조건과 포트 조건을 모두 충족해야 하며, 둘 중 하나만 맞으면 되는 것이 아닙니다. ‘도메인은 프록시로 보내고, 별도의 포트 묶음도 프록시로 보낸다’면 규칙을 두 개로 나누는 편이 명확합니다. 규칙이 길수록 조건을 한 문장으로 설명할 수 있는지 먼저 확인한 다음 설정에 옮기세요.
정확한 도메인 규칙 하나부터 시작하기
다음은 Xray의 routing 일부 설정이며, 구성에 proxy와 direct 아웃바운드가 이미 있다고 가정합니다. 예시는 문서용 테스트 도메인을 먼저 프록시로 보내고, 그다음 국내 도메인과 사설 주소를 처리합니다. full:은 도메인 전체가 정확히 일치할 때만 매칭하고, domain:은 해당 도메인과 하위 도메인을 매칭합니다. 예시 도메인은 문법 설명용입니다. 실제 설정에는 사용할 대상을 입력하고, 서비스 연결 여부를 확인하는 용도로 사용하지 마세요.
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"domain": ["full:example.com"],
"outboundTag": "proxy"
},
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["geoip:private", "geoip:cn"],
"outboundTag": "direct"
}
]
}
}geosite와 geoip는 규칙 데이터 참조이며, 온라인에서 실시간으로 조회하지 않습니다. 해당 파일이 없거나 분류 이름을 지원하지 않거나 데이터가 오래된 경우 로드에 실패하거나 예상과 다르게 매칭될 수 있습니다. 클라이언트 업데이트와 규칙 데이터 업데이트는 별개의 작업입니다. 오류가 발생하면 먼저 full: 규칙 하나로 라우팅의 기본 구조를 확인한 다음 데이터 집합 참조를 다시 추가하세요. 코어, 데이터 파일, 전체 규칙을 한꺼번에 바꾸지 마세요.
domainStrategy의 해석 시점 이해하기
AsIs는 라우팅 판단을 위해 대상 도메인을 추가로 해석하지 않으므로 도메인 규칙을 주로 사용하는 경우에 적합합니다. IPIfNonMatch는 도메인 형태로 규칙에 매칭되지 않을 때 해석을 시도하고, 얻은 주소로 다시 판단합니다. IPOnDemand는 매칭 과정에서 IP 주소가 필요한 규칙을 만나면 해석을 시도할 수 있습니다. 이 옵션들은 라우팅 단계의 동작을 제어하며, 최종적으로 사용할 DNS 서버를 직접 결정하지 않습니다. 아웃바운드 연결 단계의 주소 선택 정책과도 다릅니다.
앱이 클라이언트에 IP 주소를 직접 전달하면 도메인 규칙에 매칭할 입력이 없을 수 있습니다. 트래픽 스니핑은 일부 HTTP 또는 TLS 요청에서 도메인 단서를 찾을 수 있지만 모든 프로토콜의 원래 도메인을 복원하지는 못합니다. 암호화 핸드셰이크, 앱 캐시, IP 주소만 사용하는 요청도 결과에 영향을 줍니다. 문제를 해결할 때는 먼저 진입점에 도메인과 IP 중 무엇이 전달되는지 확인한 뒤 도메인 규칙, 주소 규칙 또는 진입점별 분할 중 적절한 방법을 선택하세요. 규칙 이름이 맞다는 이유만으로 반드시 매칭된다고 단정하지 마세요.
검증할 때는 앱의 기존 연결을 정리한 뒤 대상이 분명한 요청을 새로 보내고, 접속 로그에서 대상과 아웃바운드 태그를 확인하세요. 브라우저가 연결을 재사용하면 규칙을 바꿔도 적용되지 않은 것처럼 보일 수 있습니다. 코어를 재시작해도 브라우저 자체 캐시가 지워지는 것은 아닙니다. 로그를 켠 뒤 기록이 너무 많이 쌓이면 테스트 범위를 좁히고 상세 출력을 바로 끄세요. 새 규칙은 한 번에 하나씩 검증하고, 매칭을 확인한 다음 도메인 집합으로 확장해야 순서, 해석, 태그 참조 중 무엇이 문제인지 파악할 수 있습니다.
DNS 설정 최적화: 해석 경로와 연결 경로를 따로 확인하기
서로 다른 계층의 DNS 요청 구분하기
요청 하나에 시스템 DNS, 앱 자체 해석기, 내장 DNS, 프록시 서버 측 해석이 관여할 수 있습니다. 코어의 dns.servers를 설정해도 모든 앱이 해당 설정을 사용한다는 뜻은 아닙니다. 시스템 프록시는 프록시 설정을 따르는 요청에 주로 영향을 줍니다. 브라우저에서 자체 암호화 DNS를 사용하면 별도의 경로로 해석할 수도 있습니다. 먼저 도메인이 어느 단계에서 IP 주소로 바뀌는지 확인한 다음 사용할 해석기를 정하세요. 현재 요청에 관여하지 않는 계층만 수정하는 실수를 피할 수 있습니다.
대상 웹사이트의 도메인과 프록시 서버의 도메인도 구분해야 합니다. 프록시 연결을 수립하려면 먼저 서버 자체의 도메인을 사용할 수 있는 주소로 해석해야 합니다. 아직 연결되지 않은 동일한 연결에 이 단계를 의존할 수는 없습니다. 서버 주소가 도메인이라면 대상 도메인의 분할 해석을 설정하기 전에 시작 단계의 DNS 경로가 작동하는지 확인하세요. 모든 DNS 요청을 무조건 프록시로 보내면 시작 단계에서 의존성 순환이 생길 수 있습니다. 코어는 정상적으로 시작되지만 첫 연결을 수립하지 못하는 현상이 나타날 수 있습니다.
특정 도메인에 적용되는 해석기 설정 사용하기
아래 Xray 설정 일부는 geosite:cn에 해당하는 도메인을 우선 국내 해석기로 보내고 일반 해석기도 유지합니다. expectIPs는 반환된 주소가 예상 범위에 해당하는지 확인하지만, 웹사이트의 신원을 검증하거나 최적 경로의 주소임을 보장하지는 않습니다. 이 설정에는 해당 규칙 데이터가 필요합니다. 로컬 네트워크에서 이 DNS 주소에 접근할 수 있는지 확인해야 예시를 테스트할 수 있습니다. DNS 요청 자체가 어떤 아웃바운드로 나가는지는 실제 코어와 라우팅 설정을 함께 확인하세요.
{
"dns": {
"queryStrategy": "UseIP",
"servers": [
{
"address": "223.5.5.5",
"domains": ["geosite:cn"],
"expectIPs": ["geoip:cn"]
},
"1.1.1.1"
]
}
}도메인 우선 매칭, 예상 주소 필터링, 대체 조회가 함께 결과에 영향을 줍니다. 서버 배열을 ‘첫 번째 서버가 실패하면 두 번째 서버 사용’이라고 단순하게 해석하면 안 됩니다. 해석기를 추가하기 전에 현재 코어가 대체 정책 필드를 지원하는지 확인하고 로그로 실제 조회 동작을 살펴보세요. 이미 한 해석기가 안정적으로 응답한다면 여러 개를 추가해도 대기 시간과 불확실성만 커질 수 있습니다. 특정 도메인에 단일 경로를 적용해야 한다면 배열 순서에 기대지 말고 매칭 범위와 대체 동작을 별도로 설정하세요.
일반 DNS, DoH, 주소 계열 정책 선택하기
일반 DNS는 보통 지정된 포트에서 UDP 또는 TCP를 사용합니다. DoH는 HTTPS로 DNS 요청을 전달해 해석기까지의 전송을 보호하지만, 프록시를 대체하거나 잘못된 라우팅을 자동으로 해결하지는 않습니다. DoH 주소가 도메인이라면 시작 단계에서의 해석도 고려해야 합니다. 현재 코어가 해당 주소 형식을 지원하고, 네트워크에서 엔드포인트에 접근할 수 있으며, 인증서 검증이 정상적으로 작동할 때만 사용하세요. 오류를 없애려고 인증서 검증을 끄지 마세요. 연결의 보안 범위가 달라집니다.
UseIP는 설정에 따라 두 주소 계열을 모두 조회하고, UseIPv4와 UseIPv6는 조회 방향을 제한합니다. IPv4로 제한하면 IPv6 경로와 관련된 문제인지 확인하는 데 도움이 될 수 있지만, 모든 네트워크에 적용할 영구 해결책은 아닙니다. 시스템은 IPv6 주소를 제공하지만 TUN이 IPv4만 처리한다면 앱이 처리되지 않는 경로를 먼저 시도할 수 있습니다. 해석 결과, 시스템 라우팅, 아웃바운드 기능을 함께 점검하고 해석기 주소만 바꾸지 마세요.
‘연결은 되는데 일부 도메인이 열리지 않는’ 문제를 진단할 때는 같은 도메인의 시스템 해석 결과와 코어 로그 결과를 각각 기록한 뒤 예상한 도메인 규칙에 매칭됐는지 확인하세요. 시스템 조회 도구가 보여주는 것은 그 도구가 사용한 해석 경로뿐이며 프록시 요청 내부의 결과를 나타내지는 않습니다. 다음으로 테스트 앱을 재시작하고 DNS 캐시를 지우거나 기록이 만료될 때까지 기다린 뒤 새 연결을 시도하세요. 클라이언트 목록만 새로고침해도 모든 계층의 캐시가 지워지는 것은 아니므로 기존 주소가 한동안 계속 사용될 수 있습니다.
접근 가능한 해석기 하나만 사용하는 기준 설정을 저장해 두세요. 도메인 분할을 추가한 뒤에는 일반 도메인, 지정된 도메인 집합, 재시작 후 첫 연결 순서로 테스트합니다. 콜드 스타트 때만 실패한다면 시작 단계의 DNS 의존성을 먼저 확인하세요. 장시간 실행한 뒤에만 실패한다면 캐시, 네트워크 전환, 해석기 접근성을 살펴보세요. 이렇게 계층별로 테스트하면 DoH, FakeDNS, 복잡한 대체 규칙을 한꺼번에 켜는 것보다 원인을 분명하게 파악할 수 있습니다.
TUN 모드: 트래픽 처리 범위와 시스템 라우팅 확인하기
시스템 프록시, 가상 네트워크 인터페이스, Android VPN 구분하기
시스템 프록시는 앱에 프록시 주소를 제공하며, 해당 설정을 따르는 프로그램만 사용합니다. TUN은 가상 네트워크 인터페이스로 시스템의 IP 트래픽을 받아 적절한 구성 요소가 프록시 요청으로 변환합니다. 두 방식은 작동 계층이 다릅니다. TUN을 켜도 서버 프로토콜이 바뀌는 것은 아니며 모든 프로그램의 트래픽이 처리되는 것도 아닙니다. 데스크톱에서는 우선 v2rayN 인터페이스의 TUN 옵션을 사용하세요. 실제 처리 구성 요소와 설정 형식은 현재 클라이언트가 생성한 결과를 기준으로 확인해야 합니다.
Android용 v2rayNG는 일반적으로 시스템 VPN 서비스를 통해 앱 트래픽을 받습니다. 권한 안내와 데스크톱 가상 네트워크 인터페이스의 설치 과정은 다릅니다. 데스크톱 TUN 설정 파일을 Android 클라이언트에 그대로 가져오지 마세요. v2flyNG는 다른 코어 방식을 사용하므로 v2rayNG 메뉴만 보고 기능을 추측할 수 없습니다. 클라이언트를 선택한 뒤 먼저 일반 연결이 되는지 확인하고 시스템 트래픽 처리를 별도로 켜야 서버 매개변수 문제와 기기 내 트래픽 진입 문제를 구분할 수 있습니다.
활성화 전에 라우팅 충돌 해결하기
활성화 전에는 기본 경로를 처리 중인 다른 네트워크 도구를 끄고 기존 VPN, 가상 머신 네트워크 인터페이스, 기업 네트워크 설정을 기록하세요. 여러 구성 요소가 기본 경로, DNS, 방화벽을 동시에 수정하면 실행 순서에 따라 증상이 달라질 수 있습니다. 데스크톱 시스템에서 권한 상승을 요구하면 클라이언트 안내를 따르세요. 오류를 피하려고 여러 인스턴스를 반복해서 실행하면 안 됩니다. 가상 인터페이스 생성에 실패했다면 구독을 수정하거나 프로토콜을 바꾸기 전에 권한과 드라이버 로그부터 확인하세요.
프록시 서버로 향하는 연결이 다시 가상 인터페이스에 들어가지 않는지도 확인하세요. TUN이 대부분의 트래픽을 처리할 때는 하위 프록시 연결이 올바른 우회 경로를 사용해야 하며, 일반적으로 클라이언트가 이를 처리합니다. 시스템 경로를 수동으로 추가하거나 네트워크 인터페이스 바인딩을 변경하면 이 예외 경로가 깨져 트래픽 루프가 발생할 수 있습니다. TUN을 켜자 모든 연결이 끊기고 끄면 바로 복구되는 경우가 흔합니다. 먼저 자동 인터페이스와 기본 경로 설정을 복구한 다음 사용자 지정 항목을 하나씩 다시 적용하세요.
| 방식 | 주요 진입 경로 | 우선 확인할 항목 |
|---|---|---|
| 시스템 프록시 | 앱이 시스템 프록시 설정을 따름 | 앱의 지원 여부, 주소와 포트의 정확성 |
| 데스크톱 TUN | 시스템 경로가 가상 인터페이스로 전달됨 | 인터페이스 권한, 라우팅, DNS, 연결 우회 경로 |
| Android VPN 서비스 | 시스템에서 권한을 부여한 앱 트래픽 | VPN 권한, 앱별 목록, 백그라운드 실행 |
TCP, UDP, 로컬 네트워크를 각각 테스트하기
웹페이지가 열린다는 사실은 일부 경로가 정상이라는 뜻일 뿐, UDP, 실시간 음성·영상, 로컬 네트워크 접근까지 정상임을 의미하지는 않습니다. TUN이 UDP를 받아도 이후 아웃바운드 프로토콜, 서버, 대상 네트워크가 모두 지원해야 합니다. 테스트에 실패하면 먼저 요청이 클라이언트에 들어왔는지 확인하고, 그다음 아웃바운드가 해당 네트워크 유형을 지원하는지 확인하세요. 문제를 숨기려고 UDP를 모두 차단하지 마세요. 앱이 다른 전송 방식으로 전환될 수도 있고 일부 기능이 완전히 작동하지 않을 수도 있습니다.
로컬 네트워크 기기에 접근하려면 사설 주소 라우팅, 방화벽, 이름 해석도 확인해야 합니다. 로컬 네트워크 우회 규칙은 일반적으로 연결 경로만 처리할 뿐 프린터 검색이나 멀티캐스트 브로드캐스트까지 해결하지는 않습니다. 먼저 기기의 실제 사설 주소로 기본 연결을 확인한 다음 검색 프로토콜이 트래픽 처리의 영향을 받는지 살펴보세요. 로컬 네트워크에서 들어오는 연결을 허용하는 설정은 기기에서 프록시 포트를 여는 별도의 기능입니다. 기기에서 로컬 네트워크 기기에 접근하는 문제를 해결하려고 이 기능을 함부로 켜지 마세요.
Android에서 앱별 프록시를 사용할 때는 ‘선택한 앱만 프록시 사용’과 ‘선택한 앱 우회’ 중 어느 모드인지 명확히 설정하세요. 같은 앱 목록이어도 모드가 반대면 결과가 완전히 달라집니다. 앱 업데이트나 재설치, 업무 프로필 환경에 따라 표시되는 앱 범위가 바뀔 수 있습니다. 목록을 수정한 뒤 VPN 연결을 다시 수립하고 테스트하세요. 일부 시스템은 백그라운드 프로세스를 추가로 제한합니다. 화면을 잠근 뒤 연결이 끊긴다면 라우팅 규칙 탓으로 돌리기 전에 시스템 배터리 및 백그라운드 실행 설정을 확인하세요.
안정성 검증에는 켜기, 끄기, 네트워크 전환, 절전 모드에서 복귀하는 상황이 포함되어야 합니다. 클라이언트를 사용할 때 시스템 DNS와 기본 경로가 올바르게 복구되는지 매번 확인해 접근할 수 없는 DNS 주소가 남지 않도록 하세요. 클라이언트를 종료한 뒤에도 시스템에서 인터넷에 연결되지 않는다면 시스템 프록시와 자동 DNS를 복구한 다음 가상 인터페이스 설정이 남아 있는지 살펴보세요. 트래픽 처리 전후의 변화를 기록하면 기기 네트워크 상태 문제와 원격 연결 문제를 구분하고 검증된 일반 프록시 모드로 되돌리기도 쉽습니다.
FakeDNS: 가상 주소에 연결하는 대신 도메인 매핑 관리하기
가상 주소의 용도 이해하기
FakeDNS는 조회한 도메인에 가상 IP를 할당하고 코어에 도메인과 주소의 매핑을 저장합니다. 앱이 나중에 해당 주소로 연결하면 프록시 구성 요소가 매핑에서 도메인을 찾아 라우팅과 아웃바운드 처리를 수행합니다. 가상 주소는 대상 서버의 실제 주소가 아니며 임의의 네트워크에서 직접 접근할 수 있는 주소도 아닙니다. DNS 해석과 연결이 서로 연동되는 처리 경로를 거쳐야 이후 연결에 IP만 포함되어 있어도 도메인 정보를 복원할 수 있습니다.
따라서 DNS 설정에 fakedns만 입력해서는 완전한 구성이 되지 않습니다. 클라이언트가 관련 DNS 조회를 FakeDNS에 전달하고, 가상 주소 범위의 연결을 처리하며, 진입점에서 매핑을 복원할 수 있어야 합니다. 시스템 프록시 환경에서 앱이 자체적으로 해석한 뒤 프록시를 우회해 연결하면 외부 네트워크에서 라우팅할 수 없는 주소를 받을 수 있습니다. 먼저 트래픽 처리 범위를 정한 다음 FakeDNS를 활성화하세요. 올바르게 설정되지 않은 시스템 라우팅을 대신하는 용도로 사용하면 안 됩니다.
주소 풀과 스니핑 기능부터 확인하기
다음은 Xray의 DNS와 주소 풀 설정 일부를 보여 주는 예시이며 TUN 트래픽 처리 설정은 포함하지 않습니다. 198.18.0.0/15는 벤치마크 테스트용 특수 주소 범위로, 가상 주소 풀로 자주 사용됩니다. 실제 대상 웹사이트의 네트워크 대역은 아닙니다. 기존 기업 네트워크나 다른 트래픽 처리 도구도 이 범위를 사용할 수 있으므로 충돌이 생겼을 때 주소 풀만 확대해서는 안 되며 전체 사용 범위를 조정해야 합니다. 진입점 설정은 해당 트래픽을 실제로 받는 인바운드에 합쳐야 합니다. 사용되지 않는 인바운드를 새로 만들어 대신 사용할 수는 없습니다.
{
"dns": {
"servers": ["fakedns"]
},
"fakedns": [
{
"ipPool": "198.18.0.0/15",
"poolSize": 65535
}
]
}실제 트래픽을 처리하는 Xray 인바운드에는 다음과 같은 형태로 스니핑을 설정할 수 있습니다. destOverride의 fakedns는 관련 도메인을 복원하는 데 사용하고, routeOnly는 스니핑 결과를 라우팅에 사용하는 방식을 제한합니다. 해당 옵션을 클라이언트가 자동 생성하는지 현재 코어와 생성된 파일에서 반드시 확인하세요. 클라이언트의 TUN 경로를 다른 구성 요소가 처리한다면 이 Xray 인바운드 설정을 일반적인 TUN 설정 문법으로 간주하면 안 됩니다.
{
"sniffing": {
"enabled": true,
"destOverride": ["http", "tls", "fakedns"],
"routeOnly": true
}
}캐시와 매핑 수명 관리하기
매핑 수명은 문제 해결의 핵심입니다. 앱이 가상 주소를 캐시한 뒤 코어를 재시작하면 원래 매핑이 저장되지 않아 이전 연결에 가상 IP만 남고 실제 도메인을 복원하지 못할 수 있습니다. 처음에는 정상이다가 클라이언트 재시작 후 일부 앱이 실패하는 현상이 나타날 수 있습니다. 먼저 앱의 기존 연결을 종료하고 관련 DNS 캐시를 지운 다음 다시 조회하고 연결하세요. 가상 주소를 장기간 사용하는 서버 주소로 저장하거나 다른 기기에 복사해 테스트하지 마세요.
주소 풀 용량은 관리할 수 있는 매핑 규모를 제한하며 동시 연결 수나 성능 점수가 아닙니다. 장시간 동안 많은 도메인에 접속하면 매핑 교체와 앱 캐시가 함께 문제를 일으킬 수 있습니다. 용량만 무작정 늘려도 처리되지 않는 연결은 해결되지 않습니다. 먼저 좁은 범위에서 조회가 FakeDNS에 도달하고 연결이 같은 처리 경로로 돌아오는지 검증한 다음 안정성을 확인하세요. 기본 동작이 확인된 후 코어 설명서와 기기 자원을 바탕으로 용량 조정이 필요한지 판단하세요.
일부 앱은 해석 결과를 검사하거나 하드코딩된 주소를 사용하고 자체 암호화 DNS 조회를 수행할 수 있어 예상한 매핑 경로를 우회할 수 있습니다. 특정 앱 하나만 호환되지 않는다면 먼저 실제 DNS를 복구하고 나머지 라우팅 설정은 유지한 채 결과를 비교하세요. FakeDNS를 끄자 복구되었다면 구독을 바로 바꾸기보다 매핑 경로를 확인해야 합니다. 일부 도메인에 실제 DNS 해석을 사용하려면 이후 라우팅이 실제 주소를 처리할 수 있는지도 확인해 두 방식의 판단이 충돌하지 않게 하세요.
검증할 때는 최초 조회, 앱 재시작, 코어 재시작, 네트워크 전환을 모두 테스트하세요. 로그에 도메인으로 복원되지 않은 가상 대상 주소가 계속 표시되면 매핑이 존재하는지와 인바운드가 올바른지 먼저 확인하세요. 가상 주소에 직결 규칙을 추가하지 마세요. 가상 주소를 외부 네트워크로 바로 보내면 대개 대상에 접근할 수 없습니다. 올바른 해결 방향은 도메인 매핑과 트래픽 처리 경로의 연결을 복구하는 것이지 직결 범위를 넓히는 것이 아닙니다.
다중 구독 관리: 출처와 업데이트 정책 분리하기
목록 하나에 합치지 말고 출처별 목록 만들기
다중 구독에서 중요한 것은 가져오기 개수가 아니라 설정 출처, 업데이트 결과, 활성 서버 사이의 관계입니다. 출처마다 별도 그룹을 만들고 용도, 가져오는 방식, 자동 업데이트 허용 여부를 기록하세요. 바뀌기 쉬운 서버 이름에 의존하지 말고 실제 용도를 메모로 남기세요. 수동 관리가 필요한 특수 설정은 구독 업데이트로 대체되지 않도록 별도 그룹에 보관하세요. 두 출처를 비교해야 한다면 각 그룹에서 먼저 테스트한 뒤 어떤 출처를 주로 사용할지 결정하세요.
구독은 주소, 포트, 프로토콜, 전송 매개변수를 제공할 수 있지만 클라이언트의 모든 라우팅, DNS, 트래픽 처리 설정까지 제어한다고 가정하면 안 됩니다. 구독 형식마다 적용 범위가 다르며 서버 목록만 제공하는 경우도 있습니다. 가져온 뒤에는 실제로 무엇이 바뀌었는지, 특히 코어 선택과 전송 필드를 확인하세요. 출처의 설정을 다른 형식으로 변환하면 원래 형식의 일부 기능이 손실될 수 있습니다. 설정을 정상적으로 해석했는데 연결에 실패한다면 원래 매개변수가 모두 유지되었는지 살펴보세요.
같은 이름, 중복 제거, 업데이트 덮어쓰기에서 생기는 혼란 방지하기
출처가 다른 두 항목의 이름이 모두 ‘예비 회선’이어도 같은 서버에 연결된다는 뜻은 아닙니다. 반대로 이름이 달라도 같은 주소를 가리킬 수 있습니다. 중복을 제거하기 전에 어떤 기준으로 판단할지 정하세요. 최소한 프로토콜, 주소, 포트, 사용자 식별 정보, 전송 설정을 확인해야 합니다. 주소와 포트만 보고 삭제하면 사용자 식별 정보나 보안 설정이 다른 유효한 항목까지 잘못 지울 수 있습니다. 중복 제거 알고리즘이 명확하지 않다면 먼저 백업을 내보내 복사본에서 작업하세요. 유일하게 사용할 수 있는 목록을 바로 정리하지 마세요.
구독 항목을 수동으로 수정할 때는 변경 범위를 추적할 수 있도록 관리하세요. 서버 메모를 임시로 바꾸는 것은 대체로 영향이 적지만 SNI, 전송 경로, 공개 키를 바꾸면 다음 업데이트에서 원래 값으로 돌아갈 수 있습니다. 변경 사항을 계속 유지해야 한다면 별도의 수동 항목으로 복사하고 원래 출처와 수정 목적을 기록하세요. 설정 충돌을 감추려고 구독 업데이트를 꺼 두면 주소나 서비스 매개변수가 바뀌어도 오래된 설정을 계속 사용할 수 있어 나중에 문제를 해결하기가 더 어려워집니다.
| 그룹 용도 | 업데이트 정책 | 보관할 항목 |
|---|---|---|
| 주 사용 출처 | 검증 후 정기 업데이트 | 현재 활성 설정과 마지막으로 정상 작동한 백업 |
| 예비 출처 | 별도로 업데이트하고 일부 항목 검증 | 독립적인 가져오기 경로와 사용 가능한 항목 |
| 수동 설정 | 수동으로 수정 | 원래 출처, 수정 목적, 복구용 매개변수 |
| 테스트 그룹 | 필요할 때 가져오기 | 테스트 조건과 결과를 기록하고 주 설정은 교체하지 않기 |
업데이트, 선택, 장애 전환을 각각 처리하기
구독 업데이트, 지연 시간 테스트, 활성 서버 선택은 서로 다른 작업입니다. 구독 업데이트가 성공했다고 서버가 전환된 것은 아니며, 목록 순서가 자동으로 최적 서버를 선택한다는 뜻도 아닙니다. 클라이언트가 자동 선택 기능을 제공하더라도 실행 조건, 테스트 주소, 전환 범위를 확인하세요. 테스트 대상에 접근할 수 있어도 모든 서비스에 접근할 수 있는 것은 아니며 TCP 연결 수립에 성공했다고 전체 요청이 성공한 것도 아닙니다. 각 테스트의 의미는 지연 시간 테스트와 다운로드 속도 측정의 차이에서 확인하세요.
자동 업데이트를 설정할 때는 긴 연결을 안정적으로 유지해야 하는 시간대를 피하고, 업데이트가 코어를 다시 로드하는지 먼저 확인하세요. 모바일 기기는 네트워크가 전환되거나 절전 상태에 들어가면 예약 작업이 늦게 실행될 수 있습니다. 따라서 자동 업데이트를 정확한 시간에 실행된다고 보장되는 기능으로 여기지 마세요. 중요한 작업을 시작하기 전에는 설정과 연결 상태를 직접 확인하세요. 여러 구독이 모두 같은 실패한 연결을 통해 가져오는 방식이라면 예비 출처도 동시에 업데이트하지 못할 수 있으므로, 검증된 오프라인 설정 백업을 보관하세요.
구독 주소에는 접근 권한이 포함되는 경우가 많으므로 일반 공개 웹페이지 링크처럼 취급하면 안 됩니다. 브라우저 기록, 스크린샷, 클립보드 동기화, 내보낸 파일에 전체 주소가 남을 수 있습니다. 설정을 공유할 때는 문제 해결에 필요한 항목만 제공하고 구독 주소와 연결 식별 정보는 공개하지 마세요. 주소가 유출된 것으로 의심되면 제공처의 관리 기능으로 접근 자격 정보를 변경한 뒤 클라이언트를 업데이트하세요. 로컬 그룹 이름만 바꿔서는 기존 주소가 무효화되지 않으며 다른 기기의 접근도 차단되지 않습니다.
장애 전환은 정해진 절차에 따라 진행할 수 있습니다. 먼저 현재 그룹과 활성 서버를 확인하고, 구독이 방금 변경되었는지 살펴본 뒤 검증된 예비 항목으로 전환하세요. 전환에 성공해도 장애가 발생한 설정은 사본으로 남겨 별도로 원인을 확인하고 출처 전체를 바로 삭제하지 마세요. 서로 다른 두 출처가 동시에 실패한다면 기기 DNS, 시스템 시간, 네트워크 권한, 트래픽 처리 상태부터 확인하세요. 출처를 여러 개 두면 일부 장애의 영향을 줄일 수 있지만 같은 기기에서 발생하는 공통 네트워크 문제까지 해결되지는 않습니다.
사용자 지정 아웃바운드: 태그, 기본 경로, 복구 관리
설정을 누가 생성하는지 먼저 확인하기
아웃바운드는 코어가 대상과 연결을 수립하는 방식을 설명하고, 라우팅은 각 요청에 어떤 아웃바운드를 사용할지 결정합니다. 클라이언트 그래픽 인터페이스는 일반적으로 활성 서버, 라우팅 모드, 매개변수를 바탕으로 실행 설정을 생성합니다. 임시로 생성된 파일을 직접 편집하면 다음 시작 때 덮어써질 수 있습니다. 장기적으로 사용자 지정 설정을 적용하기 전에 클라이언트에서 사용자 지정 설정이나 템플릿 입력을 지원하는지 확인하고 현재 결과를 내보내 비교 자료로 보관하세요. 데스크톱의 일반 설정은 우선 v2rayN 그래픽 옵션으로 처리하고 인터페이스에서 표현할 수 없는 경우에만 전체 설정을 직접 관리하세요.
Xray, V2Fly, 기타 네트워크 구성 요소의 설정 형식은 필드 이름이 비슷하다고 서로 바꿔 쓸 수 있는 것이 아닙니다. 이 절의 예시는 Xray 스타일 JSON을 기준으로 하며 모든 클라이언트에서 그대로 가져올 수 있는 것은 아닙니다. 전체 설정을 직접 지정하면 클라이언트의 서버 목록 생성 로직이 우회될 수 있으므로 목록에서 항목을 바꿔도 연결 대상이 달라지지 않을 수 있습니다. 저장한 뒤 실제로 실행되는 파일, 코어 종류, 설정 로드 결과를 로그에서 확인하세요. 먼저 수정한 파일이 실제로 사용되지 않은 문제부터 배제해야 합니다.
직결 및 차단 아웃바운드로 기본 구조 검증하기
다음은 아웃바운드 배열의 일부입니다. freedom은 직결을, blackhole은 매칭된 트래픽을 버리는 것을 뜻합니다. 다른 규칙이 처리하지 않으면 첫 번째 항목이 기본 아웃바운드가 되는 경우가 많으므로 이 예시는 기본값이 직결입니다. 완전한 프록시 설정은 아닙니다. 실제 프록시 아웃바운드를 추가하려면 검증된 클라이언트 설정에서 올바른 연결 매개변수를 유지하고 라우팅 규칙이 해당 태그를 참조하도록 하세요. 서버 식별 정보를 임의로 만들어 넣지 마세요.
{
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
},
{
"tag": "block",
"protocol": "blackhole",
"settings": {}
}
]
}태그는 짧고 안정적으로 정하며 같은 설정 안에서 고유하게 사용해야 합니다. 아웃바운드 태그를 proxy에서 proxy-main으로 바꾸면 기존 태그를 참조하는 라우팅 규칙과 관련 설정도 모두 함께 변경해야 합니다. 화면에 표시되는 메모를 태그 대신 사용하거나 서로 다른 아웃바운드에 같은 이름을 지정하지 마세요. 관리할 때는 ‘인바운드 태그, 규칙 조건, 대상 아웃바운드’ 대응표를 먼저 작성한 뒤 모든 참조가 정의되어 있는지 확인하세요. JSON 들여쓰기만 보는 것보다 신뢰할 수 있는 방법입니다.
연쇄 연결, 트래픽 분할, 자동 장애 전환 구분하기
아웃바운드를 여러 개 설정해도 여러 연결 방식이 존재할 뿐 자동으로 장애 전환되지는 않습니다. 대상에 따라 서로 다른 아웃바운드를 지정하는 것은 트래픽 분할이고, 한 아웃바운드를 거쳐 다른 연결을 수립하는 것은 연쇄 연결입니다. 상태를 확인해 아웃바운드를 선택하려면 별도의 선택 기능이 필요합니다. 이 세 가지를 혼동하면 안 됩니다. 상태 확인과 선택 로직을 명시적으로 설정하지 않았다면 첫 번째 프록시가 실패해도 배열에 두 번째 항목이 있다는 이유로 자동 전환되지 않습니다. 아웃바운드를 반복해서 추가해도 가용성이 높아지지 않습니다.
연쇄 연결은 앞 단계에 대한 의존성을 늘립니다. 첫 번째 연결의 DNS, 전송 기능, 안정성이 모두 다음 단계에 영향을 줍니다. 경로의 한 단계라도 필요한 네트워크 유형을 지원하지 않으면 최종 요청이 실패합니다. 연쇄 연결을 구성하기 전에 각 아웃바운드를 개별적으로 검증하고 현재 코어가 관련 필드를 지원하는지 확인하세요. 여러 단계의 연쇄 연결, 복잡한 라우팅, 서로 다른 해석 정책을 한꺼번에 추가하지 마세요. 오류가 발생했을 때 어느 단계에서 실패했는지 판단하기 어려워지고 로그도 제대로 활용할 수 없습니다.
복구 가능한 변경으로 최종 설정 검증하기
사용자 지정 설정은 먼저 문법과 로드를 확인한 다음 실제 서비스 동작을 검증하세요. 유효한 JSON이라도 현재 코어에서 필드를 지원하지 않을 수 있으며, 필드가 로드되어도 라우팅 참조가 올바르다는 뜻은 아닙니다. 시작 오류가 발생하면 로그가 가리키는 객체를 찾아 해결하고 라우팅 전체를 바로 삭제하지 마세요. 가장 최근에 정상 작동한 버전으로 복구한 뒤 아웃바운드 하나 또는 규칙 하나만 추가하세요. 클라이언트에서 설정 테스트 기능을 제공하면 우선 사용하고, 제공하지 않는 경우에도 재시작 전에 원본 파일과 복구할 수 있는 그래픽 설정을 보관하세요.
실제 동작을 검증할 때는 직결되어야 하는 대상, 프록시를 사용해야 하는 대상, 명확하게 차단할 테스트 대상을 각각 하나 이상 선택해 로그와 앱 결과를 확인하세요. 차단 규칙은 업데이트 및 DNS 요청에 영향을 주지 않도록 명확한 도메인이나 테스트 범위로 제한해야 합니다. 연결이 실패하면 마지막 타임아웃 정보만 보고 서버 문제라고 판단하지 말고 요청이 진입점에 도달했는지부터 시작해 매칭 규칙, 대상 태그, 주소 해석, 원격 핸드셰이크 순서로 확인하세요. 데스크톱 로그 메뉴는 v2rayN 기본 창 기능 안내를 참고하세요.
작업을 마친 뒤 정상 작동하는 설정, 변경 목적, 검증 조건을 함께 저장하세요. ‘인터넷이 된다’고만 기록하기보다 사용한 트래픽 처리 방식, DNS 경로, 아웃바운드 태그를 남겨야 재현에 도움이 됩니다. 내보내기 전에 불필요한 민감 정보를 제거하고 다른 사람과 공유할 때는 별도의 비식별화 사본을 사용하세요. 나중에 코어나 클라이언트를 바꾸면 기존 기준 설정이 정상 작동하는지 먼저 확인한 뒤 사용자 지정 필드를 옮기세요. 일반적인 연결 절차는 입문 가이드의 연결 및 확인 절차를 따르고 실제로 필요한 이유를 설명할 수 있는 복잡한 설정만 유지하세요.