JSON 구조와 설정 범위
설정 파일은 커널이 연결을 수신하고 경로를 선택해 아웃바운드 연결을 만드는 방법을 정의합니다. 클라이언트의 모든 설정을 담는 파일은 아닙니다. 창 위치, 구독 그룹, 업데이트 주기, 시스템 프록시 스위치는 대개 그래픽 클라이언트가 관리하고, 리스닝 포트와 프로토콜 매개변수, 라우팅 규칙은 실행 설정에 포함됩니다. 먼저 두 범위를 구분해야 화면 옵션, 사용자 지정 템플릿, 독립 JSON 파일 중 어디를 수정할지 판단할 수 있습니다.
최상위 객체와 데이터 형식
JSON의 최상위에는 객체 하나가 오며, 필드명과 문자열은 영문 큰따옴표로 묶습니다. 객체는 중괄호, 배열은 대괄호로 표현하고 포트는 보통 숫자로, 불리언 값은 소문자 true 또는 false로 씁니다. 마지막 항목 뒤에는 쉼표를 붙이지 않습니다. 한글 따옴표나 주석, 페이지에서 복사할 때 포함된 보이지 않는 문자를 파일에 넣지 마세요. 일부 도구에서 허용하는 문법이라고 해서 모든 커널이 읽을 수 있는 것은 아닙니다.
inbounds와 outbounds는 배열입니다. 하나의 프로세스에서 여러 인바운드와 아웃바운드를 정의할 수 있기 때문입니다. routing, dns, policy는 각각 규칙, DNS 조회, 연결 정책을 관리하는 객체입니다. 필드명은 대소문자를 구분하며 태그도 정확히 일치해야 합니다. outboundTag의 대소문자를 바꿔 쓰면 프로그램이 알아서 고쳐 줄 것이라고 기대할 수 없습니다.
{
"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": {}
},
{
"tag": "block",
"protocol": "blackhole",
"settings": {}
}
]
}최소 설정 이해하기
위 예제는 SOCKS 인바운드에서 직접 연결하는 아웃바운드로 이어지는 기본 설정 전체입니다. 애플리케이션이 지정된 로컬 포트로 요청을 보내면 커널은 현재 네트워크를 통해 freedom으로 연결합니다. 원격 프록시 서버는 포함하지 않으며 브라우저나 운영체제의 프록시를 자동으로 설정하지도 않습니다. 이 설정은 파일이 로드되고 포트가 열리며 애플리케이션 요청이 커널에 전달되는지 확인하는 용도이지, 원격 노드 연결을 보여 주는 예제가 아닙니다.
이 예제에는 라우팅 규칙이 없으므로 규칙에 걸리지 않은 연결은 첫 번째 아웃바운드를 사용합니다. 따라서 아웃바운드 배열의 순서는 실제 동작에 영향을 주며 단순한 표시 순서가 아닙니다. 원격 아웃바운드를 추가할 때는 기본 경로를 명확하게 정하세요. 그렇지 않으면 노드 하나만 추가한 것처럼 보여도 규칙에 걸리지 않는 모든 요청의 경로가 바뀔 수 있습니다. 먼저 기본 경로를 정한 뒤 배열 순서와 기본 처리 규칙을 구성하세요.
전체 파일, 설정 조각, 클라이언트 템플릿
설정 조각은 routing 객체나 아웃바운드 항목처럼 특정 필드 주변의 구조만 보여 줍니다. 병합할 때는 같은 이름의 최상위 필드 안에 넣어야 하며, 전체 객체 두 개를 그대로 이어 붙이면 안 됩니다. 최상위 필드도 중복해서 정의하지 마세요. 파서마다 중복 키를 처리하는 방식이 다를 수 있고, 실행에 성공했다고 두 설정이 모두 적용된다는 뜻은 아닙니다. 명확한 배열이나 객체 하나로 정리하는 편이 안전합니다.
그래픽 클라이언트는 현재 서버, 라우팅 프리셋, 로컬 포트에 맞춰 실행 파일을 생성하는 경우가 많습니다. 이 파일을 직접 편집해도 다음에 서버를 바꾸거나 커널을 재시작하면 수정 내용이 덮어써질 수 있습니다. 먼저 클라이언트의 사용자 지정 설정, 라우팅 편집, 가져오기 기능을 확인하세요. 사용자가 파일을 독립적으로 관리하는 것이 확실할 때만 장기 설정 파일로 사용하고, 화면 설정과 수동 편집이 같은 필드를 동시에 관리하게 두지 마세요.
| 항목 | 주로 설정하는 위치 | 확인할 점 |
|---|---|---|
| 구독 그룹, 자동 업데이트 | 클라이언트 설정 | 업데이트 시 서버 항목이 다시 생성되는지 |
| 인바운드, 아웃바운드, 라우팅 | 커널 실행 설정 | 필드와 태그가 서로 맞는지 |
| 시스템 프록시, 백그라운드 권한 | 운영체제와 클라이언트 연동 | 애플리케이션 트래픽이 인바운드에 들어오는지 |
생략한 필드에는 커널 기본값이 적용되지만, 기본값 때문에 설정 구조를 이해하기 어려워서는 안 됩니다. 보안 범위, 기본 아웃바운드, 라우팅 조회 정책은 명시적으로 설정하고, 아직 사용하지 않는 복잡한 기능은 우선 생략하세요. 예제를 참고할 때는 커널 계열도 확인해야 합니다. V2Fly와 Xray의 기본 구조가 비슷해도 모든 확장 필드를 함께 쓸 수 있는 것은 아닙니다. 알 수 없는 필드나 시작 오류가 나타나면 네트워크부터 의심하지 말고 먼저 지원 범위를 확인하세요.
저장할 때는 정상 작동하는 기준 설정을 따로 보관하고, 변경 목적은 파일에 직접 삽입하지 말고 일반 메모로 남기세요. 엄격한 JSON에 설명 문구를 넣으면 안 됩니다. 한 번에 서로 관련된 필드만 바꾸고, 설정이 로드된 뒤 해당 동작을 테스트하세요. 이렇게 하면 문법 오류, 잘못된 계층에 넣은 설정, 연결 매개변수 불일치를 구분할 수 있습니다. 설정을 한꺼번에 많이 붙여 넣어 되돌릴 수 있는 상태를 잃는 일도 줄어듭니다.
inbounds 인바운드와 로컬 리스너
인바운드는 애플리케이션이 커널에 연결을 전달하는 입구입니다. 설정에서 원격 서버보다 먼저 확인할 것은 애플리케이션이 실제로 연결하는 로컬 주소와 포트, 프록시 프로토콜입니다. 원격 노드 설정이 완벽해도 브라우저가 예전 포트를 가리키면 이 설정에 연결되지 않습니다. 문제를 해결할 때는 클라이언트에 실행 중이라고 표시되는지만 보지 말고 애플리케이션의 프록시 설정과 인바운드 리스너를 함께 비교하세요.
리스닝 주소와 접근 범위
listen은 바인딩할 로컬 주소를, port는 리스닝 포트를 지정합니다. 로컬 기기에서만 사용할 때는 IPv4 루프백 주소인 127.0.0.1에 바인딩하는 것이 좋습니다. 애플리케이션에서 localhost를 사용하면 운영체제가 IPv6 루프백 주소로 해석할 수도 있습니다. 커널은 IPv4만 수신하고 애플리케이션은 IPv6만 시도하면 연결에 실패할 수 있습니다. 문제를 진단할 때는 동일한 루프백 주소를 명시적으로 사용하세요.
모든 인터페이스에서 수신하는 것과 로컬 네트워크 기기의 접근을 허용하는 것은 같은 설정이 아닙니다. 바인딩 범위를 넓히면 방화벽, 기기의 네트워크 위치, 인바운드 인증도 고려해야 합니다. 인증되지 않은 프록시 인바운드를 신뢰할 수 없는 네트워크에 직접 노출해서는 안 됩니다. 공유가 필요하다면 사용 대상과 네트워크 경계를 먼저 정한 뒤 인증과 방화벽의 접근 출처 제한을 설정하세요. 원격 서버의 인증 정보는 로컬 인바운드의 접근 제어를 대신하지 않습니다.
{
"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": {}
}
]
}SOCKS와 HTTP 인바운드의 차이
위 설정 조각은 각각 SOCKS와 HTTP 프록시를 제공하는 인바운드입니다. 애플리케이션에서 SOCKS5를 선택했다면 앞쪽 포트에, HTTP 프록시를 선택했다면 뒤쪽 포트에 연결해야 합니다. HTTP 프록시는 CONNECT를 통해 HTTPS 대상과의 연결을 전달할 수 있으므로, 대상 URL이 HTTPS로 시작한다는 이유만으로 프록시 인바운드에도 TLS가 필요하다고 오해하지 마세요. 프록시 입구의 프로토콜과 대상 웹사이트의 프로토콜은 서로 다른 계층입니다.
SOCKS 인바운드의 udp는 SOCKS UDP 전달을 허용한다는 뜻이지, 전체 경로에서 UDP를 사용할 수 있다는 보장은 아닙니다. 애플리케이션이 해당 방식을 지원해야 하고, 원격 아웃바운드와 서버도 UDP를 처리할 수 있어야 하며 네트워크 경로에서 관련 패킷을 허용해야 합니다. HTTP 인바운드는 범용 UDP 인바운드를 대신할 수 없습니다. 웹은 정상인데 실시간 앱에 문제가 있다면 웹 프록시 포트를 계속 바꾸기보다 해당 앱의 전송 방식을 따로 확인하세요.
인바운드 태그와 스니핑 범위
tag는 라우팅에서 참조할 인바운드 이름을 지정합니다. 예를 들어 브라우저와 테스트 도구가 서로 다른 인바운드를 사용한다면 inboundTag로 두 트래픽을 구분할 수 있습니다. 태그 자체로 리스너가 생성되거나 애플리케이션 접근이 제한되는 것은 아닙니다. 애플리케이션 연결 여부는 주소, 포트, 프로토콜이 결정합니다. 태그는 짧고 일관되게 정하고 이름을 바꿀 때는 해당 태그를 참조하는 라우팅도 함께 수정하세요.
{
"sniffing": {
"enabled": true,
"destOverride": ["http", "tls"]
}
}이 sniffing 객체는 특정 인바운드 내부에서 settings와 같은 계층에 둡니다. 지원되는 프로토콜의 핸드셰이크를 바탕으로 도메인을 감지해 도메인 기반 라우팅을 돕습니다. 모든 암호화된 내용을 읽을 수 있는 것은 아니며 모든 연결에서 도메인을 알아낼 수 있는 것도 아닙니다. 요청에 IP 주소가 직접 지정된 경우 감지 결과가 대상 처리에 영향을 줄 수 있습니다. 라우팅에만 사용하는 옵션 같은 확장 기능은 실제 커널의 지원 여부를 확인하세요.
포트 충돌과 시스템 프록시
리스너가 시작되지 않으면 먼저 로그에 나온 주소와 포트를 확인하세요. 다른 클라이언트 인스턴스나 시스템 서비스, 다른 로컬 프록시가 포트를 이미 사용 중일 수 있습니다. 포트 숫자만 바꾸고 끝내면 안 됩니다. 인바운드 포트를 바꾼 뒤에는 수동으로 설정한 브라우저, 터미널 도구, 다른 애플리케이션도 함께 수정해야 합니다. 클라이언트가 관리하는 시스템 프록시는 설정에 맞춰 업데이트되기도 하지만, 시스템 프록시 설정 화면에서 실제 값을 확인하세요.
시스템 프록시는 해당 설정을 따르는 애플리케이션에 특정 인바운드로 연결하라고 알리는 기능이지, 기기의 모든 연결을 가로채는 기능은 아닙니다. 일부 앱은 자체 프록시 설정을 사용하고, 일부 앱은 시스템 프록시를 무시합니다. 이는 인바운드가 시작되는지와는 별개의 문제입니다. 클라이언트에 TUN 모드가 있다면 트래픽 처리와 라우팅, 권한은 운영체제 측 기능에도 관련되므로 SOCKS 인바운드만 추가해서 구현할 수 없습니다. 테스트 범위를 좁히려면 프록시를 명시적으로 지원하는 앱부터 사용하세요.
인바운드가 제대로 작동하는지 확인하려면 커널이 정상적으로 시작되었는지, 대상 포트가 리스닝 중인지, 애플리케이션 요청이 해당 로그에 나타나는지를 모두 확인해야 합니다. 프로세스가 존재하는 것만으로는 충분하지 않습니다. 설정 로드에 실패해도 클라이언트 화면에는 실행 중으로 표시될 수 있습니다. 이 세 가지를 확인한 뒤 아웃바운드를 점검하면 로컬 인바운드 문제를 원격 연결 문제로 오인하지 않고, 이후 인바운드별 트래픽 분류를 위한 기준도 마련할 수 있습니다.
outbounds 아웃바운드와 태그의 관계
아웃바운드는 커널이 연결을 받은 뒤 어떤 방식으로 대상에 도달할지 결정합니다. 직접 연결하거나 원격 프록시 서버에 전달하거나 규칙에 맞는 연결을 차단할 수 있습니다. outbounds의 각 객체는 프로토콜을 먼저 확인하고 해당 프로토콜에 맞는 settings를 살펴보세요. 프로토콜마다 설정 구조가 다르므로 protocol 이름만 바꿔 기존 설정을 다른 프로토콜로 변환할 수는 없습니다.
직접 연결, 프록시, 차단
freedom은 현재 기기가 연결된 네트워크를 통해 직접 연결한다는 뜻이고, blackhole은 일치하는 트래픽을 버리는 데 사용합니다. direct, proxy, block은 흔히 쓰이는 태그일 뿐 내장 프로토콜이 아닙니다. direct라는 태그가 실제로 원격 프로토콜을 가리킨다면 원격 아웃바운드를 사용합니다. 태그의 영문 이름만 보고 동작을 추측하지 말고 태그와 프로토콜을 함께 확인하세요.
{
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
},
{
"tag": "block",
"protocol": "blackhole",
"settings": {}
}
]
}이 설정 조각은 기본 테스트 설정의 아웃바운드 부분으로 사용할 수 있습니다. 다른 아웃바운드를 선택하는 규칙이 없으면 일반적으로 첫 번째 항목이 기본 경로가 됩니다. 클라이언트는 설정을 생성하면서 기본 아웃바운드와 기본 처리 규칙을 따로 정할 수 있으므로, 직접 읽을 때는 화면에 표시된 현재 서버 이름이 아니라 최종 실행 파일을 확인하세요. 아웃바운드를 추가해도 자동으로 트래픽이 전달되지는 않습니다. 기본 순서로 선택하거나 라우팅에서 참조해야 합니다.
원격 아웃바운드 매개변수의 계층
원격 프록시 설정에는 보통 서버 주소와 포트, 사용자 인증, 전송 및 보안 설정이 포함됩니다. 주소는 실제로 연결할 서버를, 포트는 해당 서비스가 대기하는 위치를 지정하고 사용자 필드는 선택한 프로토콜에 맞아야 합니다. 전송 경로, 서비스 이름, TLS 서버 이름은 별도 계층에 속합니다. 이 값을 주소 입력란 하나에 모두 복사하거나, 링크의 인코딩된 내용을 인증 필드에 그대로 넣으면 설정 구조가 잘못됩니다.
구독 및 공유 링크는 서버 매개변수를 전달하는 수단이지 완성된 실행 설정이 아닙니다. 클라이언트는 가져온 항목에 로컬 포트, DNS, 라우팅 설정을 더해 실행 파일을 만듭니다. 공유 링크를 읽을 수 있다는 것은 대략적인 형식을 파악했다는 뜻일 뿐, 인증이 유효하거나 인증서가 일치하거나 전송 엔드포인트가 존재한다는 보장은 아닙니다. 원격 매개변수는 사용 권한이 있는 서비스 설정에서 가져오고, 다른 예제의 인증 정보나 경로를 조합하지 마세요.
| 계층 | 일반적인 설정 | 불일치 시 나타나는 증상 |
|---|---|---|
| 연결 대상 | 서버 주소, 포트 | 주소 확인 실패, 연결 거부, 시간 초과 |
| 프로토콜 인증 | 사용자 식별자, 비밀번호, 암호화 매개변수 | 연결 후 인증 실패 또는 연결 종료 |
| 전송 및 보안 | 경로, 서비스 이름, TLS 매개변수 | 핸드셰이크 실패, 엔드포인트 응답 불일치 |
여러 아웃바운드와 전환 범위
하나의 설정에 여러 원격 아웃바운드를 두고 규칙마다 다르게 참조할 수 있습니다. 태그마다 고유한 의미를 부여해 이름이 중복되어 참조 대상을 헷갈리지 않도록 하세요. 태그를 직접 수정할 때는 라우팅 외에도 아웃바운드를 참조할 수 있는 기능을 확인해야 합니다. 목록 순서만 바꾼다고 상태 확인이나 자동 전환 기능이 생기지는 않습니다. 관련 기능을 설정하지 않았다면 경로가 느리다는 이유만으로 커널이 다른 경로로 자동 전환하지 않습니다.
일부 프로토콜에는 도메인 조회 정책, 연결 재사용, 하위 소켓 옵션도 있습니다. 이런 필드는 기본 연결이 정상 작동한 뒤 조정하세요. 예를 들어 조회 정책은 직접 연결 아웃바운드의 도메인 처리에 영향을 줄 수 있지만 라우팅 객체의 도메인 정책을 대신하지는 않습니다. 연결 재사용은 연결 구성 방식을 바꾸지만 잘못된 서버 인증을 해결하지 않습니다. 성능 최적화와 연결 가능성은 따로 다뤄야 문제 해결 기록이 뒤섞이지 않습니다.
원격 아웃바운드 주소가 도메인 이름이라면 시작 시 해당 이름을 조회하는 방법도 고려해야 합니다. 프록시가 연결되기 전에 서버 도메인을 조회할 경로가 없으면 프록시에 연결하기 위해 같은 프록시를 먼저 거쳐야 하는 순환이 생길 수 있습니다. 로컬 조회나 명확한 부트스트랩 DNS 설정, 서비스 제공업체가 제공한 유효한 주소로 순환을 해소하세요. 시스템 프록시 스위치만 계속 바꾸는 것은 해결책이 아닙니다.
설정과 클라이언트의 역할 구분
데스크톱에서는 v2rayN으로 서버와 라우팅 템플릿을 관리할 수 있습니다. 안드로이드의 v2rayNG는 Xray 생태계를 사용하며, v2flyNG는 V2Fly 계열의 대안입니다. 기본 아웃바운드 개념은 공유할 수 있지만 전용 프로토콜 확장, 전송 필드, 가져오기 동작은 각각 확인해야 합니다. 클라이언트를 선택할 때는 기기 플랫폼과 설정 요구 사항부터 확인하세요. 설치 파일은 다운로드 페이지에서 받을 수 있으며 클라이언트 이름을 커널 필드에 입력하면 안 됩니다.
원격 매개변수를 저장하기 전에 연결 주소, 포트, 인증, 전송, 보안 설정이 모두 동일한 서비스 설정에서 가져온 것인지 항목별로 확인하세요. 연결이 성립한 뒤에는 요청이 의도한 아웃바운드로 전달되는지도 확인해야 합니다. 연결 테스트 성공이 모든 대상에 해당 라우팅 규칙이 적용된다는 뜻은 아닙니다. 로컬 직접 연결은 정상이지만 원격 아웃바운드가 실패한다면 인바운드는 그대로 둔 채 서버 주소 조회, 핸드셰이크, 인증으로 확인 범위를 좁히세요.
routing 규칙의 매칭 순서와 트래픽 분기
라우팅은 인바운드와 아웃바운드를 연결합니다. 대상 도메인, IP 주소, 포트 또는 인바운드 태그를 확인한 뒤 이미 정의된 아웃바운드를 선택합니다. 규칙은 일반적으로 위에서 아래로 확인하며 먼저 일치한 규칙이 경로를 결정합니다. 특정 예외를 앞에, 범위가 넓은 규칙을 뒤에 두는 원칙은 특정 프리셋을 외우는 것보다 신뢰할 수 있습니다. 어떤 규칙에도 일치하지 않는 연결은 기본 아웃바운드로 처리되며 도메인의 지역에 따라 자동으로 경로를 판단하지 않습니다.
대상을 먼저 정하고 조건을 추가하세요
outboundTag는 아웃바운드 항목의 tag와 정확히 일치해야 합니다. 존재하지 않는 이름을 참조해도 새 아웃바운드가 만들어지지 않으며, 설정 검사나 전달 과정에서 오류가 날 수 있습니다. 규칙의 type이 field라면 조건 필드가 매칭 범위를 지정합니다. 사용할 아웃바운드부터 확인한 뒤 규칙을 하나씩 추가하세요. 그렇지 않으면 조건이 일치하지 않은 것인지, 일치한 뒤 대상 아웃바운드를 찾지 못한 것인지 구분하기 어렵습니다.
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"domain": ["full:blocked.example"],
"outboundTag": "block"
},
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
}
]
}
}이 라우팅 조각은 앞에서 설명한 직접 연결 및 차단 아웃바운드와 함께 사용할 수 있습니다. blocked.example은 정확한 매칭 문법을 보여 주기 위한 예약 예제 도메인입니다. 실제로 테스트할 때는 관리 권한이 있는 도메인으로 바꾸세요. geosite와 geoip는 외부 규칙 데이터를 참조하므로 실행 환경에 해당 데이터 파일이 있어야 합니다. 필요한 데이터가 없을 때 발생한 로드 오류를 네트워크 문제로 돌리지 마세요.
동일 필드와 여러 필드의 논리
같은 도메인 배열의 여러 항목은 보통 하나라도 일치하면 적용됩니다. 반면 한 규칙에 도메인, 포트, 네트워크 유형을 함께 쓰면 서로 다른 조건을 모두 만족해야 합니다. 특정 도메인 또는 특정 IP를 같은 아웃바운드로 보내려면 도메인과 IP를 한 규칙에 넣고 OR로 처리될 것이라 기대하기보다 규칙 두 개로 나누는 것이 일반적입니다. 조건 관계를 먼저 정리한 뒤 JSON으로 옮기면 겉보기에는 완전하지만 한 번도 매칭되지 않는 규칙을 줄일 수 있습니다.
full:은 도메인 전체를 정확히 일치시키고, domain:은 지정한 도메인과 하위 도메인을 포함해 매칭하며, regexp:는 정규 표현식을 사용합니다. 접두어가 없는 문자열은 예상보다 넓은 범위에 매칭될 수 있으므로 정확한 예외를 지정할 때는 적절하지 않습니다. 규칙 대상은 호스트명이 아니라 전체 URL이 아닙니다. 라우팅은 주소창의 URL 전체를 비교하지 않으므로 일반적으로 https://, 경로, 쿼리 매개변수를 도메인 조건에 넣지 마세요.
도메인 조회 정책과 IP 규칙
AsIs는 라우팅의 IP 조건을 위해 도메인을 자동으로 조회하지 않습니다. 애플리케이션이 도메인을 전달하는 경우 IP 규칙만으로는 기대한 결과가 나오지 않을 수 있습니다. IPIfNonMatch는 도메인 규칙에 일치하지 않을 때 조회를 시도한 뒤 계속 매칭하고, IPOnDemand는 IP 기반 규칙의 매칭이 필요할 때 조회합니다. 두 옵션 모두 조회가 개입할 가능성을 높이고 규칙 순서에 따른 실제 동작도 바꿉니다.
조회 결과에는 여러 주소가 포함될 수 있으며 대상 서비스의 주소는 바뀔 수 있습니다. IP 규칙에 매칭되어도 해당 주소가 영구적으로 특정 도메인에 속한다는 뜻은 아닙니다. 여러 서비스가 같은 인프라를 공유할 수도 있습니다. 안정적인 도메인으로 목적을 표현할 수 있다면 도메인 조건을 우선 사용하세요. 로컬 네트워크나 고정 서비스 주소를 제어해야 할 때 IP 조건을 사용하면 됩니다. 데이터 분류 역시 인증서나 서비스 소유권을 확정하는 증거는 아닙니다.
{
"type": "field",
"inboundTag": ["local-socks"],
"network": "tcp",
"port": "443",
"outboundTag": "direct"
}이 단독 규칙은 지정된 SOCKS 인바운드에서 들어오고 대상 포트가 443이며 TCP를 사용하는 연결을 직접 연결로 보냅니다. 세 조건을 모두 만족해야 하며 해당 포트를 전역적으로 허용하는 규칙은 아닙니다. 여기서 포트는 대상 포트이지 로컬 리스닝 포트가 아닙니다. 규칙을 배열 앞부분에 두면 뒤에 있는 도메인 차단 규칙을 먼저 가로채지 않는지도 확인하세요. 범위가 넓을수록 순서를 신중하게 정해야 합니다.
기본 아웃바운드와 검증 방법
명시적인 기본 규칙이 필요하다면 TCP와 UDP를 모두 포함하는 규칙을 배열 끝에 추가하고, 이미 정의된 기본 아웃바운드를 지정할 수 있습니다. 이 뒤에 오는 유사 규칙은 일반적으로 적용되지 않으므로 기본 규칙이 마지막인지 확인하세요. 첫 번째 아웃바운드를 기본으로 사용한다면 나중에 순서를 바꿔 동작이 달라지지 않도록 설정 메모에 기록하세요. 클라이언트의 '전역 프록시' 모드와 시스템이 모든 앱을 제어하는지는 구분해야 합니다. 전자는 주로 경로 선택 방식을 뜻합니다.
규칙이 적용되지 않으면 애플리케이션이 도메인과 IP 중 무엇을 전달하는지, 앞선 규칙이 먼저 처리하지 않았는지, 태그가 일치하는지, 데이터 파일을 불러올 수 있는지 순서대로 확인하세요. 수정한 뒤에는 커널이 해당 설정을 다시 로드해야 합니다. 기존의 장기 연결은 이전 경로를 계속 사용할 수 있으므로 테스트 전에 기존 연결을 끊고 새 요청을 시작하세요. 그래야 연결 재사용으로 이어진 동작을 규칙 미적용으로 오해하지 않습니다.
DNS 조회와 라우팅의 연동
DNS는 도메인을 IP 주소로 변환하지만 프록시 경로에서는 조회를 수행하는 주체가 하나가 아닙니다. 애플리케이션이 프록시에 요청을 넘기기 전에 직접 조회할 수 있고, 커널이 라우팅이나 직접 연결을 위해 조회할 수도 있으며, 원격 서버가 최종 대상을 조회할 수도 있습니다. dns 객체를 작성했다는 것은 커널 조회 설정을 지정했다는 뜻일 뿐, 기기의 모든 도메인 조회가 해당 설정을 사용한다는 의미는 아닙니다. 먼저 어느 계층에서 조회가 발생하는지 확인한 뒤 설정 위치를 정하세요.
커널 DNS의 기본 구조
servers는 커널이 사용할 DNS 서버를 지정하고, hosts는 특정 도메인에 정적 주소를 지정할 수 있습니다. 아래 예제는 루프백 도메인 매핑과 예시 DNS 서버 주소로 구조를 보여 줍니다. 시스템 DNS를 가로채는 인바운드나 애플리케이션 자체의 조회 설정은 포함하지 않습니다. DNS 서버를 바꿀 때는 익숙해 보이는 주소라는 이유만으로 선택하지 말고 현재 네트워크에서 접근 가능한지, 해당 환경의 관리 정책에 맞는지 확인하세요.
{
"dns": {
"hosts": {
"loopback.example": "127.0.0.1"
},
"servers": [
"1.1.1.1"
]
}
}여기의 정적 매핑은 커널 DNS 조회 흐름을 확인하기 위한 것으로 시스템 hosts 파일을 수정하지 않습니다. 커널 DNS를 사용하는 요청에만 영향을 주며 다른 방식으로 조회한 브라우저 주소를 찾아 바꾸지는 않습니다. 실제 설정에서 정적 매핑을 사용한다면 서비스가 이전된 뒤 오래된 주소가 남지 않도록 관리해야 합니다. 서비스 제공업체가 해당 연결 방식을 명시적으로 지원하지 않는 한 동적 서비스 도메인 대신 고정 IP를 장기간 사용하지 마세요.
도메인별 조회와 대체 처리
해당 필드를 지원하는 커널에서는 서버 객체의 domains로 우선 매칭할 도메인 범위를 지정하고, expectIPs로 응답 주소 범위를 검사할 수 있습니다. 두 필드는 용도가 다릅니다. 앞의 필드는 조회 대상을 선택하고 뒤의 필드는 응답을 확인합니다. 라우팅 규칙과도 다릅니다. DNS가 조회 서버를 선택한 뒤에도 실제 트래픽 경로는 아웃바운드와 라우팅이 결정합니다. DNS 서버 그룹을 나눈 것만으로 연결 경로가 분기되었다고 보면 안 됩니다.
{
"dns": {
"servers": [
{
"address": "223.5.5.5",
"domains": ["geosite:cn"],
"expectIPs": ["geoip:cn"]
},
"1.1.1.1"
]
}
}이 예제는 사용할 수 있는 규칙 데이터 세트가 있어야 하며 우선 매칭과 일반 DNS 서버가 함께 설정되는 구조를 보여 줍니다. 실제 대체 동작은 커널이 지원하는 fallback 옵션에도 영향을 받습니다. 배열 순서를 항상 순차 실행되는 주 서버와 보조 서버의 대기열로 해석하지 마세요. 특정 조회가 다른 서버로 넘어가지 않게 하려면 주소 하나를 지우거나 수정하는 대신 해당 버전의 fallback 스위치를 확인하세요. 설정한 뒤에는 매칭되는 도메인과 매칭되지 않는 도메인을 각각 테스트해야 합니다.
DNS 트래픽 자체의 경로
일반 UDP DNS, HTTPS를 통한 DNS, 로컬 네트워크 스택을 사용하는 방식은 실제 아웃바운드가 서로 다를 수 있습니다. 일부 주소 형식은 커널 내부에서 전달되고, 일부 로컬 모드는 일반적인 라우팅 처리를 거치지 않습니다. DNS 서버 URL은 실제 커널 문서에 맞춰 작성해야 합니다. 일반 주소 앞에 접두어만 붙인다고 프록시를 사용한다고 가정할 수 없습니다. 특히 암호화된 DNS 연결을 시작할 때 DNS 서버 호스트 이름의 주소를 먼저 어떻게 얻는지 확인하세요.
원격 아웃바운드의 도메인과 원격 DNS 서버의 도메인이 서로 의존하면 시작 단계에서 순환이 생길 수 있습니다. 첫 연결이 실패하거나 네트워크 전환 후 오래 대기하고, 캐시가 있을 때는 정상인데 재시작하면 실패하는 식으로 나타날 수 있습니다. 프록시 연결 전에 사용할 수 있는 부트스트랩 DNS 경로를 만들고, 그 경로가 어떤 기본 도메인만 담당하는지 명확히 하세요. 한 번 발생한 시간 초과를 피하려고 모든 DNS 서버와 아웃바운드를 아직 연결되지 않은 하나의 경로에 묶지 마세요.
IPv4·IPv6와 캐시 차이
DNS에서 IPv6 주소를 받았다고 해서 기기에서 대상까지 IPv6 경로가 작동한다는 뜻은 아닙니다. 마찬가지로 IPv6를 끄는 것이 모든 시간 초과 문제의 해결책은 아닙니다. 조회 결과를 제한하기 전에 로컬 네트워크와 원격 서비스, 아웃바운드의 주소 계열 지원 여부를 확인하세요. 커널의 조회 정책 필드는 계열에 따라 다르므로 실제 지원 범위에 맞춰 설정해야 합니다. 인식되지 않는 필드로 네트워크 정책을 설정하지 마세요.
애플리케이션, 운영체제, 커널, 재귀 DNS 서버에 각각 캐시가 있을 수 있습니다. DNS를 바꾼 뒤 페이지를 새로고침해도 이전 동작이 이어진다고 해서 설정이 적용되지 않았다고 단정할 수는 없습니다. 먼저 애플리케이션 연결을 다시 만든 뒤 필요에 따라 해당 계층의 캐시를 비우고 새로운 조회를 관찰하세요. 제어 가능한 도메인이나 조회 시간을 기록해 테스트하세요. 대형 사이트의 IP 주소가 바뀌는지만 보고 DNS 서버 전환 여부를 판단하지 마세요.
웹페이지가 느린데 로그에 뚜렷한 DNS 오류가 없다면 첫 방문과 연속 방문을 나눠 비교하세요. 첫 방문이 느린 것은 DNS 조회나 핸드셰이크 때문일 수 있고, 다운로드가 계속 느리다면 회선, 부하, 로컬 처리 문제일 가능성이 더 큽니다. 더 자세한 내용은 인터넷 속도 저하의 단계별 진단 방법을 참고하세요. DNS, 노드, 라우팅을 동시에 바꾸면 실제로 효과가 있었던 항목을 확인하기 어렵습니다.
policy 정책, 로그 및 통계
policy는 연결 동작과 통계 기능을 관리하며 도메인 분기 규칙을 대신하지 않습니다. 사용자 레벨별로 핸드셰이크 대기 시간과 유휴 시간 제한을 설정하고 시스템 통계를 제어할 수 있습니다. 라우팅은 연결 경로를 정하고 정책은 연결을 관리합니다. 두 개념을 혼동하면 경로 문제에서 실제 원인은 건드리지 않은 채 시간 초과 설정만 반복해서 바꾸게 됩니다.
레벨과 시간 제한의 관계
levels의 키는 문자열 형식의 레벨 번호이며, 해당 기능을 지원하는 프로토콜 사용자 설정과 연결됩니다. 인바운드에 사용자가 명시되지 않았거나 프로토콜이 해당 레벨을 사용하지 않는다면 임의의 레벨 설정이 적용된다고 가정할 수 없습니다. 기본 레벨부터 확인하고 연결 동작을 살펴보세요. 레벨 번호는 우선순위나 대역폭 등급이 아닙니다. 특정 트래픽을 더 빠른 아웃바운드로 자동 전달하지 않습니다.
{
"policy": {
"levels": {
"0": {
"handshake": 4,
"connIdle": 300,
"uplinkOnly": 2,
"downlinkOnly": 5
}
},
"system": {
"statsInboundUplink": true,
"statsInboundDownlink": true,
"statsOutboundUplink": true,
"statsOutboundDownlink": true
}
},
"stats": {}
}여기서 시간 값의 단위는 초이며 모든 네트워크에 맞는 최적화 설정이 아니라 구조를 보여 주는 예시입니다. handshake는 핸드셰이크 대기 시간을, connIdle은 데이터 교환이 없는 유휴 시간을 제한합니다. 나머지 두 필드는 한 방향의 연결이 끝난 뒤 다른 방향을 기다리는 시간과 관련됩니다. 연결에 업무 데이터가 오랫동안 없으면 시간 초과는 정상 동작일 수 있습니다. 값을 무한정 늘려도 끊어진 네트워크 경로가 복구되지는 않으며 연결 정리만 늦어집니다.
오래 유지해야 하는 연결이라면 먼저 애플리케이션에 하트비트가 있는지, 서버가 지속 연결을 허용하는지, 네트워크 장비가 유휴 연결을 종료하는지 확인하세요. 커널의 유휴 시간을 바꾸는 것만으로 중간 장비의 제한을 바꿀 수 없습니다. 반대로 시간을 지나치게 짧게 설정하면 정상적인 저빈도 요청도 자주 다시 연결해야 할 수 있습니다. 연결이 끊기는 간격과 로그를 먼저 기록한 뒤 어느 계층에서 종료했는지 판단하세요. 모든 연결 끊김을 배터리 소모나 백그라운드 문제로 돌리지 마세요.
통계 스위치와 통계 화면은 다릅니다
예제에는 통계 객체와 시스템 통계 스위치가 함께 있지만, 이를 설정해도 접근 가능한 그래프나 관리 페이지가 자동으로 만들어지지는 않습니다. 통계를 읽으려면 해당 인터페이스와 클라이언트의 지원이 필요하며 일부 집계는 인바운드, 아웃바운드 태그, 사용자 식별자에 의존합니다. 화면의 수치가 갱신되지 않으면 라우팅 필드를 추가하기 전에 클라이언트가 해당 커널의 통계를 실제로 읽는지 확인하세요. 통계는 처리량을 보여 줄 뿐 원격 서비스 요청이 실패한 이유를 직접 설명하지 않습니다.
관리 인터페이스를 직접 설정한다면 리스닝 범위를 신뢰할 수 있는 로컬 네트워크로 제한하고 인터페이스 경로와 권한 범위를 이해해야 합니다. 도구가 쉽게 읽을 수 있게 하려고 관리 포트를 모든 네트워크 인터페이스에 바인딩하지 마세요. 일반 데스크톱 사용자는 클라이언트에서 제공하는 통계 기능을 우선 사용하세요. 별도 설정에는 실제로 필요한 항목만 남겨 불필요한 리스너와 유지 관리 부담을 줄이는 것이 좋습니다.
로그 수준과 문제 진단
{
"log": {
"loglevel": "info"
}
}이 로그 설정은 연결을 일시적으로 관찰하기 위한 예제입니다. 평소에는 필요한 수준만 기록하고 문제를 해결할 때 잠시 상세도를 높인 뒤 원래대로 되돌리세요. 액세스 로그, 오류 로그, 로그 상세 수준은 각각 다른 설정입니다. 로그 파일 경로를 지정하지 않았다면 클라이언트가 커널 출력을 어떻게 수집하는지도 확인해야 합니다. 파일에 기록하려면 쓰기 가능한 위치와 파일 크기 관리 방안을 정하세요. 어떤 플랫폼에서도 애플리케이션 설치 디렉터리에 쓸 수 있다고 가정하면 안 됩니다.
로그는 시간 순서로 연결해서 살펴보세요. 설정이 로드됐는지, 인바운드가 리스닝하는지, 요청이 들어왔는지, 어떤 아웃바운드를 선택했는지, 어느 단계에서 종료됐는지 확인합니다. 시간 초과 한 줄만 떼어 보면 원인을 찾기 어렵습니다. 앞선 DNS 조회 실패나 핸드셰이크 오류가 근본 원인일 수 있습니다. 로그를 공유하기 전에 서버 인증 정보, 구독 주소, 개인적으로 접근한 대상은 삭제하세요. 오류 유형과 발생 단계, 필요한 경우 익명화한 태그만 남기면 됩니다.
정책 변경의 검증 범위
연결 재사용, 캐시, 기존 연결 때문에 정책 변경 효과가 늦게 나타날 수 있습니다. 시간 제한을 바꿔도 애플리케이션의 기존 연결에 새 동작이 바로 적용되지 않을 수 있으므로 관련 연결을 다시 시작한 뒤 테스트하세요. 같은 대상과 같은 동작으로 테스트하고 유휴 시간과 재연결 여부를 기록하세요. 서버 부하 변화를 정책 효과로 오인하지 않도록 해야 합니다. 반복해서 재현할 수 있는 차이만 장기 설정으로 유지하세요.
안드로이드의 백그라운드 유지와 배터리 최적화는 운영체제의 작업 스케줄링에도 영향을 받으므로 connIdle을 늘리는 것만으로 해결되지 않습니다. v2rayNG가 시스템에 의해 종료되면 커널 설정만으로 계속 실행할 수 없습니다. 먼저 앱의 배터리 권한과 실행 모드를 확인하세요. 관련 내용은 v2rayNG 배터리 소모 및 백그라운드 실행 문제 해결을 참고하세요. 시스템과 커널을 각각 확인해야 실제 개선 없이 시간 제한만 늘려 배터리를 더 소모하는 일을 막을 수 있습니다.
전송 매개변수와 TLS 보안 계층
하나의 프록시 프로토콜은 여러 전송 방식으로 실행될 수 있고, 같은 전송 방식에 서로 다른 프로토콜을 실을 수도 있습니다. 설정은 안쪽에서 바깥쪽으로 프록시 프로토콜, 전송 방식, 보안 계층으로 나누어 이해하세요. 프로토콜은 사용자 인증과 요청 의미를 처리하고, 전송은 데이터가 서버에 도달하는 방식을 담당하며, 보안 계층은 해당 연결의 암호화와 서버 신원 확인을 맡습니다. 한 계층이 올바르다고 나머지 계층까지 자동으로 설정되는 것은 아닙니다.
streamSettings의 위치
streamSettings는 일반적으로 개별 아웃바운드 객체 안에서 protocol 및 settings와 같은 계층에 둡니다. 프로토콜 사용자 객체 안에 넣거나 최상위에 임의로 배치하는 필드가 아닙니다. 아래에는 WebSocket과 TLS 전송 설정 일부만 있으며 실제 서비스에서 제공한 아웃바운드 매개변수와 함께 사용해야 합니다. 도메인은 예약된 예제 이름이고 경로는 문법 설명용이므로 연결 가능한 원격 서비스가 아닙니다.
{
"streamSettings": {
"network": "ws",
"security": "tls",
"tlsSettings": {
"serverName": "gateway.example",
"allowInsecure": false
},
"wsSettings": {
"path": "/transport",
"headers": {
"Host": "gateway.example"
}
}
}
}서버 연결 주소는 이 설정 조각에 없으며 아웃바운드 프로토콜의 서버 설정에 지정합니다. serverName은 TLS 서버 이름과 인증서 확인에 사용되고 WebSocket의 Host는 애플리케이션 계층의 호스트를 선택합니다. 일부 구성에서는 둘이 같지만 서로 다른 역할을 하는 구성도 있습니다. 모두 도메인처럼 보인다는 이유만으로 서버 설명 없이 바꿔 쓰면 안 됩니다.
경로, 호스트, 인증서
WebSocket 경로는 서버의 수신 엔드포인트와 일치해야 합니다. 앞의 슬래시, 대소문자, 뒤에 붙는 문자열도 매칭 결과에 영향을 줄 수 있습니다. 경로가 틀려도 서버가 일반 웹페이지나 다른 HTTP 응답을 반환할 수 있지만 프록시 핸드셰이크가 성립한 것은 아닙니다. 서버 첫 화면이 열린다고 전송 엔드포인트 설정이 올바른 것은 아닙니다. 도메인을 브라우저로 열 수 있는지만 보지 말고 업그레이드 핸드셰이크와 커널 오류를 확인하세요.
인증서 검증에 실패하면 기기 시간, 인증서에 포함된 도메인, 신뢰 체인, 실제로 연결된 서비스를 먼저 확인하세요. allowInsecure로 검증을 끄면 보안 범위가 달라지므로 인증서 오류를 장기적으로 해결하는 방법으로 사용하면 안 됩니다. IP 주소로 연결하더라도 서비스 인증서가 도메인용이라면 올바른 서버 이름을 설정해야 합니다. 인증서 검증과 프록시 사용자 인증은 별개의 기능이므로 사용자 식별자를 바꿔도 도메인 불일치는 해결되지 않습니다.
전송 유형 간 설정 필드는 호환되지 않습니다
전송 방식을 바꾼다고 network 필드 하나만 수정하면 되는 것은 아닙니다. WebSocket 경로, gRPC 서비스 이름, 다른 전송의 매개변수는 각각 별도의 설정 객체에 속하며 서버 설정과 일치해야 합니다. 관련 없는 필드를 남겨 두면 무시될 수도 있고 설정 로드나 핸드셰이크 오류가 생길 수도 있습니다. 실제로 사용할 전송 설정만 남기고 서버에서 제공한 매개변수를 하나씩 대응하세요. 여러 공유 링크의 설정을 섞지 마세요.
기본 TCP, WebSocket, gRPC는 자원 사용량과 연결 관리, 배포 조건이 서로 다릅니다. 서버 환경과 무관하게 항상 가장 빠른 방식은 없습니다. 클라이언트에서 선택한 전송 방식에 해당하는 서버 엔드포인트가 없으면 연결할 수 없습니다. 성능을 조정할 때는 사용 가능한 전송 설정을 유지한 채 같은 네트워크에서 실제 동작을 비교하세요. 전송 방식의 이름만으로 속도가 보장된다고 생각하지 마세요.
| 필드 또는 개념 | 주요 역할 | 확인할 설정 출처 |
|---|---|---|
| 서버 주소 | 실제 연결 대상 지정 | 아웃바운드 서버 매개변수 |
| TLS serverName | 서버 이름 및 인증서 일치 여부 | 보안 계층 설정 |
| WebSocket Host 및 path | 애플리케이션 계층 엔드포인트 선택 | 서버 전송 설정 |
| gRPC serviceName | 대응하는 서비스 선택 | 양쪽에서 합의한 서비스 이름 |
커널 계열과 확장 기능
V2Fly와 Xray는 관련된 프록시 커널 생태계이지만 설정 기능은 각각 발전합니다. REALITY 같은 전용 보안 기능은 실제로 지원하는 커널을 사용하고 해당 커널의 필드 규격에 맞춰 설정해야 합니다. 이름만 바꿔 이 절의 TLS 예제에 적용하면 안 됩니다. JSON 구조가 비슷해 보여도 매개변수가 호환된다는 뜻은 아닙니다. 공유 링크를 가져온 뒤에는 클라이언트가 선택한 커널이 노드 요구 사항과 맞는지 확인하세요.
연결 재사용도 프로토콜과 서버 환경을 고려해야 합니다. 활성화하면 새 연결을 만드는 비용이 줄어들 수 있지만 특정 경로나 서비스에서는 동작이 달라질 수 있습니다. 장기 연결 하나에 문제가 있다면 재사용 설정을 추가하지 않은 기준 상태로 돌아가 다른 매개변수는 그대로 둔 채 비교하세요. 재사용, 전송, TLS, DNS를 한꺼번에 바꾸면 변화가 너무 많아 우연히 성공한 결과를 재현하기 어렵습니다.
로컬 인바운드가 정상이고 서버 포트에도 연결할 수 있지만 로그가 TLS 또는 전송 핸드셰이크 단계에서 멈춘다면 라우팅과 policy를 더 이상 변경하지 마세요. 시스템 시간, 서버 이름, 경로, 서비스 이름, 인증 설정이 모두 같은 설정에서 가져온 것인지 먼저 확인한 뒤 중간 리버스 프록시의 엔드포인트 매핑을 살펴보세요. 계층별로 확인하면 구독을 반복해서 가져오는 것보다 유효한 단서를 보존하기 쉽고, 정상 작동하던 규칙을 덮어쓰지도 않습니다.
설정 병합, 테스트 및 문제 발생 시 복구
설정을 유지 관리할 때 중요한 것은 필드를 많이 모으는 것이 아니라 각 변경의 이유를 설명하고 검증한 뒤 되돌릴 수 있도록 하는 것입니다. 시작하기 전에 현재 클라이언트, 실제 커널, 설정 출처, 기본 아웃바운드를 확인하고 정상 작동하는 기준 설정을 저장하세요. 기준 설정에는 JSON뿐 아니라 클라이언트의 현재 모드와 시스템 프록시 상태도 포함됩니다. 파일만 보관하고 외부 스위치 상태를 잊으면 복구 후에도 결과가 달라질 수 있습니다.
의존 관계에 따라 설정 조각 병합하기
먼저 시작 가능한 인바운드와 직접 연결 아웃바운드를 만든 다음 원격 아웃바운드, 대상 하나만 처리하는 라우팅 규칙, DNS와 정책 순으로 추가하세요. 기능상 제한 때문이 아니라 문제 해결에 필요한 의존 순서입니다. 인바운드가 연결되지 않으면 아웃바운드를 테스트할 수 없고, 아웃바운드가 없으면 규칙을 확인할 수 없으며, 기본 연결이 실패하면 시간 제한을 최적화할 의미가 없습니다. 각 단계가 성공하면 기록을 저장한 뒤 다음 단계로 넘어가세요. 문제가 생겼을 때 되돌릴 지점을 명확히 할 수 있습니다.
배열을 병합할 때는 항목을 추가하고 객체를 병합할 때는 키를 하나씩 대조하세요. 설정 조각을 파일 끝에 그대로 붙이지 마세요. 특히 routing, dns, log 필드의 중복과 같은 이름으로 여러 번 정의된 태그에 주의해야 합니다. 템플릿 도구가 일부 필드를 자동 생성한다면 객체 전체를 바꾸는지 배열 항목만 추가하는지 확인하세요. 내용이 모두 보이는 것보다 실제 병합 방식이 중요합니다.
시작 전후 점검
먼저 로컬 편집기의 JSON 검사 기능으로 문법을 확인한 다음 실제로 실행되는 커널에 설정 구조를 검사시키세요. 문법 검사를 통과해도 필드가 지원된다는 보장은 없고, 커널이 설정을 읽어도 원격 서버에 연결된다는 뜻은 아닙니다. 오류는 계층별로 확인하세요. 파싱 오류는 따옴표와 쉼표, 알 수 없는 필드는 커널 지원 범위, 리스닝 실패는 로컬 포트, 핸드셰이크 실패는 원격 매개변수를 먼저 살펴봅니다. 파일이 정상적으로 로드되기 전에 네트워크 테스트에 의존하지 마세요.
| 단계 | 검증 방법 | 실패 시 우선 확인할 항목 |
|---|---|---|
| 설정 로드 | 커널 시작 로그 확인 | JSON 계층 구조, 필드 지원 여부, 데이터 파일 |
| 로컬 연결 | 애플리케이션에서 로컬 프록시를 직접 지정 | 리스닝 주소, 포트, 인바운드 프로토콜 |
| 원격 연결 | 고정된 테스트 대상으로 요청 | 주소 조회, 인증, 전송, 보안 계층 |
| 라우팅 적용 | 요청에 연결된 아웃바운드 확인 | 매칭 조건, 규칙 순서, 태그 |
테스트 도구에서 프록시를 명시적으로 지정해 시스템 프록시 상태로 인한 혼동을 피하세요. 아래 요청은 로컬 SOCKS 인바운드가 HTTPS 대상 요청을 처리하는지 확인합니다. socks5h는 도메인 조회를 SOCKS 쪽에 맡긴다는 뜻입니다. 결과는 선택한 아웃바운드와 네트워크에 따라 달라지며, 지연 시간 평가나 모든 애플리케이션이 프록시에 연결됐다는 증거가 아닙니다. Windows에서는 프로그램 이름을 명시해 터미널 환경의 같은 이름 별칭으로 인한 차이를 방지할 수 있습니다.
curl.exe --proxy socks5h://127.0.0.1:10808 --head https://example.com
curl --proxy http://127.0.0.1:10809 --head https://example.com클라이언트 설정 재생성 및 구독 업데이트
v2rayN에서는 서버나 라우팅 프리셋을 바꾸거나 커널을 다시 시작할 때 실행 설정이 새로 생성될 수 있습니다. 직접 수정한 내용이 곧 사라진다면 임시 출력 파일을 계속 편집하지 말고 설정을 유지하는 메뉴를 찾으세요. 최초 설치 위치, 쓰기 권한, 시작 설정은 v2rayN 최초 설치 설정 체크리스트를 참고하고 기본 연결 순서는 빠른 시작 가이드에서 확인하세요.
구독을 업데이트하면 서버 항목, 노드 이름, 선택 가능한 매개변수도 바뀔 수 있습니다. 사용자 지정 규칙이 자주 바뀌는 항목 이름에 의존한다면 클라이언트가 이를 실행 태그에 어떻게 연결하는지 확인하세요. 화면에 표시되는 이름이 항상 아웃바운드 태그와 같다고 가정해서는 안 됩니다. 여러 구독을 관리하는 방법은 구독 그룹 및 필터링 방법을 참고하세요. 업데이트 전후의 구조 차이를 보관하면 업데이트 후 문제가 생겼다는 기록만 남기는 것보다 원인을 찾기 쉽습니다.
자주 묻는 질문과 복구 순서
설정이 시작되는데 애플리케이션은 왜 계속 직접 연결되나요?
애플리케이션이 시스템 프록시를 따르는지, 현재 인바운드를 직접 사용하도록 설정했는지 먼저 확인하세요. 그다음 기본 아웃바운드와 라우팅 매칭 결과를 살펴봅니다. 커널 프로세스가 실행 중이라는 것은 프로그램이 시작됐다는 뜻일 뿐, 해당 애플리케이션의 요청이 커널을 거친다는 뜻은 아닙니다.
규칙을 바꿨는데 기존 연결은 왜 이전 경로를 계속 사용하나요?
이미 연결된 세션은 규칙이 바뀌어도 보통 자동으로 경로를 전환하지 않습니다. 관련 애플리케이션의 기존 연결을 종료하고 새 요청을 보낸 뒤 새로운 연결 로그를 확인하세요. 필요하면 커널 설정을 다시 불러오고 클라이언트가 방금 수정한 내용을 덮어쓰지 않았는지도 확인합니다.
연결이 갑자기 끊기면 어떤 설정부터 복원해야 하나요?
마지막으로 정상 작동한 커널 설정과 클라이언트 모드를 복원한 뒤 인바운드 하나와 대상 하나만 테스트하세요. 실패 로그를 보관하고 수정 사항을 하나씩 다시 적용합니다. 기준 설정도 실패한다면 네트워크와 서버 상태, 구독 매개변수에 변경이 있었는지 확인하세요.
최종 검증 기록에는 네 가지가 명확히 남아야 합니다. 요청이 들어온 인바운드, 대상이 도메인인지 IP인지, 일치한 규칙, 연결을 만든 아웃바운드입니다. '작동함'이라는 기록만으로는 분기가 올바른지 증명할 수 없고, '시간 초과'만으로는 오류가 발생한 계층을 판단할 수 없습니다. 성공과 실패 사례를 같은 연결 경로에 따라 기록하면 설정 전체를 다시 작성하지 않고도 원인을 몇 개의 필드로 좁힐 수 있습니다.
유지 관리가 끝나면 적절한 로그 수준으로 되돌리고 더 이상 필요하지 않은 테스트 인바운드와 임시 정적 매핑을 삭제한 뒤 클라이언트가 인정하는 위치에 장기 설정을 저장하세요. 여러 프리셋을 쌓기보다 간결하고 설명 가능한 규칙을 유지하는 편이 관리하기 쉽습니다. 이후 연결 방법만 필요하면 가이드를 참고하고, 필드의 의미와 의존 관계 또는 병합 방법을 확인하려면 이 페이지의 목차에서 해당 절로 이동하세요.