JSON 구조와 설정 범위
먼저 어느 계층을 편집 중인지 확인하세요
V2Ray 환경에서 ‘설정 파일’은 하나의 파일만을 뜻하지 않습니다. v2rayN은 서버 정보, 구독 그룹, 라우팅 규칙과 각종 설정을 저장한 뒤 선택한 코어에 맞춰 실행 설정을 생성합니다. v2rayNG와 v2flyNG 역시 앱 자체 데이터와 코어 실행 설정이 별도로 존재합니다. 인터페이스에서 포트를 바꿔도 구독 원본이 바뀌는 것은 아니며, 임시로 생성된 JSON을 편집해도 다음 실행 때 유지된다는 보장은 없습니다. 필드를 살펴보기 전에 파일이 직접 관리하는 파일인지, 클라이언트에서 내보낸 파일인지, 실행 중 임시 디렉터리에 생성된 파일인지 확인하세요. 생성에 사용된 클라이언트와 코어도 기록해 두는 것이 좋습니다.
이 페이지의 예제는 V2Ray 형식의 JSON과 Xray에서 흔히 쓰이는 필드를 중심으로 설명합니다. V2Fly와 Xray는 설정 기반을 공유하지만 지원 프로토콜, 전송 이름과 확장 옵션은 서로 다를 수 있습니다. sing-box는 설정 구조가 별도이므로 v2rayN에서 코어를 바꿀 수 있다고 해서 이 JSON을 그대로 적용할 수는 없습니다. ‘알 수 없는 필드’ 오류가 나면 실제로 실행 중인 코어부터 확인한 다음, 해당 코어에서 지원하는 필드를 살펴보세요. 클라이언트 이름만으로 지원 여부를 추측하지 마세요. 클라이언트가 필요하다면 플랫폼 다운로드 페이지에서 맞는 항목을 선택하세요.
객체, 배열, 참조 관계
JSON의 최상위 구조는 객체이며 필드명과 문자열은 큰따옴표로 묶습니다. 배열은 대괄호로 감싸 여러 인바운드, 아웃바운드 또는 규칙을 담고, 객체는 중괄호로 감싸 여러 설정값을 묶습니다. 포트는 일반적으로 숫자로, 불리언 값은 소문자 true 또는 false로 씁니다. 표준 JSON은 주석, 마지막 쉼표, 작은따옴표를 허용하지 않습니다. 주석을 허용하는 확장 문법을 지원하는 도구를 사용하더라도 공유하거나 이전하기 전에는 표준 JSON으로 내보내세요. 다른 파서에서 읽지 못하는 일을 막을 수 있습니다.
아래는 JSON 파싱과 로컬 리스닝, 로그 출력을 점검하기 위한 독립 실행형 로컬 직접 연결 기본 설정입니다. 프록시 서버는 포함하지 않습니다. 루프백 주소에서만 수신하며 시스템 프록시를 설정하거나 데스크톱 메뉴를 만들지 않습니다. 설정을 불러오면 로컬 SOCKS 인바운드가 요청을 direct 아웃바운드로 전달합니다. 이때 특정 주소에 접속할 수 있어도 직접 연결 경로가 작동한다는 뜻일 뿐, 구독에 포함된 프록시 서버가 정상이라는 의미는 아닙니다. 클라이언트에 이 설정을 적용하기 전에는 사용자 지정 설정 기능을 지원하는지, 로컬 포트를 다시 설정하는지 확인하세요.
{
"log": {
"loglevel": "warning"
},
"inbounds": [
{
"tag": "local-socks",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": true
}
}
],
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
}
]
}구조가 올바른지 확인한 다음 의미도 검증하세요
파싱에 성공해도 해결된 것은 문법 문제뿐입니다. routing에 존재하지 않는 outboundTag를 지정하거나 규칙에서 인바운드 태그를 잘못 입력하면 오류가 발생하거나 예상과 다르게 트래픽이 분기될 수 있습니다. 태그는 같은 실행 설정 안에서 참조하는 이름이며 대소문자를 구분합니다. 인터페이스에 표시되는 메모나 서버 도메인이 아닙니다. 먼저 인바운드와 아웃바운드의 tag를 정리한 뒤 규칙이 올바른 태그를 참조하는지 확인하세요. 배열 순서에도 의미가 있습니다. 일반 라우팅 규칙은 순서대로 비교하며, 첫 번째 아웃바운드가 미일치 요청의 기본 출구인 경우가 많으므로 임의로 알파벳순 정렬을 해서는 안 됩니다.
| 필드 | 역할 | 흔한 오해 |
|---|---|---|
inbounds | 로컬 리스닝 및 수신 프로토콜 | 서버 주소를 listen에 입력 |
outbounds | 연결 대상 또는 프록시 서버 | 기본 출구 순서를 무시 |
routing | 요청을 일치시켜 출구 선택 | 존재하지 않는 tag 참조 |
dns | 내장 DNS 리졸버 설정 | 시스템 DNS를 자동으로 전환한다고 오해 |
policy | 사용자별 연결 정책 및 통계 옵션 | 시간 설정을 대역폭 제한으로 오해 |
이후의 부분 예제를 읽을 때는 여러 개의 완성된 객체를 한 파일에 차례대로 붙여 넣지 말고, 해당 필드를 올바른 최상위 위치에 병합하세요. 하나의 최상위 객체에 routing이나 dns를 중복 정의하지 마세요. 중복 키 처리 방식은 파서 구현에 따라 달라져 인터페이스 표시와 실제 동작이 다를 수 있습니다. 병합할 때마다 기능 하나만 변경하고, 변경 전 사본을 보관한 뒤 시작 로그에서 설정이 적용됐는지 확인하세요. 구독 가져오기와 일상적인 연결만 필요하다면 클라이언트가 설정을 생성하도록 두세요. 인터페이스로 구현할 수 없는 요구 사항이 있을 때만 JSON을 직접 관리하는 편이 좋습니다.
inbounds 인바운드와 로컬 리스닝
listen, port, protocol의 역할
인바운드는 애플리케이션 트래픽이 코어로 들어오는 입구입니다. listen은 수신할 로컬 주소, port는 포트 번호, protocol은 받을 프로토콜을 지정합니다. 데스크톱 로컬 프록시는 보통 127.0.0.1에서 수신하므로 로컬 프로세스만 연결할 수 있습니다. 0.0.0.0으로 설정하면 일반적으로 모든 IPv4 인터페이스에서 수신하므로 로컬 네트워크에 입구가 노출될 수 있습니다. 이는 ‘아무 서버나 사용’한다는 뜻도, 외부에서 반드시 접속할 수 있다는 뜻도 아닙니다. 실제 접근 가능 여부는 방화벽과 네트워크 환경에도 달려 있습니다. 공유가 꼭 필요한 경우가 아니라면 리스닝 범위를 넓히지 마세요.
SOCKS와 HTTP는 서로 다른 로컬 프록시 프로토콜이므로 애플리케이션 설정을 인바운드와 맞춰야 합니다. 브라우저에서 HTTP 프록시 주소를 입력할 때 SOCKS만 받는 포트를 지정해서는 안 됩니다. 명령줄 도구에서 SOCKS를 사용할 때도 프록시 측에서 도메인을 해석하는 방식을 지원하는지 확인하세요. v2rayN 인터페이스는 클라이언트와 선택한 코어가 구현하는 로컬 혼합 포트를 제공할 수 있습니다. 그렇다고 모든 V2Ray 형식 설정에서 mixed라는 protocol을 임의로 지정해도 된다는 뜻은 아닙니다. 사용 가능 여부는 현재 코어의 설정 정의를 기준으로 판단하세요.
SOCKS와 HTTP 인바운드를 각각 정의
아래는 인바운드 객체 두 개로 구성된 부분 설정입니다. 최상위 inbounds 배열에 있는 기존 항목을 대체하거나 병합해야 하며, 이미 사용 중인 포트와 겹치는 인바운드가 있어서는 안 됩니다. 두 인바운드 모두 루프백 주소에 연결됩니다. SOCKS는 UDP 수신을 활성화하고, HTTP 인바운드는 HTTP 프록시를 지원하는 프로그램에서 사용합니다. udp를 활성화해도 해당 인바운드가 관련 요청을 받는다는 뜻일 뿐, 이후 아웃바운드와 서버, 네트워크 경로까지 UDP를 전달한다고 보장하지 않습니다. 애플리케이션에서 프록시 요청을 보내지 않는다면 코어 라우팅을 변경해도 자동으로 이 포트를 이용하지 않습니다.
{
"inbounds": [
{
"tag": "local-socks",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": true
}
},
{
"tag": "local-http",
"listen": "127.0.0.1",
"port": 10809,
"protocol": "http",
"settings": {}
}
]
}로컬 포트는 서버의 원격 포트와 다릅니다. 로컬 포트는 이 기기의 애플리케이션이 접속하는 포트이고, 원격 포트는 outbounds의 서버 설정에 지정합니다. 둘을 같은 값으로 설정할 필요는 대개 없습니다. 포트가 사용 중이라면 먼저 클라이언트를 중복 실행했는지 확인하고, 백그라운드에 코어 프로세스가 남아 있는지 살펴본 뒤 비어 있는 포트로 바꾸세요. 인바운드 포트를 변경한 뒤에는 애플리케이션 프록시 설정과 클라이언트의 시스템 프록시 설정도 함께 변경해야 합니다. JSON만 바꾸고 시스템 프록시를 그대로 두면 코어는 정상적으로 시작했지만 브라우저는 이전 포트에 계속 연결할 수 있습니다.
sniffing의 용도와 한계
스니핑은 지원되는 트래픽 특성에서 도메인을 추출해 도메인 라우팅에 활용하는 기능입니다. 암호 해독 도구가 아니며 모든 연결에서 도메인을 식별할 수 있는 것도 아닙니다. Xray를 예로 들면 아래 객체를 인바운드 객체 안에 넣을 수 있으며, routeOnly는 스니핑 결과를 라우팅 판단에만 사용한다는 뜻입니다. 해당 필드의 지원 여부와 인식 가능한 프로토콜은 사용하는 코어에 따라 다릅니다. 애플리케이션이 이미 SOCKS 인바운드에 도메인을 전달한다면 라우팅에 사용할 도메인 정보가 있으므로, 설정을 ‘완전하게’ 만들기 위해 모든 스니핑 옵션을 추가로 켤 필요는 대개 없습니다.
{
"sniffing": {
"enabled": true,
"destOverride": ["http", "tls"],
"routeOnly": true
}
}Android VPN 모드는 시스템에서 제공하는 가상 네트워크 인터페이스로 트래픽을 받으므로 사용자가 앱마다 SOCKS 포트를 설정할 필요가 없습니다. v2rayNG의 ‘앱별 프록시’는 어떤 앱이 이 경로를 이용하거나 우회할지 결정하며, 인바운드 JSON의 리스닝 주소와는 다른 계층의 설정입니다. 데스크톱에서도 다른 트래픽 가로채기 방식을 사용할 때는 시스템 계층과 코어 계층을 구분해야 합니다. 먼저 트래픽이 코어에 도달하는지 확인한 다음 후속 규칙을 살펴보세요. ‘VPN 연결됨’ 표시만으로 모든 앱이 같은 인바운드를 이용한다고 단정할 수는 없습니다.
로컬 네트워크 기기의 접속을 허용하려면 인증, 접속 출처, 방화벽 범위도 고려해야 합니다. 인증이 없는 HTTP 또는 SOCKS 인바운드를 신뢰할 수 없는 네트워크에 직접 노출해서는 안 됩니다. 연결 기기가 프록시 주소를 정확히 알아야 하며, 호스트에서는 접근 가능한 네트워크 범위를 제한해야 합니다. listen만 변경하고 네트워크 경계를 고려하지 않으면 예상보다 넓은 접근 범위가 생길 수 있습니다. 문제 해결은 먼저 로컬 루프백 연결을 확인하고, 그다음 로컬 네트워크 접속을 추가한 뒤 마지막으로 방화벽을 점검하세요. 주소와 규칙을 한꺼번에 바꾸는 것보다 단계적으로 허용하는 편이 원인을 찾기 쉽습니다.
outbounds 아웃바운드와 프로토콜 매개변수
기본 출구와 명시적 태그
아웃바운드는 코어가 요청을 이어서 처리하는 방식을 결정합니다. freedom은 보통 직접 연결에, blackhole은 차단에 사용하며 VMess 같은 프로토콜은 해당 서버를 통해 트래픽을 전달합니다. tag는 라우팅에서 출구를 선택할 때 사용하는 식별자이지, 사용할 수 있는 서버를 자동으로 만들어 주는 값이 아닙니다. proxy라는 태그도 어떤 프로토콜이든 가리킬 수 있으므로 protocol과 settings를 함께 확인해야 출구의 실제 성격을 알 수 있습니다. 라우팅 규칙에 일치하지 않는 요청은 보통 outbounds의 첫 번째 항목으로 전달됩니다. direct를 첫 번째에 두면 기본 경로는 직접 연결입니다.
아래 예제는 직접 연결과 차단 출구를 정의합니다. 라우팅 참조를 연습하기 위한 설정으로 원격 프록시 기능은 포함하지 않습니다. blackhole의 빈 설정은 해당 프로토콜의 기본 방식으로 요청을 차단합니다. 특정 응답을 반환하려면 현재 코어에서 지원하는 프로토콜 설정을 확인하세요. 임의의 HTTP 텍스트를 일반적인 응답으로 사용할 수는 없습니다. 아웃바운드가 여러 개라면 direct, block, proxy처럼 의미가 분명하고 고유한 태그를 사용하세요. 숫자만 붙여 구분하는 것보다 라우팅 문제를 확인할 때 출구의 역할을 바로 알 수 있는 편이 중요합니다.
{
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
},
{
"tag": "block",
"protocol": "blackhole",
"settings": {}
}
]
}VMess로 서버 필드 이해하기
VMess 아웃바운드는 서버 주소, 원격 포트와 사용자 매개변수를 settings의 vnext 배열에 둡니다. address는 서버 도메인이나 주소, port는 서버가 실제로 수신하는 포트, users는 인증 사용자 정보를 나타냅니다. 아래 예제는 필드 구조를 보여 주기 위한 것입니다. example.net은 문서용 도메인이며, 모두 0인 UUID도 설명용 값이므로 실제 서비스에 연결할 수 없습니다. 실제로 사용할 매개변수는 기존 서버 설정이나 유효한 구독에서 가져와 서로 일치하는지 확인해야 합니다. 이 예제에는 사용할 수 있는 노드가 없으며 UUID를 무작위로 만들어 서버 인증 정보를 추측해서도 안 됩니다.
{
"tag": "proxy",
"protocol": "vmess",
"settings": {
"vnext": [
{
"address": "example.net",
"port": 443,
"users": [
{
"id": "00000000-0000-0000-0000-000000000000",
"alterId": 0,
"security": "auto",
"level": 0
}
]
}
]
}
}이 객체만으로는 연결 설정이 완성되지 않았으며 서버에 맞는 전송 및 보안 계층 설정도 필요합니다. 포트가 443이라고 TLS가 자동으로 활성화되는 것은 아닙니다. users의 security와 streamSettings의 security도 서로 다른 계층의 설정입니다. 최신 VMess 설정에서는 보통 alterId를 0으로 사용하지만, 이전 설정을 옮길 때는 서버 측 설정을 기준으로 확인하세요. 시스템 시간이 크게 어긋나면 인증에 영향을 줄 수 있습니다. 핸드셰이크 오류가 발생하면 사용자 매개변수를 하나씩 확인하기 전에 시스템 시간과 시간대를 먼저 점검하세요.
프로토콜 간에 필드를 그대로 옮기지 마세요
VMess, VLESS 및 다른 프로토콜은 사용자 설정 구조가 완전히 같지 않습니다. 한 프로토콜의 users 객체를 다른 프로토콜 설정에 그대로 붙여 넣으면 파싱 단계에서 실패하거나 의미 없는 매개변수 조합이 될 수 있습니다. 연결 주소, 전송 Host, TLS serverName도 서로 다른 필드일 수 있으며 각각 네트워크 연결, 애플리케이션 계층 요청, 인증서 검증에 사용됩니다. 서버에서 명시적으로 요구하는 경우에만 해당 값을 입력하세요. 세 항목을 같은 이름으로 맞추려고 구독에 지정된 값을 덮어쓰지 마세요.
| 필드 | 주요 위치 | 확인할 사항 |
|---|---|---|
tag | 아웃바운드 객체 | outboundTag와 정확히 일치 |
address / port | 프로토콜 서버 설정 | 실제 서버 주소와 수신 포트 |
id | UUID를 지원하는 프로토콜의 사용자 항목 | 유효한 서버 정보 사용 |
streamSettings | 아웃바운드 객체 | 서버 측 전송 및 보안 계층과 일치 |
구독 업데이트와 수동 편집 사이에는 설정이 덮어써지는 관계도 있습니다. 클라이언트는 보통 구독의 서버 정보를 바탕으로 아웃바운드를 다시 생성합니다. 임시 JSON을 직접 수정해도 구독에는 반영되지 않으며 다음에 서버를 전환할 때 변경 사항이 사라질 수 있습니다. 사용자 지정 설정을 계속 사용해야 한다면 클라이언트에서 제공하는 사용자 지정 설정 또는 템플릿 기능을 이용하고 서버 정보의 출처도 보관하세요. 라우팅만 바꾸려면 인증 필드를 함께 수정할 필요가 없으며, 로컬 포트만 조정할 때도 아웃바운드 전체를 다시 작성할 필요는 없습니다. 변경 범위를 좁히면 정상적인 연결 매개변수를 잘못 바꿀 위험도 줄어듭니다.
‘연결 테스트 통과’와 ‘실제 트래픽 전달 정상’은 같은 뜻이 아닙니다. 테스트는 연결 성립이나 특정 URL 또는 요청만 확인할 수 있지만, 실제 애플리케이션은 장시간 연결, 다른 도메인, UDP를 사용할 수 있습니다. 먼저 아웃바운드가 프로토콜 연결을 맺는지 확인하고, 액세스 로그에서 애플리케이션 요청이 실제로 해당 태그를 통과하는지 확인한 다음 실제 사용 사례를 테스트하세요. 단일 공유 링크와 구독 주소의 차이는 공유 링크와 구독 가져오기 안내에서 확인할 수 있습니다. 잘못된 데이터 계층의 매개변수를 수정하지 않도록 주의하세요.
streamSettings 전송 및 보안 계층
프로토콜, 전송, TLS를 구분해서 살펴보세요
아웃바운드 프로토콜은 프록시 요청을 구성하고 인증하는 역할을 하며, 전송은 양쪽 끝 사이에서 데이터를 전달하는 방식을 정합니다. TLS 등의 보안 계층은 해당 연결을 보호하고 신원을 확인합니다. 세 요소는 서로 연관되어 있지만 서로를 대체할 수는 없습니다. 같은 VMess 프로토콜도 다양한 전송과 조합할 수 있지만 서버가 그 모든 조합을 지원하는 것은 아닙니다. 클라이언트에서 옵션을 선택할 수 있다고 해서 현재 서버가 지원하는 것은 아닙니다. 문제를 해결할 때는 드롭다운의 모든 조합을 무작정 시도하기보다 ‘프로토콜 일치, 전송 일치, 보안 계층 일치’ 순서로 확인하세요.
streamSettings는 해당 인바운드 또는 아웃바운드 객체 안에 두며 임의의 최상위 필드가 아닙니다. 여기서는 클라이언트 아웃바운드를 살펴보고 WebSocket과 TLS를 조합한 구조를 예로 듭니다. network가 ws이면 관련 매개변수는 wsSettings에, security가 tls이면 관련 매개변수는 tlsSettings에 둡니다. 코어와 구현에 따라 전송 이름 및 사용 가능한 확장 기능이 다를 수 있습니다. 새로운 이름이나 폐기 예정 경고가 나오면 비슷해 보이는 철자로 필드명을 바꾸지 말고 현재 코어가 지원하는 범위를 확인하세요.
{
"streamSettings": {
"network": "ws",
"security": "tls",
"tlsSettings": {
"serverName": "example.net"
},
"wsSettings": {
"path": "/proxy",
"headers": {
"Host": "example.net"
}
}
}
}주소, serverName, Host
예제의 example.net과 경로는 필드를 설명하기 위한 값일 뿐이며 실제 연결에는 서버에서 제공한 값을 사용해야 합니다. 아웃바운드 address는 먼저 연결할 대상을 정하고, tlsSettings.serverName은 TLS 서비스 이름과 인증서 검증에 사용하며, WebSocket의 Host는 HTTP 요청의 호스트 정보를 나타냅니다. 리버스 프록시 환경에서는 세 값이 서로 다를 수 있습니다. 직접 편집할 때는 각 값을 따로 확인하고 서버 메모 하나로 모든 필드를 덮어쓰지 마세요. 도메인이 같아 보이는 경우도 있지만 모든 설정에 적용되는 규칙은 아닙니다.
path는 임의의 설명 문구를 입력하는 곳이 아닙니다. 리버스 프록시는 경로를 기준으로 WebSocket 요청을 백엔드에 전달하는 경우가 많습니다. 경로가 맞지 않으면 일반 웹 페이지나 리디렉션, 오류 응답이 반환될 수 있습니다. 대소문자, 앞쪽 슬래시, 추가 쿼리 문자열도 서버 동작에 영향을 줄 수 있습니다. 연결 직후 끊긴다면 먼저 서버에서 요구하는 경로와 Host를 확인한 뒤 중간 프록시가 연결 업그레이드를 지원하는지 살펴보세요. 원격 WebSocket 경로 오류를 해결하려고 로컬 인바운드 포트를 바꾸지 마세요. 두 설정은 완전히 다른 위치에 있습니다.
연결 단계별로 오류를 찾으세요
연결 시간 초과는 주어진 시간 안에 어떤 단계가 완료되지 않았다는 뜻일 뿐, 인증 암호가 틀렸다는 의미는 아닙니다. 서버 주소를 해석하지 못하면 먼저 도메인 해석을 살펴보세요. 주소를 해석했지만 연결을 맺지 못한다면 원격 포트 수신 여부, 방화벽과 네트워크 경로를 확인해야 합니다. TLS 단계에 진입했다면 로그에 인증서나 핸드셰이크 관련 단서가 남는 경우가 많습니다. 프록시 프로토콜 인증 단계에 도달한 뒤에야 사용자 매개변수를 주요 점검 대상으로 삼으세요. 이 순서를 따르면 라우팅 규칙, DNS와 인증 필드를 한꺼번에 잘못 바꾸는 일을 줄일 수 있습니다.
전송 계층에는 소켓 동작, 연결 재사용, 특정 전송 확장 등 다양한 고급 옵션이 있습니다. 처음 설정할 때 반드시 필요한 항목은 대개 아닙니다. 여러 출처의 ‘최적화 매개변수’를 한꺼번에 합치면 연결 수명이 달라지거나 호환되지 않는 조합이 생기고 서버가 요청을 인식하지 못할 수 있습니다. 먼저 서버 설정과 일치하는 최소 구성을 만들고, 명확한 필요가 있을 때 옵션을 하나씩 추가해 검증하세요. 근거가 없는 문제를 해결하려고 매개변수를 쌓아 올린다고 속도가 저절로 빨라지지는 않습니다.
REALITY 같은 확장 기능도 tlsSettings에 임의로 넣어 대체할 수 있는 값이 아닙니다. 전용 코어 요구 사항과 개별 매개변수 제약이 있습니다. v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용하므로 두 코어가 동일한 프로토콜과 확장 기능을 지원한다고 볼 수 없습니다. 이전하기 전에 서버별로 필요한 기능을 확인한 다음 클라이언트와 코어를 선택하세요. 먼저 가져온 뒤 오류 필드를 하나씩 지우는 방식은 피해야 합니다. v2rayN 데스크톱 버전에서도 해당 서버에 실제로 어떤 코어가 선택되어 실행되는지 확인하세요.
변경 결과를 비교하려면 같은 서버와 네트워크, 테스트 대상을 유지하고 매개변수 하나만 바꾸세요. 로그의 단계별 변화를 기록하는 것도 중요합니다. 전송, 서버 주소, 라우팅 모드를 한 번에 바꾸면 연결이 복구되더라도 어떤 변경이 효과를 냈는지 알 수 없습니다. 핸드셰이크 오류가 반복된다면 실행 로그 오류 확인 방법을 참고해 계속 문제를 해결하세요. 속도 문제는 연결이 정상화된 뒤 별도로 분석해야 하며, 연결이 느리다고 모두 TLS 탓으로 돌려서는 안 됩니다.
routing 라우팅과 규칙 순서
규칙이 적용되는 시점을 먼저 이해하세요
라우팅은 이미 코어에 들어온 요청을 처리하고 조건에 따라 아웃바운드를 선택합니다. 애플리케이션의 시스템 프록시를 켜 주거나 클라이언트에 들어오지 않은 연결을 자동으로 받지는 않습니다. 일반 field 규칙은 배열 순서대로 비교되며 가장 먼저 조건에 맞는 규칙이 출구를 결정합니다. 규칙에 서로 다른 조건이 여러 개 있으면 일반적으로 모두 만족해야 합니다. 같은 domain 또는 ip 배열의 항목은 여러 후보 조건을 나타냅니다. 규칙을 설계할 때는 먼저 트래픽의 출처와 대상, 출구를 정한 다음 필드를 선택하세요. 목록을 먼저 늘어놓고 우선순위를 추측해서는 안 됩니다.
아래는 부분 라우팅 설정 예제입니다. 사설 주소와 geosite:cn 도메인은 direct로 전달합니다. 이 예제를 사용하려면 outbounds에 direct 태그가 있어야 합니다. geoip 및 geosite 참조를 사용하려면 실행 환경에 호환되는 규칙 데이터도 있어야 합니다. 어떤 규칙에도 일치하지 않는 요청은 일반적으로 proxy라는 태그를 자동으로 선택하는 것이 아니라 첫 번째 아웃바운드로 돌아갑니다. 나머지 요청을 프록시로 보내려면 유효한 프록시 아웃바운드를 확인한 뒤 기본 출구를 지정하세요. 규칙 이름만 보고 전체 동작을 추측하지 마세요.
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
}
]
}
}domainStrategy와 일치 방식
routing.domainStrategy는 라우팅 규칙을 비교할 때 도메인과 주소를 어떻게 처리할지 정합니다. AsIs는 보통 요청에 이미 있는 정보만으로 비교합니다. IPIfNonMatch는 도메인 규칙에 일치하지 않을 때 주소 규칙으로 계속 확인할 수 있도록 해석을 시도합니다. IPOnDemand는 주소 정보가 필요한 비교를 할 때 해석을 요청합니다. 이는 DNS 서버 주소가 아니며 모든 아웃바운드가 특정 주소 체계를 우선 사용하도록 강제하는 옵션도 아닙니다. 전략을 선택할 때는 주소 규칙의 유무와 도메인 해석의 정상 여부, 추가 해석이 문제 해결 및 요청 경로에 미치는 영향을 고려하세요.
도메인 규칙은 전체 도메인, 도메인 및 하위 도메인, 키워드, 정규식 등 서로 다른 범위를 지정할 수 있습니다. 흔히 쓰는 full:example.net은 지정한 이름만 대상으로 하고, domain:example.net은 해당 하위 도메인도 포함합니다. regexp:를 사용할 때는 정규식과 JSON 문자열 이스케이프를 이해해야 합니다. 특정 사이트 하나만 일치시키려면 범위가 명확한 형식을 우선 사용하세요. 범위가 넓은 키워드는 관계없는 도메인까지 일치시킬 수 있고 복잡한 정규식은 유지 관리 부담을 높입니다. 변경 후에는 예상대로 일치해야 하는 대상과 일치하지 않아야 하는 대상을 모두 테스트하세요.
{
"type": "field",
"domain": [
"full:example.net",
"domain:example.org"
],
"network": "tcp",
"outboundTag": "direct"
}이 규칙은 대상 도메인이 항목 중 하나에 일치하고 네트워크 유형이 TCP여야 적용됩니다. 요청에 주소만 포함되어 있다면 도메인 규칙을 판단할 정보가 없을 수 있습니다. 스니핑으로 도메인을 가져온 경우에도 스니핑 및 라우팅 설정을 확인해야 합니다. ‘웹사이트가 특정 도메인을 사용한다’는 사실과 ‘코어가 해당 도메인을 받았다’는 사실을 혼동하지 마세요. 애플리케이션이 직접 해석하거나 암호화된 DNS를 사용하거나 주소에 바로 연결하면 코어에서 확인할 수 있는 정보가 달라집니다. 도메인 항목을 계속 늘리기보다 액세스 로그에 대상이 어떤 형식으로 기록되는지 확인하는 편이 효과적입니다.
예외 규칙부터 기본 경로까지 순서대로 배치하세요
먼저 처리해야 하는 범위가 좁은 규칙은 더 넓은 규칙보다 앞에 배치하세요. 예를 들어 특정 내부 서비스를 먼저 처리하고 나서 더 넓은 주소나 도메인 범위를 처리합니다. 앞에 모든 TCP를 포괄하는 규칙이 있으면 뒤에 작성한 특정 웹사이트의 TCP 예외는 적용되지 않는 경우가 많습니다. 규칙을 관리할 때는 용도를 메모로 남기되 문서나 클라이언트에서 지원하는 메모 기능을 이용하세요. 표준 JSON에 중국어 주석을 직접 넣으면 안 됩니다. 작동하지 않는 항목을 정리할 때도 의존 관계가 있는 설정을 한꺼번에 삭제하지 않도록 되돌릴 사본을 보관하세요.
‘중국 본토 우회’는 클라이언트에 미리 정의된 규칙 세트의 흔한 이름일 뿐, JSON에서 분기 처리를 자동으로 완성하는 불리언 옵션이 아닙니다. 실제 효과는 규칙 데이터, 규칙 순서, 기본 출구와 DNS 동작에 따라 달라집니다. 클라이언트와 코어, 규칙 데이터가 업데이트되면 경계에 해당하는 대상의 처리 결과도 달라질 수 있습니다. 정확한 분기 처리가 필요하다면 메뉴 이름만 보지 말고 실행 중인 routing 설정을 확인하세요. 시스템 프록시와 라우팅 모드의 관계는 시스템 프록시와 중국 본토 우회 모드 설명에서 확인할 수 있습니다.
특정 대상의 문제를 해결하려면 먼저 요청이 코어에 들어왔는지 확인하고 어떤 출구에 일치했는지 살펴본 뒤 해당 출구가 연결 가능한지 점검하세요. 비교를 위해 전체 도메인 규칙 하나를 임시로 추가해도 계속 일치하지 않는다면 요청에 도메인이 포함되어 있는지, 설정이 다시 로드되었는지, 앞쪽에 더 넓은 규칙이 있는지 확인합니다. 로컬 네트워크 주소에 접속할 때 문제가 생기면 요청이 코어에 들어가지 않았을 수 있으므로 시스템 프록시의 우회 목록도 확인해야 합니다. 데스크톱 프로세스 규칙은 플랫폼과 트래픽 가로채기 기능에 따라 다릅니다. Android의 앱별 프록시를 일반적인 routing 필드로 간주해서는 안 됩니다.
dns 이름 해석과 라우팅의 연동
시스템 DNS와 내장 DNS를 구분하세요
DNS는 도메인을 주소로 변환하지만 한 번의 접속 과정에서도 여러 지점에서 해석이 이루어질 수 있습니다. 애플리케이션이 시스템 리졸버를 호출할 수도 있고 자체 해석 기능을 사용할 수도 있습니다. 코어도 라우팅 판단이나 아웃바운드 연결 과정에서 내장 DNS를 호출할 수 있습니다. 최상위 dns는 주로 코어의 이름 해석 기능을 설정합니다. 이 객체가 있다는 이유만으로 기기 전체의 DNS 요청을 가로채지는 않습니다. 시스템에서 여전히 기존 리졸버를 사용하는 것만으로 코어의 dns가 적용되지 않았다고 단정할 수 없습니다. 먼저 관찰한 쿼리가 어느 프로세스와 처리 단계에서 발생했는지 확인하세요.
도메인을 포함한 요청이 SOCKS에 들어오면 이후에 코어 또는 원격 서버가 도메인을 해석할 수 있습니다. 애플리케이션이 먼저 도메인을 해석한 뒤 주소를 보내면 코어에는 주소만 전달될 수 있습니다. 두 방식에 따라 도메인 라우팅에서 확인할 수 있는 정보와 오류가 발생하는 위치가 달라집니다. ‘도메인으로는 접속되지 않지만 주소로는 접속됨’ 문제를 해결하려면 먼저 어느 쪽에서 해석이 이루어지는지 확인하고 결과를 점검하세요. 모든 DNS 서버를 차례로 바꾸면 원래 문제를 가릴 수는 있어도 특정 애플리케이션과 브라우저의 동작이 다른 이유를 설명하지는 못합니다.
필드를 이해하기 위한 DNS 설정 예제
아래 예제는 로컬 리졸버를 사용해 현재 시스템의 해석 경로를 유지하면서 내장 쿼리에서 IPv4 결과를 우선하도록 지정합니다. hosts의 example.test는 정적 매핑을 설명하기 위한 문서용 주소이며 실제 웹사이트를 제공하지 않습니다. 최상위 dns에 이 설정을 병합하더라도 해당 기능이 내장 리졸버를 호출해야 적용됩니다. 코어마다 쿼리 전략과 서버 옵션 지원이 다릅니다. 시작할 때 필드 오류가 발생하면 현재 코어의 설정 정의를 다시 확인하세요.
{
"dns": {
"hosts": {
"example.test": "192.0.2.10"
},
"servers": [
"localhost"
],
"queryStrategy": "UseIPv4"
}
}hosts는 적고 명확하며 안정적인 로컬 매핑에 적합하지만, 동적으로 바뀌는 사이트를 장기간 대신할 수는 없습니다. 여러 주소와 지역별 라우팅, 장애 조치를 사용하는 서비스가 많아 오래된 주소 하나로 고정하면 간헐적으로 접속이 실패할 수 있습니다. 정적 매핑을 사용해도 TLS 인증서는 도메인을 기준으로 검증합니다. 목적지 주소를 바꾼다고 아무 서버나 해당 도메인의 신원을 갖는 것은 아닙니다. 테스트 매핑을 삭제한 뒤에는 애플리케이션 및 시스템 캐시도 고려하세요. 캐시를 지우지 않으면 다음 접속에서도 이전 결과를 사용해 설정이 적용되지 않았다고 오해할 수 있습니다.
DNS 해석 전략과 아웃바운드 전략은 다릅니다
dns.queryStrategy와 routing.domainStrategy는 이름이 비슷하지만 용도가 다릅니다. 전자는 주로 내장 DNS 쿼리에서 사용할 주소 체계를 제한하고, 후자는 라우팅 비교를 위해 도메인을 주소로 해석할지 결정합니다. 일부 아웃바운드나 소켓 설정에는 별도의 도메인 처리 옵션이 있으며 이것도 혼동해서는 안 됩니다. 내장 DNS 쿼리를 IPv4로 바꿔도 모든 애플리케이션과 시스템 해석, 원격 프록시가 IPv4만 사용한다는 뜻은 아닙니다. 주소 체계 문제를 찾으려면 로컬 해석, 실제 연결 대상과 최종 출구를 각각 관찰하세요.
| 설정 위치 | 주요 역할 | 이 설정만으로 판단할 수 없는 내용 |
|---|---|---|
dns.servers | 내장 DNS 서버 선택 | 모든 애플리케이션이 이 서버를 사용함 |
dns.queryStrategy | 내장 DNS 쿼리의 주소 체계 정책 | 기기 전체에서 다른 주소 체계를 비활성화함 |
routing.domainStrategy | 주소 일치를 위해 라우팅에서 도메인을 해석할지 결정 | DNS 서버 주소를 지정함 |
dns.hosts | 내장 DNS의 정적 매핑 | 운영체제 hosts 파일을 수정함 |
암호화된 DNS 서비스를 지정할 때는 해당 서비스에 연결할 방법도 마련해야 합니다. 쿼리 서비스가 도메인 이름을 사용하고, 그 서비스에 연결할 때 아직 작동하지 않는 동일한 DNS 경로에 의존하면 순환 참조가 생길 수 있습니다. 프록시 서버의 도메인도 프록시를 거쳐야 사용할 수 있는 DNS 경로에 의존한다면 시작 단계에서 멈출 수 있습니다. 서버 도메인에 처음 연결할 주소를 어떻게 확보할지, DNS 쿼리 연결은 어떤 출구를 이용할지, 실패할 때 사용할 대체 경로가 있는지 명확히 하세요. 설정이 복잡하다고 해서 더 안정적인 것은 아닙니다.
문제 해결은 세 단계로 진행하세요. 먼저 도메인 해석 결과를 얻을 수 있는지 확인하고, 다음으로 결과가 접속 가능한 주소인지 살펴본 뒤, 마지막으로 연결이 예상한 출구를 통과하는지 점검합니다. 해석에 성공했는데 연결 시간이 초과된다면 네트워크 경로를 계속 확인해야 합니다. 모든 시간 초과를 DNS 오류라고 부르면 안 됩니다. 해석 실패를 인증서 검증 비활성화로 해결해서도 안 됩니다. 두 DNS 결과를 비교할 때는 시간과 주소 체계를 기록하세요. 동적 라우팅에 따라 결과가 달라질 수 있습니다. 변경 사항과 오류가 반복적으로 연관되는 경우에만 해당 변경을 유지할 근거가 생깁니다.
라우팅의 geosite 데이터는 도메인 집합을, geoip 데이터는 주소 집합을 나타냅니다. DNS 캐시가 아니며 도메인을 올바른 주소로 자동 변환하지도 않습니다. 규칙 집합을 불러올 수 있는지, 도메인을 해석할 수 있는지, 출구에 연결할 수 있는지는 각각 별도로 확인해야 합니다. 투명 프록시와 가상 주소, DNS 분기에는 추가 상태가 생기므로 먼저 일반 로컬 프록시를 기본 설정으로 구축한 다음 기능을 단계적으로 더하세요. 라우터나 게이트웨이에 배포하려면 Xray 게이트웨이 배포 개요를 참고하세요. 데스크톱 리스닝 설정을 그대로 적용하지 마세요.
policy 정책, 로그, 통계
사용자별 정책 연결 방식
policy는 연결 동작과 통계 관련 정책을 정의합니다. 별도의 라우팅 테이블도 아니고 애플리케이션에 대역폭을 자동 할당하는 속도 제한기도 아닙니다. levels 객체는 사용자 레벨별로 매개변수를 구성하며 JSON의 키는 문자열입니다. 프로토콜 사용자 설정의 level은 해당 레벨과 연결하는 데 사용됩니다. 이 기능을 지원하는 프로토콜 및 설정 경로에서만 레벨이 의미가 있습니다. 임의의 인바운드 태그를 레벨 이름으로 사용할 수는 없습니다. 구체적인 필요가 없다면 코어 기본 정책을 먼저 사용하고, 의미를 모르는 매개변수를 일반적인 최적화 옵션처럼 다루지 마세요.
아래는 레벨 0의 연결 시간 매개변수 예제입니다. 값의 단위는 초이며 구조를 설명하기 위한 것으로 모든 네트워크에 권장되는 설정은 아닙니다. handshake는 해당 연결의 핸드셰이크 단계 시간을 제한하고 connIdle은 유휴 연결 시간을 처리합니다. uplinkOnly와 downlinkOnly는 연결이 단방향 상태로 전환된 뒤 대기하는 방식에 영향을 줍니다. 각 매개변수가 어떤 프로토콜과 단계에 적용되는지는 현재 코어 구현을 기준으로 확인하세요. 서버 상태 확인을 대신하지 않으며 값만 늘려서는 연결할 수 없는 원격 주소를 복구할 수 없습니다.
{
"policy": {
"levels": {
"0": {
"handshake": 4,
"connIdle": 300,
"uplinkOnly": 2,
"downlinkOnly": 5
}
}
}
}시간 설정을 조정할 때의 영향
유휴 시간 제한을 너무 짧게 설정하면 데이터가 잠시 없는 연결이 일찍 종료될 수 있습니다. 너무 길게 설정하면 끊어진 연결이 더 오랫동안 리소스를 점유할 수 있습니다. 장시간 연결을 사용하는 애플리케이션에 미치는 영향은 애플리케이션의 하트비트와 서버 시간 제한, 네트워크 기기 상태에도 달려 있습니다. 연결이 끊기는 문제를 해결할 때는 마지막으로 정상적인 데이터가 오간 시점부터 연결이 종료될 때까지의 시간을 기록하고 같은 간격으로 반복되는지 확인하세요. 한 번 연결이 끊겼다는 이유로 모든 시간 제한을 늘리면 문제를 찾을 수 없고 실제 실패 연결의 정리만 늦어질 수 있습니다.
핸드셰이크 시간 초과도 어느 단계에서 발생했는지 함께 살펴봐야 합니다. 네트워크 혼잡, 서버 응답 지연, 인증 불일치 모두 핸드셰이크가 제시간에 완료되지 않는 원인이 될 수 있지만 해결 방법은 서로 다릅니다. 대기 시간을 늘리면 허용 범위만 넓어질 뿐 잘못된 사용자 매개변수나 일치하지 않는 전송 설정은 고쳐지지 않습니다. 실행 로그로 실패 단계를 확인한 다음 소폭 조정할지 판단하세요. 변경 후 ‘빠르게 실패’하던 문제가 ‘오래 기다린 뒤 실패’로 바뀌기만 했다면 원래 값으로 되돌리고 주소와 프로토콜, 보안 계층을 점검하세요.
필요한 수준의 로그부터 사용하세요
log는 최상위 설정이며 loglevel에서 현재 코어가 지원하는 로그 수준을 선택합니다. 평소에는 warning 또는 error를 확인하고, 문제를 찾을 때는 일시적으로 info로 올리세요. 더 자세한 정보가 필요할 때만 짧은 시간 동안 debug를 사용하세요. 로그 수준을 높여도 연결 속도가 빨라지지는 않으며 로그에 접속 대상, 로컬 경로, 사용자 식별 정보가 포함될 수 있습니다. 문제 해결 기록을 공유하기 전에는 구독 주소와 인증 정보, 개인을 식별할 수 있는 내용을 삭제하세요. 마지막 ‘실패’ 문구만 캡처하는 것보다 오류 원문과 발생 순서를 보존하는 편이 도움이 됩니다.
{
"log": {
"loglevel": "info"
}
}access 및 error 파일 경로를 명시적으로 설정한다면 실행 계정에 쓰기 권한이 있는지, 디렉터리가 존재하는지, 디스크 공간이 충분한지도 확인하세요. 데스크톱 클라이언트가 이미 로그 출력을 관리하고 있을 수 있어 직접 지정한 경로가 클라이언트 로그 패널에 표시되지 않을 수도 있습니다. 상대 경로는 프로세스의 작업 디렉터리를 기준으로 하므로 편집기가 있는 디렉터리를 기준으로 판단해서는 안 됩니다. 평소에 로그가 지나치게 쌓이지 않도록 문제를 찾은 뒤에는 로그 수준을 낮추고, 접속 기록이 포함된 파일은 정한 보존 기간에 맞춰 정리하세요.
통계 옵션은 모니터링 화면이 아닙니다
stats와 policy의 통계 옵션은 api의 통계 조회 기능과 함께 동작합니다. 옵션 하나만 켠다고 데스크톱에 그래프가 자동으로 표시되지는 않습니다. 인바운드, 아웃바운드, 사용자 통계는 적용 범위가 서로 다르며 사용자 통계에는 프로토콜 사용자 식별 필드가 필요할 수도 있습니다. 클라이언트에 트래픽 통계 기능이 있다면 먼저 해당 인터페이스를 이용하세요. 숫자를 표시하려고 관리 인터페이스를 추가로 노출하지 마세요. 통계는 특정 지점에서 집계된 값이며 통신사 과금 트래픽이나 애플리케이션의 실제 파일 크기와 일치하지 않을 수 있습니다.
‘최적화’ 효과를 평가할 때는 같은 애플리케이션과 서버, 테스트 대상을 사용하세요. 먼저 기존 설정의 결과를 기록한 뒤 정책 하나만 바꾸세요. 처리량은 노드 부하와 회선, 프로토콜, 애플리케이션의 동시 요청 수, 기기 성능이 함께 좌우합니다. policy의 시간 값 몇 개로 전체 연결 속도가 결정되지는 않습니다. 연결은 안정적인데 다운로드가 느리다면 속도 저하를 단계별로 확인하는 방법을 참고해 노드와 회선, 로컬 설정을 구분하세요. 시간 제한을 계속 줄이거나 모든 통계 옵션을 켜는 방식은 피하세요.
설정 검증, 이전, 롤백
재현 가능한 변경 기록을 남기세요
설정을 바꾸기 전에 현재 정상적으로 작동하는 상태를 저장하고 해결하려는 문제를 구체적으로 기록하세요. 예를 들면 ‘특정 애플리케이션이 프록시를 사용하지 않음’, ‘한 도메인이 잘못된 출구에 연결됨’, ‘네트워크 전환 후 이름 해석 실패’ 등이 있습니다. 각 문제는 인바운드, 라우팅, DNS에 해당하므로 구독 전체를 다시 가져오는 방식으로 한꺼번에 해결해서는 안 됩니다. 클라이언트와 실제 실행 코어, 트래픽 처리 방식, 변경 필드를 기록하면 충분하며 인증 정보를 복사할 필요는 없습니다. 사본에 비공개 서버 정보가 포함될 수 있으니 공개된 위치에 업로드하지 마세요.
수동 JSON 검증은 최소한 세 단계로 진행해야 합니다. 문법 파싱, 코어의 필드 수용 여부, 실제 동작입니다. 문법 단계에서는 괄호와 따옴표, 쉼표, 데이터 유형을 확인합니다. 코어 단계에서는 필드 지원 여부와 태그 참조, 리소스 로드를 점검합니다. 동작 단계에서는 실제 애플리케이션이 예상한 인바운드로 들어와 올바른 출구를 이용하는지 확인합니다. 앞의 두 단계가 통과해도 세 번째까지 성공한다는 보장은 없습니다. 반대로 웹페이지 하나가 우연히 열렸다고 설정 전체가 올바른 것도 아닙니다. 직접 연결이나 캐시의 영향일 수 있으므로 실제 경로를 확인해야 합니다.
정해진 순서로 시작하고 테스트하세요
로컬 포트 충돌을 방지하려면 중복 실행 중인 클라이언트나 테스트 프로세스를 먼저 종료하세요. 설정을 불러온 뒤 시작 로그에서 문법 오류와 알 수 없는 필드, 누락된 규칙 데이터, 리스닝 실패가 없는지 확인하고 애플리케이션에서 특정 요청을 보냅니다. 시작에 실패했다면 라우팅 모드를 계속 바꾸지 마세요. 정상적으로 시작했는데 접속 기록이 없다면 먼저 애플리케이션 인바운드를 확인하세요. 기록은 있지만 잘못된 태그로 연결된다면 라우팅 순서를 살펴보세요. 이 순서를 따르면 ‘요청을 받지 못함’과 ‘요청을 받은 뒤 잘못 처리함’을 구분할 수 있습니다.
- 원래 설정을 보관하고 사본에서 필드 그룹 하나만 변경한 뒤 예상 결과를 기록하세요.
- 사본을 불러와 파싱 결과와 태그 참조, 규칙 데이터, 포트 리스닝 상태를 확인하세요.
- 고정된 테스트 대상으로 요청을 보내고 로그의 대상 정보와 아웃바운드 태그를 확인하세요.
- 영향을 받지 않아야 하는 대상도 테스트해 예외 규칙의 적용 범위가 넓어지지 않았는지 확인하세요.
- 평소 사용하는 애플리케이션과 기존 로그 수준으로 되돌린 뒤 클라이언트를 다시 시작해도 변경 사항이 유지되는지 확인하세요.
테스트 대상은 실제 요구 사항을 반영하면 되며 모든 웹사이트를 한 번에 시험할 필요는 없습니다. 최소한 직접 연결될 대상 하나와 원격 아웃바운드를 거칠 대상 하나를 포함하세요. 로컬 네트워크를 사용한다면 내부 서비스도 추가합니다. 페이지가 열리는지만으로 판단하지 마세요. 브라우저 캐시와 기존 연결, 앱 자체 프록시가 결과에 영향을 줄 수 있습니다. 라우팅이나 DNS를 바꾼 뒤에는 해당 앱을 종료하고 다시 열어 새 요청이 새 설정을 통과하도록 하세요. 캐시를 지워야 한다면 비교 조건이 달라지지 않도록 삭제 범위도 기록하세요.
복구 가능한 오류와 호환성 문제를 구분하세요
unknown field와 같은 메시지가 나오면 먼저 설정 형식이 현재 코어에 맞는지 확인한 다음 필드 철자와 위치를 살펴보세요. address already in use 오류가 나면 서버를 바꾸지 말고 중복 실행 프로세스와 포트를 확인해야 합니다. 인증서 오류는 시간과 서비스 이름, 인증서 체인을 확인하세요. 규칙 데이터 읽기 오류는 클라이언트가 파일을 제대로 관리하고 있는지 살펴보세요. 오류 문구는 코어마다 다를 수 있지만 ‘실패 단계부터 확인하고 해당 필드를 수정한다’는 원칙은 같습니다.
| 증상 | 먼저 확인 | 우선 수정하지 않을 항목 |
|---|---|---|
| 코어가 시작되지 않음 | JSON, 필드 호환성, 리스닝 포트 | 웹사이트 도메인 규칙 |
| 애플리케이션 접속 기록이 없음 | 시스템 프록시, 애플리케이션 인바운드, 트래픽 처리 범위 | 원격 인증 사용자 |
| 예상과 다른 아웃바운드로 연결됨 | 규칙 순서, 대상 형식, tag 참조 | TLS 인증서 검증 |
| 재시작 후 변경 사항이 사라짐 | 생성된 설정과 저장 설정의 차이 | 네트워크 경로 |
v2rayN에서 v2rayNG로 이전할 때는 먼저 지원되는 서버 정보를 옮긴 다음 모바일에서 앱별 프록시와 라우팅을 다시 설정하세요. 데스크톱 시스템 프록시와 파일 경로, 창 설정은 코어 설정처럼 그대로 옮길 수 없습니다. v2flyNG로 이전한다면 V2Fly 코어가 기존 서버에 필요한 프로토콜과 전송을 지원하는지도 확인해야 합니다. 구독을 읽을 수 있다는 사실은 가져오기 형식을 인식했다는 뜻일 뿐, 모든 항목을 대상 코어에서 실행할 수 있다는 보장은 아닙니다. 이전 후에는 동일한 점검 절차에 따라 다시 검증하세요.
클라이언트에서 공유 링크와 전체 설정, 백업 데이터를 내보낼 수 있더라도 각 파일의 용도를 먼저 확인하세요. 공유 링크는 보통 단일 서버 정보를 담으며 라우팅과 DNS, 시스템 설정 전체를 보존하지 않습니다. 백업에는 더 많은 앱 데이터가 포함될 수 있고 복원 시 영향 범위도 커집니다. 문제 해결을 위해 다른 사람에게 내보낸 파일을 보낼 때는 서버 인증 정보와 구독 내용을 삭제하세요. 규칙 문제만 설명하면 된다면 routing과 관련 태그 정의, 개인 정보를 제거한 로그만 별도로 제공하세요. 전체 백업을 여러 곳에 전달하지 않는 편이 안전합니다.
롤백은 예전 텍스트를 다시 붙여 넣는 것만으로 끝나지 않습니다. 시스템 프록시와 기존 코어 선택, 로그 수준, 애플리케이션 인바운드도 복구해야 합니다. 로컬 네트워크 리스닝이나 관리 인터페이스를 추가했다면 그것도 함께 해제하세요. 롤백 후 다시 시작해 기존 대상이 정상적으로 작동하는지 확인하고 기준 설정이 복구된 것을 검증한 뒤 다음 변경을 시도하세요. 평소 사용 방법을 점검하려면 입문 가이드의 기본 절차를 따르세요. 다른 플랫폼용 클라이언트가 필요하다면 클라이언트 다운로드 페이지를 이용하세요. 출처가 불분명한 설정 조각을 쌓아 두기보다 언제든 작동을 확인할 수 있는 기준 설정을 보관하는 편이 장기적으로 관리하기 쉽습니다.