v2rayN 다운로드
설정 가이드

구독을 이용하면 여러 서버 설정을 하나의 업데이트 경로에서 관리할 수 있습니다. 먼저 그룹을 만든 다음 사용 권한이 있는 주소를 붙여 넣고, 업데이트 후 목록에 실제 설정이 나타났는지 확인하세요. 일반 업데이트에 실패하면 기존 연결이 작동하는 경우 프록시를 통한 업데이트를 시도할 수 있습니다. 구독 주소에는 접속 정보가 포함될 수 있으므로 스크린샷이나 공개 로그에 노출하지 마세요. 설정을 하나씩 입력하는 것보다 그룹을 사용하면 출처와 업데이트 범위를 관리하기 쉽습니다. 다만 사용자 지정 메모, 정렬 순서, 라우팅은 별도로 백업하세요. 원격 업데이트가 로컬 설정까지 영구 보관해 주는 것은 아닙니다. 오른쪽 예시는 JSON에서 URL을 저장하는 방식이며, 클라이언트 구독 파일 형식이 아닙니다.

{
  "url": "https://example.com/sub"
}

VMess, VLESS, Trojan은 서로 다른 아웃바운드 프로토콜이며 임의로 바꿔 쓸 수 있는 라벨이 아닙니다. 가져온 뒤에는 포트, 전송 방식, TLS 같은 보안 설정도 확인하세요. 프로토콜이 같더라도 모든 매개변수가 호환되는 것은 아닙니다. 그래픽 클라이언트에서는 여러 설정을 저장하고 전환할 수 있지만, 실제 실행 여부는 선택한 코어에 달려 있습니다. 먼저 서버에서 제공한 매개변수를 그대로 사용하고 연결에 성공한 뒤 전송 옵션을 조정하세요. 오른쪽은 direct와 block의 기본 아웃바운드 예시로, 라우팅에서 tag를 참조하는 방식을 이해하는 데 도움이 됩니다. 원격 서버 정보는 포함되어 있지 않으므로 사용할 수 있는 프록시 설정을 대신하지 않습니다.

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ]
}

라우팅은 연결을 어떤 아웃바운드로 보낼지 결정합니다. 규칙은 위에서 아래로 검사되므로 예외 규칙은 대체로 범위가 넓은 규칙보다 앞에 둡니다. geosite는 도메인 목록, geoip는 IP 주소 목록을 사용하며 각각 관련 데이터베이스가 필요합니다. 처음에는 로컬 네트워크 주소를 직접 연결하는 규칙처럼 명확한 항목만 두고 필요한 도메인을 하나씩 추가하세요. 모든 트래픽을 같은 경로로 보내는 것보다 분할 라우팅을 사용하면 로컬 서비스에 미치는 영향을 줄일 수 있지만, 규칙 순서와 아웃바운드 태그를 관리해야 합니다. 예시의 direct는 실제 아웃바운드에 존재해야 합니다. 수정 후에는 구체적인 대상에 규칙이 적용되는지 확인하세요. 규칙이 저장됐다는 사실만으로 작동한다고 판단하지 마세요.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

DNS 설정은 주소 조회 서버를 입력하는 데 그치지 않습니다. 누가 조회를 요청하는지, 어떤 경로로 전달되는지, 조회 결과가 라우팅에 어떻게 반영되는지도 관련됩니다. 코어에 내장된 DNS가 시스템의 모든 앱에서 자동으로 사용되는 것은 아닙니다. 도메인 접속에 실패하면 먼저 이름 조회 오류인지 연결 오류인지 구분한 뒤 조회 정책과 실제 아웃바운드를 확인하세요. 조회 서버를 계속 바꾸기보다 앱·시스템·코어의 역할을 분명히 나누는 편이 도움이 됩니다. 예시는 서버 목록과 IPv4 조회 정책을 작성하는 방법이며 모든 네트워크에 권장되는 값은 아닙니다. 수정 전에 기존 설정을 기록하고 한 번에 한 항목씩 바꿔야 무엇이 영향을 줬는지 알 수 있습니다.

{
  "dns": {
    "servers": [
      "1.1.1.1",
      "localhost"
    ],
    "queryStrategy": "UseIPv4"
  }
}

시스템 프록시는 시스템 설정을 따르는 앱이 로컬 프록시를 사용하게 합니다. TUN은 가상 네트워크 인터페이스로 트래픽을 처리하므로 필요한 권한과 적용 범위가 다릅니다. 처음에는 시스템 프록시로 연결을 확인한 뒤 필요에 따라 TUN을 살펴보세요. 오른쪽은 로컬 SOCKS 인바운드 예시이지 TUN 설정이 아닙니다. 루프백 주소에서 수신하면 이 기기에서 시작된 연결만 허용됩니다. 로컬 네트워크 전체에 수신을 개방하는 것보다 접근 범위를 제어하기 쉽습니다. 다른 기기의 연결이 꼭 필요하다면 방화벽, 인증, 네트워크 경계도 함께 확인하세요. 수신 주소를 모든 인터페이스로 바꾸는 것만으로 설정이 끝나는 것은 아닙니다.

{
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ]
}

클라이언트 인터페이스와 프록시 코어는 서로 다른 역할을 합니다. 인터페이스에 옵션이 표시되더라도 현재 코어가 해당 필드를 인식한다는 뜻은 아닙니다. 코어를 바꾸기 전에 설정에서 사용하는 프로토콜, 전송 방식, 보안 기능을 확인하고 코어의 지원 범위를 살펴보세요. 이름만 비교하는 것보다 시작 로그를 확인하면 지원되지 않는 필드나 매개변수를 더 정확히 찾을 수 있습니다. 작동하는 설정을 별도로 보관하고, 코어를 바꾼 뒤에는 최소한의 연결부터 테스트한 다음 사용자 지정 라우팅과 DNS를 복원하세요. 오른쪽은 일반적인 로그 수준 예시이지 코어 선택 스위치가 아닙니다. 코어는 보통 클라이언트 설정에서 선택하며 JSON에 임의의 필드를 추가한다고 바뀌지 않습니다.

{
  "log": {
    "loglevel": "warning"
  }
}