JSON 구조 및 설정 출처
먼저 설정을 누가 생성하는지 확인한 뒤 어디를 수정할지 결정하세요. v2rayN, v2rayNG, v2flyNG는 노드, 구독, 라우팅, 로컬 설정을 커널 실행에 필요한 형태로 구성하는 GUI 클라이언트입니다. 클라이언트 화면에 저장된 정보, 구독에서 받은 데이터, 실제 실행되는 JSON은 서로 다른 계층에 속합니다. 구독 링크는 설정 파일이 아니며 클라이언트 데이터베이스도 커널 설정과 같지 않습니다. 문제를 진단할 때는 과거에 내보낸 파일만 확인하지 말고 현재 연결에서 실제로 사용하는 설정을 찾아야 합니다.
최상위 객체와 요청 경로
일반적인 설정은 객체 하나를 루트로 사용합니다. 객체의 키는 기능 모듈을 나타내며, 모듈 값은 객체나 배열일 수 있습니다. inbounds와 outbounds는 배열입니다. 하나의 프로세스가 여러 인바운드와 아웃바운드를 동시에 제공할 수 있기 때문입니다. 반면 routing은 객체이며, 그 안의 rules가 순서가 있는 규칙 배열입니다. 필드의 계층을 이해하는 것이 순서를 외우는 것보다 중요합니다. 최상위 키는 대체로 작성 순서에 영향을 받지 않지만 라우팅 규칙과 아웃바운드 배열은 실제 동작을 바꿀 수 있습니다.
{
"log": {
"loglevel": "warning"
},
"inbounds": [],
"outbounds": [],
"routing": {
"domainStrategy": "AsIs",
"rules": []
},
"dns": {
"servers": ["localhost"]
},
"policy": {
"levels": {}
}
}위 내용은 구조의 뼈대일 뿐, 트래픽을 전달할 수 있는 설정은 아닙니다. 비어 있는 인바운드에는 요청을 받을 포트가 없고, 비어 있는 아웃바운드에는 전달 대상이 없습니다. 일반적으로 요청은 “애플리케이션 → 인바운드 → 라우팅 → 아웃바운드” 순서로 흐릅니다. DNS는 이 과정에서 도메인을 조회할 수 있고, 로그는 진행 중 발생한 이벤트를 기록하며, policy는 연결 리소스와 타임아웃에 영향을 줍니다. 각 모듈은 서로 독립적인 스위치가 아닙니다. 철자가 맞더라도 참조되지 않은 아웃바운드 태그가 트래픽을 자동으로 처리하지는 않습니다.
문법상 올바른 설정과 의미상 올바른 설정
표준 JSON의 키와 문자열에는 영문 큰따옴표를 사용하고, 불리언 값은 소문자 true, false로 씁니다. 숫자는 보통 따옴표로 감싸지 않습니다. 배열이나 객체의 마지막 항목 뒤에는 쉼표를 붙일 수 없으며, 설명 문구를 코드 안에 직접 넣어서도 안 됩니다. 일부 구현은 확장 문법을 지원하지만 클라이언트 간에 설정을 복사할 때는 표준 JSON을 사용하는 편이 안전합니다. 중복 키는 특히 혼동을 일으키기 쉽습니다. 파서에 따라 서로 다른 값이 남을 수 있으므로 객체 하나에는 같은 이름의 필드를 하나만 두세요.
문법 검사를 통과했다는 것은 괄호, 타입, 문자가 올바르다는 뜻일 뿐 프로토콜 매개변수까지 사용할 수 있다는 뜻은 아닙니다. 커널은 프로토콜 이름, 지원 필드, 태그 참조, 리스너 리소스도 확인합니다. 실행에 성공해도 원격 주소, 인증 정보, 전송 매개변수가 서로 맞지 않으면 연결이 실패할 수 있습니다. “파일 파싱”, “프로세스 실행”, “요청 전달”, “규칙대로 처리”를 서로 다른 네 가지 확인 단계로 보고 차례로 검증하세요. 웹페이지 한 번 접속한 결과만으로 전체 상태를 판단하지 마세요.
| 설정 섹션 | 주요 역할 | 우선 확인할 항목 |
|---|---|---|
inbounds | 애플리케이션 요청 수신 | 리스닝 주소, 포트, 프로토콜 |
outbounds | 전달 또는 차단 처리 | 아웃바운드 유형, 태그, 원격 매개변수 |
routing | 조건에 따라 출구 선택 | 규칙 순서, 태그 참조 |
dns | 내장 도메인 조회 제공 | 조회 경로, 조회 결과 |
policy | 연결 리소스와 타이머 제어 | 레벨 연결, 타임아웃 범위 |
커널별 차이와 수정 범위
Project V는 관련 도구 생태계의 배경이며 V2Fly와 Xray는 각각 구분해야 하는 커널 구현체입니다. 설정 개념은 일부 공유하지만 모든 새 필드, 전송 조합, 기본값이 동일하다고 볼 수는 없습니다. 특히 REALITY 같은 확장 기능은 실제 사용하는 커널에 맞는 필드로 설정해야 합니다. 특정 구현에만 해당하는 설정 섹션을 다른 구현의 파일에 그대로 합치지 마세요. 이 핸드북의 예제는 일반적인 기본 구조를 사용하며, 확장 기능을 다룰 때는 클라이언트에서 현재 어떤 커널을 선택했는지 먼저 확인하세요.
GUI 클라이언트는 노드 전환, 구독 업데이트, 재연결 시 설정을 생성하는 경우가 많습니다. 임시 생성 파일을 직접 수정하면 다음 작업에서 덮어써질 수 있습니다. 변경 사항을 장기간 유지해야 한다면 클라이언트에서 제공하는 라우팅, DNS 또는 사용자 지정 설정 입력란을 우선 이용하고, 해당 설정이 어떻게 병합되는지 확인하세요. 수정 전에 원본을 별도로 저장하고 변경 필드와 예상 결과를 기록하세요. 한 번에 한 계층만 변경해야 문제가 생겼을 때 정확히 되돌릴 수 있습니다. 클라이언트를 처음 선택한다면 클라이언트 및 플랫폼 다운로드 페이지를 참고하세요.
log 로그와 확인 방법
로그는 특정 실행에서 어떤 일이 있었는지 설명하는 자료이지, 모든 연결이 정상이라는 증거는 아닙니다. 설정 실행에 실패하면 먼저 오류 로그를 확인하세요. 애플리케이션이 로컬 포트에는 연결되지만 요청을 완료하지 못한다면 액세스 기록, 대상 주소, 아웃바운드 동작을 함께 살펴보세요. 커널 로그, 클라이언트 화면의 로그, 시스템 서비스 로그는 서로 다른 프로세스에서 생성될 수 있으며 표시 시각과 상세 수준도 다릅니다. 두 기록을 비교하기 전 같은 실행 세션에서 나온 것인지 확인해 과거 오류를 현재 문제로 오인하지 않도록 하세요.
로그 수준과 출력 위치
loglevel은 오류 관련 로그의 상세 수준을 제어합니다. 일반적인 값은 debug, info, warning, error, none입니다. 평소에는 적절히 낮은 수준을 유지하고 문제를 재현할 때만 잠시 높이는 것이 좋습니다. 상세 수준을 높이면 확인할 정보가 늘어날 뿐 규칙 매칭이 바뀌거나 핸드셰이크 문제가 해결되지는 않습니다. 특정 애플리케이션에서만 문제가 발생한다면 모든 연결을 장시간 기록하기보다 재현 범위를 먼저 좁히세요.
{
"log": {
"access": "./access.log",
"error": "./error.log",
"loglevel": "warning"
}
}이 설정은 최상위 객체에 병합해야 합니다. 두 경로 모두 상대 경로이며 실제 파일 위치는 프로세스의 작업 디렉터리에 따라 달라집니다. JSON 파일이 있는 디렉터리를 기준으로 한다고 보장할 수 없습니다. 데스크톱 클라이언트를 바로가기로 실행하거나 서비스 또는 터미널에서 시작하면 작업 디렉터리가 달라질 수 있습니다. 파일을 찾지 못하면 먼저 실행 방식과 디렉터리 권한을 확인하고, 그다음 로그가 비활성화되어 있는지 살펴보세요. 로그 수준을 계속 높이는 것보다 쓰기 가능한 경로로 바꾸는 편이 직접적인 해결책입니다. 이를 위해 프로그램 디렉터리 전체의 접근 권한을 확대하지 마세요.
클라이언트가 이미 커널 출력을 수집한다면 파일을 별도로 지정할 필요는 없습니다. 파일을 지정하지 않았을 때의 출력 위치는 실제 커널과 실행 방식에 따라 확인해야 합니다. 일부 화면은 요약만 표시하고, 일부는 액세스 로그를 별도로 켤 수 있습니다. 파일 크기가 계속 커진다면 실행 환경에서 로그 순환이나 정리 방식을 마련해야 합니다. 커널이 자동으로 크기를 제한한다고 가정하지 마세요. 로그 보존 기간은 문제 해결에 필요한 만큼만 설정하고, 재현을 마치면 원래 수준으로 되돌려 장기간 기록으로 디스크가 가득 차지 않도록 하세요.
시간순으로 최소한의 증거 확보하기
문제를 제대로 재현하려면 시작과 종료 시점을 분명히 해야 합니다. 먼저 기존 연결을 종료하고 재시작 시각을 기록한 뒤, 확인된 주소 하나로 요청을 한 번 보냅니다. 인바운드 수신, 대상 식별, 규칙 선택, 아웃바운드 오류가 나타나는지 살펴보세요. 구현체에 따라 이 항목을 모두 로그로 출력하지 않을 수 있으므로 모든 로그가 같은 문구를 사용하리라 기대하지 마세요. 핵심은 시각, 대상, 결과를 연결하는 것입니다. 여러 페이지를 연속으로 새로고침하면 사전 연결, 백그라운드 요청, 캐시가 섞여 기록을 요청별로 구분하기 어려워집니다.
일반적인 오류는 발생 계층을 기준으로 살펴볼 수 있습니다. 리스닝 실패는 포트 충돌, 존재하지 않는 주소, 권한 문제와 관련된 경우가 많습니다. 도메인 조회 실패는 조회 경로를, 원격 연결 타임아웃은 대상에 대한 네트워크 접근성과 전송 조건을 가리킬 수 있습니다. 인증 또는 핸드셰이크 오류가 발생하면 서버와 클라이언트 매개변수를 비교해야 합니다. 최종 타임아웃 메시지만으로 어느 계층에서 문제가 생겼는지 단정할 수는 없습니다. 마지막 줄만 복사하지 말고 그보다 앞에 나온 첫 번째 의미 있는 오류를 찾으세요. 재시도로 반복된 메시지를 서로 다른 원인으로 세지 마세요.
로그가 없는 경우와 트래픽이 유입되지 않은 경우 구분하기
액세스 기록이 없다면 먼저 애플리케이션이 실제로 해당 인바운드를 사용하는지 확인하세요. 브라우저는 시스템 프록시 설정을 읽을 수 있지만 명령줄 도구는 자체 매개변수만 사용할 수 있습니다. 기존 연결이 이전 경로를 계속 사용할 수도 있습니다. 테스트할 때 연결을 새로 만들고 프록시 주소를 명시하면 변수 수를 줄일 수 있습니다. 애플리케이션 요청이 커널에 들어오지 않았다면 아웃바운드, DNS, 라우팅을 바꿔도 결과는 달라지지 않습니다. 시스템 프록시와 커널 라우팅의 역할 차이는 시스템 프록시와 라우팅 모드 설명을 참고하세요.
요청이 들어오는 것이 확인됐는데 기록된 아웃바운드가 예상과 다르다면 라우팅 장으로 이동해 규칙 순서와 태그를 확인하세요. 아웃바운드가 맞는데 일부 대상만 실패한다면 대상이 다른 주소 계열, 전송 프로토콜, 도메인 조회 경로를 사용하는지 비교하세요. 로그는 관찰 단서이므로 재현 가능한 테스트와 함께 분석해야 합니다. 성공 기록과 실패 기록을 하나씩 저장해 차이를 비교하면 포트, 조회기, 라우팅 모드를 동시에 바꾸는 것보다 실제 변화 원인을 찾기 쉽습니다.
inbounds 로컬 인바운드
인바운드는 커널이 요청을 받는 위치와 애플리케이션에서 전달된 데이터를 해석하는 프로토콜을 정의합니다. 데스크톱 환경에서는 로컬 SOCKS 또는 HTTP 인바운드가 흔합니다. 포트는 인바운드의 번호일 뿐, 아웃바운드가 원격 노드를 거치는지 결정하지 않으며 모든 애플리케이션이 자동으로 프록시를 사용하게 하지도 않습니다. 애플리케이션이 해당 포트에 직접 연결하거나 시스템 프록시 같은 인입 방식으로 요청을 전달해야 합니다. 문제를 진단하기 전에 애플리케이션이 요구하는 프로토콜을 확인하세요. SOCKS 포트를 HTTP 프록시만 받는 설정란에 임의로 입력하면 안 됩니다.
리스닝 주소, 포트, 태그
listen은 바인딩 주소를, port는 리스닝 포트를, protocol은 인바운드 프로토콜을 결정합니다. tag는 이후 설정에서 인바운드를 참조할 때 사용합니다. 로컬에서만 사용할 경우 127.0.0.1을 명시해 접근 범위를 제한할 수 있습니다. 이 주소는 로컬 IPv4 루프백을 뜻하며 모든 인터페이스나 IPv6 루프백과는 다릅니다. 애플리케이션이 다른 주소 계열로 연결한다면 양쪽 주소를 확인하세요. “localhost”라는 이름만 보고 연결 위치를 판단하지 마세요.
{
"inbounds": [
{
"tag": "local-socks",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": true
},
"sniffing": {
"enabled": true,
"destOverride": ["http", "tls"]
}
}
]
}이 예제는 로컬 애플리케이션에서 인증 없이 SOCKS 인바운드를 사용하고 UDP 전달 기능을 켭니다. 여기서 udp를 켠다고 시스템의 모든 UDP 트래픽이 가로채지는 않습니다. 애플리케이션이 SOCKS의 관련 기능을 사용해야 하며 아웃바운드도 해당 트래픽을 처리할 수 있어야 합니다. 웹페이지 테스트가 성공해도 현재 TCP 요청이 전달됐다는 사실만 확인할 수 있습니다. 음성 통화, 실시간 통신, 기타 UDP 애플리케이션까지 정상이라고 판단할 수는 없습니다. 차이가 있다면 애플리케이션 지원, 인바운드 기능, 아웃바운드 경로를 각각 점검하세요.
LAN 접근과 보안 범위
LAN 연결을 허용하는 일은 리스닝 주소를 0.0.0.0으로 바꾸는 것만으로 끝나지 않습니다. 호스트 방화벽, 네트워크 인터페이스, 인증 방식, 허용할 출처도 고려해야 합니다. 모든 인터페이스에 바인딩하면 접근 가능한 범위가 넓어지고, 다른 네트워크로 이동할 때마다 노출 범위도 달라집니다. 특정 LAN 인터페이스만 필요하다면 해당 인터페이스 주소에 바인딩하고 방화벽으로 출처를 제한할 수 있습니다. 명확한 공유 목적이 없다면 루프백 리스닝을 유지하는 편이 관리하기 쉽고 다른 기기가 로컬 인바운드를 잘못 사용하는 것도 방지할 수 있습니다.
같은 주소와 전송 유형의 포트는 여러 프로세스가 동시에 점유할 수 없습니다. 클라이언트가 백그라운드에 남아 있거나 다른 도구가 같은 포트를 사용하거나 설정 두 개를 동시에 실행하면 바인딩에 실패할 수 있습니다. 먼저 불필요한 인스턴스를 종료하고 포트를 점유한 프로세스를 확인한 뒤 포트를 바꿀지 결정하세요. 인바운드 포트를 변경했다면 애플리케이션 프록시 설정과 시스템 프록시도 함께 갱신해야 합니다. JSON만 수정하고 프록시 주소를 그대로 두면 프로토콜 핸드셰이크 오류가 아니라 연결 거부가 나타나는 경우가 많습니다.
스니핑을 통한 대상 식별 및 덮어쓰기
스니핑은 요청 내용에서 도메인 등의 대상 정보를 식별하려고 시도합니다. 예를 들어 애플리케이션이 도메인을 IP로 조회한 뒤 인바운드에 IP 대상 요청을 보내더라도 HTTP 헤더나 TLS 핸드셰이크 정보로 도메인을 복원할 수 있습니다. 이를 통해 도메인 규칙으로 라우팅할 수 있지만 실제 프로토콜 내용에 따라 식별 가능성이 달라집니다. 암호화된 모든 트래픽에서 도메인을 알아낼 수 있는 것은 아닙니다. 식별할 정보가 없거나 특수한 핸드셰이크를 사용하거나 지원 범위를 벗어난 프로토콜이면 IP나 다른 조건만으로 라우팅할 수 있습니다.
destOverride는 식별 결과가 대상에 미치는 영향과 관련됩니다. “도메인을 식별하는 것”과 “라우팅에만 사용하는 것”을 같은 의미로 취급하면 안 됩니다. 커널마다 제어 필드와 기본 동작이 다를 수 있습니다. 매칭에만 영향을 주고 연결 대상을 바꾸지 않으려면 실제 구현에서 지원하는 관련 기능을 확인한 뒤 설정하세요. 스니핑을 켠 뒤 접속 결과가 달라졌다면 같은 대상을 대상으로 스니핑을 켠 경우와 끈 경우를 각각 테스트하고 대상 및 규칙 변화를 관찰하세요. 노드와 DNS를 동시에 바꾸지 마세요.
여러 인바운드를 서로 다른 용도로 사용할 수 있습니다. 예를 들어 테스트 요청에만 별도의 태그를 지정하고 inboundTag로 전용 아웃바운드를 가리킬 수 있습니다. 태그는 논리적인 이름일 뿐 포트를 만들거나 시스템 프록시를 자동으로 켜지는 않습니다. 이름에 용도를 드러내고 구분하기 어려운 번호를 많이 사용하지 않도록 구성하세요. 리스닝을 확인한 뒤 스니핑과 트래픽 분배를 추가하면 인바운드 문제와 후속 정책 문제를 분리할 수 있습니다. GUI의 기본 조작은 빠른 시작 절차를 참고하세요.
outbounds 아웃바운드 선택
아웃바운드는 요청이 선택된 뒤 어떻게 처리할지 결정합니다. 대상에 직접 연결하거나 지정된 프록시 프로토콜로 원격 서버에 전달하거나 연결을 거부할 수 있습니다. 아웃바운드는 단순히 “노드 목록”을 뜻하지 않습니다. 직결과 차단도 아웃바운드에 포함되지만 원격 서버가 필요하지 않습니다. 설정에 아웃바운드가 여러 개 있어도 기본 경로로 사용되거나 라우팅에서 참조되는 항목만 요청 처리에 참여합니다. 먼저 요청이 어떤 아웃바운드를 선택했는지 확인한 다음 해당 출구의 매개변수를 살펴보면 문제 해결 순서가 분명해집니다.
기본 아웃바운드와 기본 동작
일반적인 설정에서는 라우팅 규칙이 특정 출구를 선택하지 못하면 아웃바운드 배열의 첫 번째 항목을 기본 출구로 사용합니다. 따라서 배열 순서를 바꾸면 어떤 출구로 전달될지 달라질 수 있습니다. 기본 출구의 용도를 명확히 기록하고 참조해야 하는 아웃바운드마다 고유한 태그를 지정하세요. 태그는 설정 안에서 일관되게 사용해야 하며 대소문자와 문자도 정확히 일치해야 합니다. 태그가 화면에 표시되는 이름과 반드시 같지는 않으며 노드 메모만 보고 실제 생성된 태그를 추측할 수도 없습니다.
{
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {
"domainStrategy": "AsIs"
}
},
{
"tag": "block",
"protocol": "blackhole",
"settings": {}
}
]
}예제에서는 직결을 첫 번째에 두었으므로 별도 규칙에 걸리지 않은 요청은 로컬 네트워크를 통해 직접 나갑니다. blackhole은 차단 처리를 뜻하며 라우팅이 block을 가리킬 때만 사용됩니다. 백업 경로가 아니며 직결 실패 시 자동으로 요청을 넘겨받지도 않습니다. 배열에 아웃바운드 두 개를 적었다고 장애 조치 기능이 만들어지는 것은 아닙니다. 부하 분산, 상태 확인, 체인 연결은 별도 설정 기능이므로 지원 여부를 확인하고 명시적으로 구성해야 합니다.
프로토콜 매개변수와 전송 매개변수 분리하기
원격 프록시 아웃바운드에는 보통 프로토콜 계층 설정과 전송 계층 설정이 함께 들어갑니다. 프로토콜 계층은 서버, 포트, 인증, 프로토콜 기능을 지정하고 전송 계층은 하위 연결 방식과 보안 매개변수를 지정합니다. 서버와 클라이언트의 주요 필드는 서로 일치해야 합니다. 원격 포트에 연결할 수 있다는 사실은 네트워크 계층에서 연결을 만들 수 있다는 뜻일 뿐, 인증과 전송 조합이 올바르다는 뜻은 아닙니다. 핸드셰이크가 실패한다면 모든 필드를 익숙한 기본값으로 바꾸지 말고 제공받은 전체 매개변수와 대조하세요.
VMess, VLESS, Trojan, Shadowsocks는 인증 구조와 기능이 서로 다르므로 protocol 이름만 바꿔 서로 전환할 수 없습니다. TLS와 REALITY 조합도 커널의 지원 범위를 고려해야 합니다. 프로토콜 선택은 네 가지 프록시 프로토콜의 사용 사례 비교를 먼저 참고하세요. 이 페이지는 임의의 원격 인증 정보를 넣은 “만능 노드”를 제공하지 않습니다. 전체 실험 설정에서 직결 아웃바운드를 사용하는 이유는 로컬 구조 문제를 분리하기 위해서이며 실제 원격 연결을 재현하기 위한 것이 아닙니다.
도메인 대상과 연결 처리 주체
아웃바운드가 받은 도메인을 로컬에서 조회할지, 내장 DNS로 조회할지, 원격으로 전달할지는 아웃바운드 프로토콜과 관련 설정에 따라 달라집니다. freedom의 domainStrategy와 routing.domainStrategy는 이름은 비슷하지만 서로 다른 계층의 설정입니다. 앞의 설정은 직결 아웃바운드가 도메인 대상을 처리하는 방식을, 뒤의 설정은 라우팅 매칭에서 조회를 수행할지를 다룹니다. 라우팅 정책을 IP 조회 방식으로 바꿔도 모든 출구가 같은 조회 절차를 사용하도록 바뀌지는 않습니다.
아웃바운드가 여러 개라면 최종 접속 대상과 프록시 서버 자체의 주소도 구분해야 합니다. 서버의 도메인도 조회하고 연결해야 합니다. 서버에 도달하는 트래픽을 그 서버에 의존하는 경로로 다시 보내면 순환 의존이 생길 수 있습니다. GUI 클라이언트는 필요한 제외 또는 직결 로직을 처리하는 경우가 많지만 사용자 지정 설정에서는 시작 연결을 어디서부터 수립하는지 명확히 분석해야 합니다. 핸드셰이크가 완료되기 전에 반복적으로 타임아웃이 발생한다면 서버 주소 조회, 하위 네트워크 연결, 출구 선택부터 확인하세요.
| 관찰된 현상 | 먼저 확인할 항목 | 성급히 단정하지 말 것 |
|---|---|---|
| 로컬 연결은 되지만 원격 접속 실패 | 아웃바운드 태그, 서버 매개변수, 전송 조건 | DNS 문제라고 단정할 수 없음 |
| 규칙이 매칭되지 않음 | 기본 아웃바운드와 배열 순서 | 모든 출구를 차례대로 자동 시도하지 않음 |
| 직결은 되지만 프록시는 실패 | 원격 경로와 프로토콜 조합 | 인바운드 설정 오류를 의미하지는 않음 |
노드 매개변수를 수정할 때는 구독 업데이트 후 수동 내용이 덮어써지지 않도록 클라이언트의 노드 편집 기능을 우선 이용하세요. 아웃바운드 태그를 고정해야 하는 사용자 지정 규칙은 클라이언트가 생성하는 태그가 안정적인지, 노드를 전환한 뒤에도 참조가 유지되는지 확인해야 합니다. 클라이언트가 태그를 다시 생성한다면 실행 파일을 복사하는 것보다 클라이언트에서 제공하는 라우팅 설정을 사용하는 편이 일반적으로 더 안정적입니다. 정상 작동이 확인된 기본 설정을 비교 대상으로 보관하면 “아웃바운드 자체의 실패”와 “라우팅 선택 오류”를 각각 검증할 수 있습니다.
routing 규칙 매칭
라우팅은 규칙 순서대로 요청을 검사한 뒤 매칭 결과를 지정된 아웃바운드에 전달합니다. 시스템 프록시 스위치가 아니며 커널에 들어오지 않은 애플리케이션 트래픽을 끌어오지도 않습니다. 규칙이 올바른데도 애플리케이션이 원래 네트워크를 사용한다면 먼저 인바운드를 확인하세요. 요청은 커널에 들어왔지만 출구가 잘못됐다면 규칙 순서, 매칭 필드, 태그 참조를 점검해야 합니다. 인바운드에서 요청을 받아들이는 것과 커널에서 전달 경로를 정하는 것을 구분해야 “전역” 및 “중국 본토 우회” 같은 화면 모드를 제대로 분석할 수 있습니다.
순서, 조건, 대상 정보
하나의 규칙 안에 있는 서로 다른 조건은 보통 모두 충족해야 합니다. 예를 들어 인바운드 태그를 지정하면서 포트도 제한할 수 있습니다. 같은 유형의 배열에 있는 여러 후보는 그중 하나가 매칭되면 됩니다. 규칙이 한 번 적용되면 뒤에 있는 일반 규칙이 이를 다시 덮어쓰지 않습니다. 넓은 범위의 규칙은 정확한 예외 규칙보다 뒤에 배치해야 합니다. 그렇지 않으면 예외가 적용될 기회가 없습니다. 도메인 조건은 사용할 수 있는 도메인 정보가 있어야 하고 IP 조건은 대상 주소나 조회 결과가 필요합니다. IP만 있는 요청이 도메인 목록과 자동으로 매칭되리라 기대해서는 안 됩니다.
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"domain": ["full:blocked.example"],
"outboundTag": "block"
},
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"inboundTag": ["local-socks"],
"network": "tcp,udp",
"outboundTag": "direct"
}
]
}
}예제는 먼저 테스트 전용 도메인을 차단하고, 다음으로 사설 주소를 처리한 뒤 지정된 인바운드의 나머지 TCP 및 UDP 요청을 직결로 보냅니다. blocked.example은 예제용 도메인이며 교체해야 하는 인증 정보가 아닙니다. 여기의 두 아웃바운드 태그는 앞 장에서 정의한 이름과 일치해야 합니다. 세 번째 규칙은 범위가 넓으므로 특정 대상에 예외를 추가하려면 일반적으로 세 번째 규칙 앞에 삽입해야 합니다. 뒤에 추가하면 문법상 올바르더라도 매칭될 기회가 없을 수 있습니다.
도메인 표기법과 데이터 파일
full:은 전체 도메인을 정확히 매칭하고, domain:은 도메인과 하위 도메인에 주로 사용하며, regexp:는 정규식 조건을 표현합니다. 접두사가 없는 표기법도 자체적인 매칭 의미가 있으므로 모두 정확한 도메인 매칭이라고 볼 수는 없습니다. 원치 않는 매칭을 피하려면 의도를 바로 표현하는 접두사를 우선 사용하고, 명확한 전체 도메인이나 도메인 접미사 대신 복잡한 정규식을 사용하지 마세요. 정규식은 JSON 문자열 이스케이프 규칙의 영향도 받으므로 식 안의 백슬래시는 문자열 규칙에 맞게 처리해야 합니다.
geoip:와 geosite:는 해당 규칙 데이터 파일을 참조하며 실행 중 온라인 검색을 수행하지 않습니다. 사용하기 전에 커널이 필요한 데이터 파일을 읽을 수 있는지, 해당 파일에 참조한 분류가 포함되어 있는지 확인하세요. 분류 이름이 존재한다고 해서 모든 대상이 포함되는 것은 아니며 데이터가 업데이트되면 매칭 범위도 달라질 수 있습니다. 웹사이트가 예상과 다른 출구로 연결된다면 실제 접속 도메인, 하위 리소스, 데이터 내용을 비교하세요. 페이지 하나에도 여러 개의 독립된 요청이 포함될 수 있으므로 주소 표시줄의 도메인만 확인해서는 안 됩니다.
domainStrategy의 조회 시점
AsIs는 이미 확보한 대상 정보를 최대한 활용하고 IP 규칙을 위해 별도로 도메인을 조회하지 않습니다. IPIfNonMatch는 도메인 단계에서 적용 가능한 규칙을 찾지 못한 경우 IP 조건을 사용하도록 조회를 시도합니다. IPOnDemand는 매칭에 IP 정보가 필요할 때 조회를 시작합니다. 각 값은 매칭 과정에서 정보를 얻는 방식을 바꾸는 것이지 “더 빠름”이나 “더 포괄적” 같은 고정 등급을 뜻하지 않습니다. 너무 일찍 조회하면 의존성이 늘어나고, 조회를 충분히 하지 않으면 기대한 IP 분류가 적용될 기회가 사라질 수 있습니다.
특히 기본 규칙에 주의하세요. 앞쪽 규칙이 모든 요청과 매칭된다면 IPIfNonMatch를 사용해도 이미 결과가 나와 원하는 조회 단계까지 진행하지 않을 수 있습니다. 이는 DNS가 작동하지 않는 문제가 아니라 규칙 매칭이 먼저 끝난 것입니다. 필드 하나만 바꾸지 말고 규칙 순서와 조회 전략을 함께 설계해야 합니다. 사설 주소 규칙도 커널이 실제로 알고 있는 주소에만 매칭됩니다. 도메인이 사설 주소로 조회되는 경우에는 조회 시점을 별도로 검증하세요.
클라이언트가 생성하는 “중국 본토 우회”는 대개 규칙 집합을 뜻하며 커널에 공통으로 존재하는 단일 옵션이 아닙니다. 설정 템플릿에 따라 도메인 목록, IP 분류, 기본 출구가 다를 수 있습니다. 실제 동작을 설명하려면 모드 이름만 인용하지 말고 현재 규칙을 확인해야 합니다. 사용 사례에 맞는 모드를 선택하려면 시스템 프록시와 전역·중국 본토 우회 모드를 참고하세요. 속도 차이가 있다면 모든 현상을 모드 이름 탓으로 돌리지 말고 규칙 선택, 조회 경로, 원격 회선을 나누어 살펴보세요.
dns 도메인 조회
DNS 설정은 먼저 “누가 조회를 요청하는지, 조회가 어디서 나가는지, 결과를 누가 사용하는지”를 확인해야 합니다. 운영체제 리졸버, 브라우저 자체 조회 기능, 커널 내장 DNS, 원격 서버의 조회가 동시에 사용될 수 있습니다. 커널의 dns를 수정해도 모든 애플리케이션의 조회 방식이 바뀌거나 모든 시스템 조회가 커널로 들어오지는 않습니다. 관련 요청 경로에서 실제로 내장 리졸버를 호출할 때만 해당 설정이 결과에 영향을 줍니다.
기본 서버와 정적 매핑
servers에는 내장 DNS가 사용하는 서버 또는 관련 설정을 지정하고, hosts에는 정적 도메인 매핑을 정의할 수 있습니다. 아래 예제는 테스트 도메인 하나를 루프백 주소에 매핑하고 나머지 조회는 로컬 조회 방식에 맡깁니다. 정적 매핑은 테스트 범위를 분리할 때 유용하지만 주소가 자주 바뀌는 서비스를 장기간 고정하는 용도로는 적합하지 않습니다. 서비스는 지역, 부하, 주소 계열에 따라 다른 결과를 반환할 수 있습니다. 주소를 고정하면 이런 선택이 무시되고 서버 측 변경 후 연결이 실패할 수도 있습니다.
{
"dns": {
"hosts": {
"full:manual.example": "127.0.0.1"
},
"servers": [
"localhost"
]
}
}이 설정만으로 모든 브라우저가 테스트 도메인을 루프백 주소로 조회하는 것은 아닙니다. 해당 요청이 실제로 커널 내장 DNS를 사용하는 경우에만 적용됩니다. 직결 아웃바운드가 시스템 조회 경로를 사용하거나 애플리케이션이 이미 도메인을 조회했다면 결과가 예상과 달라질 수 있습니다. 정적 매핑을 검증할 때는 조회 경로도 함께 확인하세요. 테스트가 끝나면 매핑을 삭제해 루프백 연결 실패를 실제 대상의 문제로 오인하지 않도록 하세요. 운영 설정의 매핑에는 명확한 목적과 추적 가능한 유지보수 기록이 필요합니다.
라우팅 조회와 아웃바운드 조회
라우팅 단계에서 IP 규칙에 맞추기 위해 도메인을 조회하더라도 아웃바운드는 도메인을 사용해 연결을 시작할 수 있습니다. 라우팅에 사용한 조회 결과가 최종 연결에서도 반드시 사용되는 것은 아닙니다. 직결 아웃바운드가 내장 DNS를 사용할지는 도메인 정책에 달려 있으며 프록시 아웃바운드가 대상을 로컬에서 조회할지는 프로토콜과 구체적인 설정에 따라 달라집니다. 요청을 분석할 때는 라우팅 판단에 사용된 정보와 최종 아웃바운드 연결에 사용된 정보를 따로 기록하세요. 조회 로그 한 곳만 보고 판단하면 안 됩니다.
애플리케이션이 먼저 도메인을 조회한 뒤 IP를 SOCKS 인바운드로 전달할 수도 있습니다. 이 경우 커널이 원래 도메인을 모를 수 있습니다. 스니핑으로 정보를 보완할 때도 있지만 항상 성공하는 것은 아닙니다. 커널에서 도메인 처리를 검증하려면 프록시에 도메인을 전달할 수 있는 테스트 방법을 사용하고 애플리케이션이 주소로 미리 바꾸지 않았는지 확인하세요. 로컬 조회와 프록시 측 조회의 차이를 비교하려는 경우에도 브라우저, 시스템, 클라이언트 캐시를 추측하는 대신 해당 변수를 명시적으로 제어해야 합니다.
조회 전송 경로와 순환 의존성
조회 서버 주소를 지정했다고 해서 요청이 자동으로 원격 프록시를 통과하는 것은 아닙니다. DNS 서버 설정의 형식에 따라 전송 경로가 달라질 수 있으므로 각각 분석해야 합니다. 연결 전에 도메인 조회가 필요한 암호화 DNS 엔드포인트를 사용한다면 최초 조회를 어떻게 수행할지도 고려해야 합니다. DNS 서버에 접근하려면 프록시가 필요하고 프록시 서버의 도메인은 다시 그 DNS 서버에 의존한다면 첫 연결을 시작하기 전에 순환 의존에 빠질 수 있습니다. 시작 과정에 명확하고 실제로 도달 가능한 경로를 마련하세요.
여러 조회기를 한 번에 바꾸면서 라우팅 정책까지 동시에 수정하지 마세요. 현재 반환 주소를 기록한 뒤 조회 과정 하나만 변경하고 같은 대상으로 다시 테스트하세요. DNS 서버가 여러 개라고 해서 작성된 순서대로 차례로 시도하는 것은 아닙니다. 실제 동작에는 매칭 조건, 동시 요청, 대체 동작, 구현체별 차이가 관련될 수 있습니다. 도메인에 따라 조회 출처를 선택하려면 현재 커널이 지원하는 서버 객체 필드를 확인하세요. 다른 도구의 “기본”과 “보조” 의미를 그대로 적용하지 마세요.
| 현상 | 관련될 수 있는 계층 | 확인 방법 |
|---|---|---|
| DNS를 바꿔도 주소가 그대로임 | 애플리케이션 캐시, 시스템 조회, 기존 연결 | 내장 리졸버에 조회가 도달하는지 확인 |
| 도메인 접속은 실패하지만 IP로는 연결됨 | 조회 실패 또는 이름 관련 핸드셰이크 | 조회 문제와 서버 이름 요구 사항 구분 |
| 일부 대상의 연결 대기 시간이 김 | 주소 계열, 반환 주소, 네트워크 경로 조건 | 조회와 연결 수립 단계를 따로 관찰 |
주소 계열과 캐시 범위
IPv4와 IPv6 결과가 모두 있으면 실제 연결 결과는 로컬 네트워크, 아웃바운드 지원 여부, 연결 선택 로직에 따라 달라집니다. 한 번 요청이 오래 걸렸다는 이유만으로 주소 계열 하나를 바로 비활성화하지 마세요. 어떤 주소가 반환됐는지, 어느 연결이 실패했는지, 실패 후 재시도가 있었는지 먼저 확인해야 합니다. 조회에 성공했다는 것은 주소를 얻었다는 뜻일 뿐 모든 주소에 도달할 수 있다는 뜻은 아닙니다. IP 주소에 접속할 수 있어도 TLS 서버 이름과 가상 호스트가 원래 도메인을 요구할 수 있으므로 IP 직접 접속이 도메인을 대체하지는 않습니다.
캐시는 테스트를 안정적으로 만들지만 설정 변경을 가릴 수도 있습니다. 변경 후에는 새 요청을 만들고 필요하다면 애플리케이션에서 제공하는 방법으로 해당 캐시를 정리하세요. 커널을 다시 시작하기 전후의 기록도 구분해야 합니다. 모든 소프트웨어를 재시작하는 것을 유일한 진단 방법으로 삼지 마세요. 캐시가 어느 계층에 있는지 구체적으로 확인해야 문제가 나타난 이유를 설명할 수 있습니다. 전체 속도가 느려진 것처럼 보인다면 속도 저하 단계별 문제 해결을 참고해 조회 대기 시간과 원격 전송 속도를 따로 측정하세요.
policy 연결 정책
연결 정책은 타이머와 리소스를 관리하며 라우팅을 선택하거나 애플리케이션 자체 타임아웃을 대체하지 않습니다. 연결이 자주 끊긴다고 모든 타임아웃부터 늘려서는 안 됩니다. 먼저 핸드셰이크가 완료되지 않았는지, 연결은 됐지만 오래 유휴 상태였는지, 아니면 한쪽이 이미 송신을 끝냈는지 확인하세요. 각 단계는 서로 다른 필드의 영향을 받고 애플리케이션, 운영체제, 원격 장비에도 각각 타이머가 있을 수 있습니다. 연결이 어느 단계에서 끊겼는지 확인해야 정책을 바꿀 목적이 분명해집니다.
레벨 객체와 사용자 연결
policy.levels는 레벨 이름으로 정책을 구성하며 JSON 객체 키는 "0"처럼 문자열로 작성해야 합니다. 사용자 레벨을 지원하는 프로토콜 설정은 관련 level 필드로 정책과 연결할 수 있습니다. 구체적으로 어떤 대상에 적용되는지는 프로토콜 구현과 실제 생성된 설정에 따라 달라집니다. 정책에 특정 레벨을 추가했다고 모든 연결이 자동으로 그 레벨을 사용하는 것은 아닙니다. 문제를 진단할 때는 연결에 해당하는 사용자의 레벨과 명시적으로 지정하지 않았을 때 적용되는 기본 동작을 확인하세요.
{
"policy": {
"levels": {
"0": {
"handshake": 4,
"connIdle": 300,
"uplinkOnly": 2,
"downlinkOnly": 5
}
}
}
}예제의 시간 단위는 초이며 연결 단계별 제한을 설명하기 위한 값입니다. 모든 네트워크 환경에 권장되는 값은 아닙니다. handshake는 관련 핸드셰이크 단계에서 대기할 시간을 제한하고, connIdle은 연결 유휴 시간을 제한합니다. uplinkOnly와 downlinkOnly는 한 방향 전송 단계의 대기 범위와 관련됩니다. 필드의 역할은 커널 문서와 연결 상태를 함께 확인해야 합니다. 이를 브라우저의 “페이지 로드 타임아웃”과 단순히 같은 것으로 보면 안 됩니다.
핸드셰이크, 유휴 상태, 반개방 연결
핸드셰이크 실패는 회선 속도만이 아니라 매개변수 불일치 때문에 발생할 수도 있습니다. 인증 또는 보안 매개변수가 잘못됐다면 핸드셰이크 시간을 늘려도 실패를 더 늦게 확인할 뿐입니다. 실제로 연결 수립에 더 긴 시간이 필요한 증거가 있을 때만 소폭 조정하는 것이 의미가 있습니다. 관찰할 때는 연결 시작, 첫 데이터 수신, 오류 발생 시각을 비교하세요. 로그의 핸드셰이크가 어느 계층을 가리키는지도 확인해야 합니다. 애플리케이션 세션, 프록시 프로토콜, 하위 전송의 핸드셰이크를 하나의 단계로 혼동하지 마세요.
유휴 연결과 저속 연결도 서로 다른 문제입니다. 장시간 연결을 유지하는 애플리케이션은 일정 시간 데이터가 오가지 않아도 세션을 유지하려 할 수 있으며, 일부 애플리케이션은 하트비트로 연결을 활성 상태로 둡니다. 정책 타이머와 애플리케이션 하트비트 주기가 맞지 않으면 일정한 간격으로 연결이 끊길 수 있습니다. 이때는 연결이 끊기는 간격, 실제 데이터 전송 여부, 원격 장비나 중간 장비가 먼저 연결을 종료했는지 확인하세요. 로컬 유휴 시간을 늘려도 원격 측 자체 규칙에 따른 종료를 막을 수 없으며 무선 네트워크 전환으로 생긴 상태 손실도 해결되지 않습니다.
반개방 상태는 한쪽이 송신을 마쳤지만 다른 쪽에서 전달할 데이터가 남아 있을 수 있는 상태입니다. 일부 프로토콜은 응답을 완료하기 위해 이 단계에 의존하므로 단방향 대기 시간이 너무 짧으면 데이터가 잘릴 수 있습니다. 반대로 모든 값을 지나치게 길게 설정하면 더는 필요하지 않은 연결이 리소스를 점유합니다. 구체적인 애플리케이션으로 문제를 재현하고 응답이 완전한지, 어느 쪽에서 먼저 연결을 닫았는지 관찰한 뒤 해당 필드만 조정하세요. 웹페이지 하나가 열렸다고 모든 장시간 연결과 단방향 전송이 정상이라고 결론 내리지 마세요.
통계와 버퍼는 속도 스위치가 아님
정책에는 사용자 또는 시스템 트래픽 통계 관련 필드가 포함될 수 있지만 통계를 켜는 것은 기록을 위한 한 조건일 뿐입니다. 클라이언트에서 관련 정보를 표시하려면 통계 모듈, 인터페이스, 클라이언트가 데이터를 읽는 방식도 필요합니다. 통계 스위치만 복사해도 화면에 데이터가 자동으로 나타나지는 않습니다. 마찬가지로 버퍼 설정은 메모리 사용량과 데이터 처리 방식에 영향을 줄 뿐 원격 대역폭, 회선 혼잡, 서버 제한을 넘어설 수 없습니다. 버퍼를 늘린다고 모든 요청이 빨라지는 것도 아닙니다.
GUI 클라이언트에서는 명확하고 재현 가능한 요구가 없다면 생성된 기본 정책을 그대로 유지하는 편이 좋습니다. 클라이언트가 현재 커널과 기능에 맞춰 기본값을 설정할 수 있으며 정책 전체를 사용자 설정으로 덮어쓰면 기존 필드가 뜻하지 않게 삭제될 수 있습니다. 값 하나만 바꾸려는 경우 클라이언트가 필드 단위로 병합하는지 섹션 전체를 교체하는지 확인하세요. 수정 전후 설정 차이를 기록하고 특히 직접 변경하지 않은 레벨과 시스템 정책이 그대로 있는지 점검하세요. 겉으로는 타임아웃만 바꾼 것 같아도 다른 설정이 사라질 수 있습니다.
정책 변경을 검증할 때는 같은 애플리케이션과 동일한 조작 절차를 사용하고 유휴 후에도 계속 전송할 수 있는지, 단방향 응답이 완전한지처럼 관찰 가능한 판정 기준을 정하세요. 문제를 안정적으로 재현할 수 없다면 기존 값을 유지하고 증거를 더 수집하세요. 핸드셰이크, 유휴 시간, 버퍼를 동시에 바꾸지 마세요. 메모리가 제한된 환경에서는 동시 연결과 로그 양도 살펴보고 리소스 부족을 네트워크 문제로 오인하지 않도록 하세요. 정책의 목적은 실제 사용 방식에 맞게 제한을 설정하는 것이지 값이 클수록 좋다는 인상을 주는 설정이 아닙니다.
전체 예제와 단계별 검증
먼저 로컬 인바운드와 직결 아웃바운드만 포함한 설정으로 구조를 검증한 뒤 실제 노드와 복잡한 트래픽 분배를 추가하세요. 이렇게 하면 원격 인증, 전송 조건, 구독 생성 로직을 실험 범위에서 잠시 제외할 수 있습니다. 아래는 로컬 SOCKS 요청을 받고 지정된 테스트 도메인을 차단 아웃바운드로 보내며 나머지 요청은 직결하는 기본 설정 전체 예제입니다. 원격 프록시 연결을 만들거나 애플리케이션의 시스템 프록시를 자동으로 설정하지는 않습니다. 인바운드, 규칙, 아웃바운드 간 참조 관계를 확인하는 데 사용하세요.
실행 가능한 로컬 실험 설정
{
"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": {
"domainStrategy": "AsIs"
}
},
{
"tag": "block",
"protocol": "blackhole",
"settings": {}
}
],
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"domain": ["full:blocked.example"],
"outboundTag": "block"
},
{
"type": "field",
"inboundTag": ["local-socks"],
"outboundTag": "direct"
}
]
},
"dns": {
"servers": ["localhost"]
},
"policy": {
"levels": {
"0": {
"handshake": 4,
"connIdle": 300,
"uplinkOnly": 2,
"downlinkOnly": 5
}
}
}
}실행 전에 같은 리스닝 포트를 점유하는 다른 인스턴스를 종료하세요. 클라이언트의 사용자 지정 설정 입력란을 사용한다면 전체 설정을 가져오는 곳인지 특정 하위 섹션만 입력받는 곳인지 확인하세요. 두 입력 방식에서 요구하는 구조는 다릅니다. 저장한 뒤 커널이 실행되는지 먼저 확인하고 리스닝 상태를 살펴보세요. 이 실험에서는 규칙 테스트가 애플리케이션이 전달한 대상 이름에 직접 의존하도록 스니핑을 사용하지 않습니다. dns는 기본 구조로 남겨 두었지만 직결 아웃바운드에서 AsIs를 사용한다고 해서 요청이 반드시 내장 DNS를 거친다고 단정해서는 안 됩니다.
인바운드, 매칭, 아웃바운드 순으로 단계별 테스트
첫 번째로 애플리케이션이 로컬 포트에 연결되는지 확인하세요. 연결이 즉시 거부된다면 프로세스가 실행 중인지, 주소 계열이 일치하는지, 포트가 바뀌지 않았는지 살펴보세요. 두 번째로 애플리케이션이 먼저 조회해 IP로 바꾸지 않도록 도메인 대상을 명시적으로 전달하세요. 세 번째로 일반 대상과 차단 대상의 동작을 비교하세요. 아래 명령은 해당 명령줄 도구가 설치된 환경에서 실행할 수 있으며 실행 중인 로컬 인바운드에만 요청을 보냅니다. 터미널에서 도구 이름을 다른 명령의 별칭으로 사용한다면 실제 실행 파일 이름을 지정하세요.
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://v2raygpu.com/
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://blocked.example/socks5h는 도메인 처리를 프록시 인바운드에 맡겨 전체 도메인 규칙을 테스트하는 데 적합합니다. 첫 번째 요청의 성공 여부는 로컬 네트워크와 대상 사이트의 상태에도 달려 있습니다. 두 번째 요청은 차단되어야 하지만 실패했다는 사실만으로 규칙이 적용됐다고 증명할 수는 없습니다. 예제 도메인은 일반적인 서비스 대상이 아니기 때문입니다. 요청 대상과 아웃바운드 기록을 함께 확인하거나, 통제된 환경에서 접속 가능한 대상으로 테스트 규칙을 잠시 바꾸고 검증 후 원래대로 되돌리세요. 타임아웃을 차단 성공으로 단정하지 마세요.
기본 경로를 확인한 다음 클라이언트에서 기존의 실제 노드 정보를 가져와 실제 아웃바운드 선택에 추가하세요. 한 번에 기능 하나만 추가합니다. 원격 아웃바운드를 먼저 확인하고, 도메인 규칙을 추가한 뒤, 마지막으로 조회 조건을 더하세요. 가져온 직후 실패한다면 추가한 부분과 기본 설정을 단계별로 비교하세요. 전체 실험 설정을 클라이언트의 자동 생성 절차에 덮어쓰면서 기존 노드와 라우팅이 그대로 유지된다고 가정하지 마세요. 설정 출처가 바뀌면 검증을 시작할 지점도 다시 확인해야 합니다.
문제 기록과 되돌리기 순서
문제 기록에는 사용한 클라이언트, 실제 커널, 설정 출처, 인바운드 주소, 테스트 대상, 예상 아웃바운드를 명확히 적으세요. 인증 정보를 제거하더라도 태그 간 관계는 남겨야 다른 사람이 라우팅 참조가 유효한지 판단할 수 있습니다. 특정 애플리케이션만 실패한다면 성공한 애플리케이션과 인바운드 사용 방식, 도메인 전달 방식, 연결 재사용 동작을 먼저 비교하세요. 모든 애플리케이션이 실패한다면 처음부터 클라이언트를 재설치하지 말고 실행, 리스닝, 조회, 원격 연결 순서로 확인하세요.
되돌릴 때는 마지막으로 변경한 항목부터 역순으로 취소하세요. 추가한 규칙이나 필드를 먼저 되돌리고 재시작한 뒤 다시 테스트합니다. 그래도 복구되지 않으면 정상 작동이 확인된 설정 출처로 전환하세요. 구독 업데이트로 생긴 변화는 노드 정보의 변경과 로컬 템플릿의 변경을 구분해야 합니다. 이전 파일과 새 화면 설정을 섞어 사용하지 마세요. 플랫폼별 설치 차이는 다운로드 페이지에서, 기본 연결 방법은 빠른 시작 가이드에서, 용어는 용어 핸드북에서 확인할 수 있습니다.
마지막으로 목표가 실제로 달성됐는지 확인하세요. 문법 검사 통과, 정상 리스닝, 요청 유입, 규칙에 맞는 아웃바운드, 명확한 조회 경로, 예상 범위 내 연결 종료를 각각 확인해야 합니다. 확실하지 않은 항목이 있다면 해당 관찰 지점을 계속 유지하세요. 핸드북의 코드 조각은 각 모듈을 설명하기 위한 것이며 전체 설정으로 사용할 수 있는 것은 전체 예제로 표시된 설정뿐입니다. 하위 섹션을 복사할 때는 올바른 계층에 병합하고 필요한 다른 모듈도 유지하세요. 안정적인 설정은 필드를 계속 늘리는 데서가 아니라 반복 검증할 수 있는 의존 관계에서 만들어집니다.