inbounds: 로컬 앱의 진입점
인바운드는 코어가 요청을 받을 주소와 포트, 사용할 프록시 프로토콜을 정의합니다. 이 기기의 앱은 보통 루프백 주소에 연결해 프록시 포트가 로컬 네트워크에 노출되지 않도록 합니다. 예시의 SOCKS와 HTTP는 서로 다른 포트를 수신하므로 앱에서도 해당 프로토콜을 맞춰 입력해야 합니다. 포트 번호는 고정된 표준이 아니므로 클라이언트 설정의 실제 값을 기준으로 삼으세요. 시스템 프록시와 달리 인바운드 설정만으로 브라우저에 프록시 사용을 알리지는 않습니다. 양쪽 설정이 모두 맞아야 요청이 코어에 전달됩니다.
{
"inbounds": [
{
"tag": "socks-in",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": { "auth": "noauth", "udp": true }
},
{
"tag": "http-in",
"listen": "127.0.0.1",
"port": 10809,
"protocol": "http",
"settings": {}
}
]
}
outbounds: 아웃바운드 프로토콜과 tag
아웃바운드는 수신한 요청을 목적지로 전달합니다. 직접 연결에는 freedom, 차단에는 blackhole을 사용하며, 프록시 아웃바운드에는 해당 프로토콜의 원격 서버 설정이 필요합니다. tag는 설정 내부에서 참조하는 이름이지 프로토콜명이 아닙니다. routing의 outboundTag는 tag와 정확히 일치해야 합니다. 예시에는 직접 연결과 차단만 있으며 원격 프록시는 포함되지 않습니다. 일반적인 설정은 라우팅 규칙에 해당하지 않을 때 첫 번째 아웃바운드를 사용하므로 배열 순서에 따라 기본 경로가 바뀔 수 있습니다. 규칙 목록만 확인해서는 안 됩니다.
{
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
},
{
"tag": "block",
"protocol": "blackhole",
"settings": {}
}
]
}
routing: 먼저 규칙을 적용한 뒤 아웃바운드 선택
라우팅 규칙은 위에서 아래 순서로 검사하며, 조건에 맞으면 해당 아웃바운드를 선택합니다. 앞선 규칙이 요청을 먼저 처리하지 않도록 구체적인 도메인 또는 주소 규칙을 포괄적인 규칙보다 위에 두세요. 예시에서는 사설 주소를 direct로 전달하며, 해당 아웃바운드가 설정에 있어야 합니다. IPIfNonMatch는 도메인 규칙이 일치하지 않을 때 주소를 조회해 다시 판단한다는 뜻이지, 모든 앱이 내장 DNS를 사용한다는 뜻은 아닙니다. geoip와 geosite가 참조하는 데이터 목록도 준비되어 있어야 하며 규칙 텍스트에 데이터가 포함되는 것은 아닙니다.
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}
dns: 리졸버 설정만으로 모든 DNS 요청을 처리하지는 않음
dns 모듈은 코어 내장 리졸버가 사용할 서버를 설정합니다. 실제로 언제 DNS 조회에 사용되는지는 라우팅 정책과 아웃바운드 설정, 앱이 도메인과 IP 주소 중 무엇을 전달하는지에 따라 달라집니다. 예시에는 hosts 정적 매핑과 DNS 서버의 기본 구조가 담겨 있습니다. 이 필드를 추가하는 것만으로 모든 DNS 트래픽을 처리할 수 있는 것은 아닙니다. 브라우저의 암호화 DNS, 시스템 리졸버, 코어 리졸버가 함께 작동할 수도 있습니다. 조회 경로를 확인하려면 요청이 어디서 시작되어 어떤 아웃바운드로 전송되는지 각각 살펴보세요.
{
"dns": {
"hosts": {
"domain:example.com": "192.0.2.1"
},
"servers": [
"https://1.1.1.1/dns-query"
],
"queryStrategy": "UseIPv4"
}
}
policy: 레벨별 연결 동작 설정
policy는 사용자 레벨별 연결 정책을 정의합니다. 예를 들어 핸드셰이크 대기 시간과 유휴 연결 제한 시간을 설정할 수 있습니다. levels의 숫자 키는 레벨을 나타내며 서버 번호가 아닙니다. 정책을 적용하려면 관련 사용자 설정에서 해당 level을 지정해야 합니다. 예시의 시간 단위는 초이며, 값은 구조를 보여 주기 위한 것으로 모든 네트워크에 적합한 최적 설정은 아닙니다. 제한 시간이 너무 짧으면 느린 핸드셰이크나 장시간 연결이 끊길 수 있습니다. 연결이 중단되면 로그와 네트워크 상태를 먼저 확인하고 한 번에 하나의 매개변수만 바꿔 결과를 비교하세요.
{
"policy": {
"levels": {
"0": {
"handshake": 4,
"connIdle": 300,
"uplinkOnly": 2,
"downlinkOnly": 5
}
}
}
}
subscription: 클라이언트 관리 항목
구독은 클라이언트에서 관리하며 V2Ray 코어 JSON의 최상위 키가 아닙니다. 클라이언트는 구독 내용을 읽어 실행 가능한 설정으로 변환합니다. 구독을 업데이트해도 코어가 업그레이드되는 것은 아닙니다. 구독 주소에 접근 자격 증명이 포함될 수 있으므로 스크린샷이나 공개 로그에 노출하지 마세요. 아래는 유효한 코어 설정 일부로, 최종 설정에서 아웃바운드가 위치하는 곳을 보여 줍니다. 구독 형식의 예시는 아닙니다. 직접 연결 아웃바운드만 포함하므로 구독 가져오기를 대신할 수 없습니다. 실제 프록시 설정은 이미 유효한 연결 정보로 생성해야 합니다.
{
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
}
]
}