V2Ray 설정 파일 참고.

01 / STRUCTURE

JSON 구조와 설정 적용 범위

실제로 불러온 파일부터 확인

설정 파일은 코어가 연결을 받고, 출구를 선택하고, 도메인을 확인하는 방식을 정의하지만 클라이언트의 모든 설정을 담지는 않습니다. v2rayN의 구독 그룹, 인터페이스 환경설정, 시스템 프록시 옵션은 클라이언트가 관리하며, 코어는 보통 클라이언트가 생성한 실행 설정만 읽습니다. 문제를 확인하기 전에 현재 선택된 코어와 실행 디렉터리, 로그에 기록된 설정 파일 경로부터 확인하세요. 디스크에 config.json이라는 파일이 여러 개 있을 수 있으며, 실제로 불러오지 않는 파일을 수정해도 연결 동작은 달라지지 않습니다.

JSON의 최상위 요소는 보통 객체이며, 각 모듈은 키 이름으로 구분됩니다. inbounds와 outbounds는 배열입니다. 하나의 프로세스가 여러 로컬 연결 지점을 받고 여러 출구를 사용할 수 있기 때문입니다. routing, dns, policy는 객체입니다. 인터페이스에서 옵션이 나열된 위치만 보고 중첩 구조를 추측하지 마세요. 필드 이름이 맞더라도 잘못된 단계에 넣으면 무시되거나 코어가 설정을 불러오지 못할 수 있습니다.

최소 구성으로 모듈 관계 파악하기

다음은 로컬 SOCKS 인바운드에서 직접 연결 아웃바운드로 이어지는 기본 설정입니다. 원격 프록시 서버는 포함하지 않습니다. 로컬에서 수신하고 요청을 받아 직접 연결하는 흐름이 완성되는지 확인하기 위한 예제입니다. 애플리케이션이 이 SOCKS 엔드포인트를 사용해야 트래픽이 코어로 전달됩니다. 두 개의 tag는 설정 내부에서 사용하는 이름이므로 자유롭게 정할 수 있지만, 해당 이름을 참조하는 부분도 함께 바꿔야 합니다. 태그는 프로토콜 이름과 다르며, 해당 이름만 지정한다고 출구가 자동으로 만들어지지는 않습니다.

{
  "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": {}
    }
  ]
}

설정을 읽을 때는 요청 흐름을 따라가 보세요. 애플리케이션이 로컬 리스닝 주소에 연결하고, 인바운드가 SOCKS 요청을 해석한 다음, 라우팅이 출구를 선택하고, 아웃바운드가 목적지에 연결합니다. 라우팅 규칙을 따로 지정하지 않으면 일반적으로 첫 번째 아웃바운드가 기본 출구로 사용됩니다. 아웃바운드를 하나 더 추가해도 트래픽이 자동 분산되지는 않습니다. 규칙이나 다른 명시적인 설정에서 참조해야 합니다. 이 기본 동작을 이해하면 많은 매개변수를 외우지 않고도 실제 동작을 설명할 수 있습니다.

문법과 의미가 모두 올바른지 확인

표준 JSON에는 주석, 마지막 쉼표, 작은따옴표로 묶은 문자열을 사용할 수 없습니다. 포트는 숫자로, 불리언 옵션은 true 또는 false로 작성해야 하며, 따옴표로 묶은 같은 단어로 대신할 수 없습니다. 문자열에서 역슬래시는 이스케이프 문자로 쓰이므로 경로나 정규식을 직접 작성할 때 특히 주의해야 합니다. 편집기에서 서식 지정이 된다고 해서 텍스트 구조가 기본적으로 올바르다는 뜻일 뿐, 해당 필드를 프로토콜이 지원하거나 원격 서버 설정과 일치한다는 보장은 없습니다.

이후에 나오는 코드 대부분은 최상위 모듈의 일부를 발췌한 것으로, 필드 간 관계를 설명하기 위한 예제입니다. 각 조각을 그대로 실행할 수 있는 것은 아닙니다. 조각을 합칠 때는 같은 이름의 기존 모듈을 교체하고, 하나의 객체에 같은 키를 중복으로 추가하지 마세요. 중복 키는 파서마다 처리 방식이 다를 수 있어 파일을 수정했는데도 실행 결과가 그대로인 것처럼 보일 수 있습니다. 배열 내부의 쉼표와 괄호도 올바르게 유지해 한 출구의 설정 안에 다른 출구를 잘못 넣지 않도록 하세요.

버전 호환성은 클라이언트 이름이 아니라 실제 사용 중인 코어를 기준으로 판단해야 합니다. 같은 클라이언트에서도 코어를 바꿀 수 있고, 배포 패키지에 따라 지원 기능이 다를 수 있습니다. 필드를 확인할 때 모듈, 필드 경로, 값 유형, 지원 코어를 함께 기록하고, 알 수 없는 필드는 설정 범위를 좁혀 확인하세요. 인터넷에서 찾은 옵션을 계속 추가하며 시험하지 마세요. 재현 가능한 요청 하나를 남겨 인바운드, 라우팅, 아웃바운드를 차례로 점검하면 실제 차이를 찾기 쉽습니다.

02 / INBOUNDS

inbounds: 리스닝 주소와 인바운드 프로토콜

리스닝 범위에 따라 엔드포인트를 사용할 수 있는 대상이 달라집니다

인바운드는 먼저 연결 가능한 로컬 엔드포인트를 정의합니다. listen은 바인딩할 주소, port는 포트, protocol은 연결에서 받은 데이터를 해석할 프로토콜을 지정합니다. 로컬 프로그램만 사용할 경우 127.0.0.1에 바인딩하는 것이 좋습니다. 모든 인터페이스에서 수신하도록 바꾸면 같은 네트워크의 다른 기기가 해당 포트에 접근할 수 있습니다. 실제 접근 가능 여부는 방화벽과 네트워크 환경에 따라 달라지므로, 접근 제어를 고려하지 않고 주소만 바꾸면 안 됩니다.

주소와 포트는 함께 확인해야 합니다. 애플리케이션에 설정한 프록시 주소는 현재 기기에서 실행 중인 코어를 가리켜야 합니다. 휴대폰의 루프백 주소는 휴대폰 자신을 가리킬 뿐 옆에 있는 컴퓨터를 가리키지 않습니다. IPv4 루프백에서 수신한다고 해서 IPv6 루프백에서도 수신하는 것은 아닙니다. 애플리케이션에서 localhost로 연결하면 실패하지만 루프백 IP 주소를 직접 입력하면 연결되는 경우, 원격 서버 문제로 단정하지 말고 이름 해석 결과와 리스닝 주소 계열을 확인하세요.

SOCKS와 HTTP 인바운드의 차이

SOCKS 인바운드는 보통 SOCKS 프록시를 지원하는 애플리케이션에서 사용하고, HTTP 인바운드는 HTTP 프록시 요청과 애플리케이션이 CONNECT로 만드는 터널을 받습니다. 두 방식 모두 브라우저 트래픽을 특정 웹 프로토콜로 강제 변환하거나 시스템 프록시를 자동으로 활성화하지 않습니다. 애플리케이션에서 인바운드와 일치하는 프록시 유형을 선택하세요. 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": {}
    }
  ]
}

여기서 SOCKS UDP 기능을 켠다는 것은 해당 인바운드가 관련 요청을 허용한다는 뜻일 뿐, 모든 UDP 애플리케이션의 트래픽이 이 경로를 사용한다는 보장은 없습니다. 애플리케이션이 SOCKS UDP 사용 방식을 지원해야 하며, 출구와 원격 서비스도 해당 전달 방식을 지원해야 합니다. 시스템 프록시가 모든 애플리케이션이나 임의의 UDP 트래픽을 처리하는 것은 아닙니다. 따라서 웹은 되는데 특정 실시간 애플리케이션이 실패하더라도 노드가 작동하지 않는다고 단정할 수 없습니다. 먼저 애플리케이션이 어떤 방식으로 연결되는지 확인한 뒤, 이후 경로가 필요한 전송 방식을 지원하는지 점검하세요.

스니핑으로 대상 정보 보완하기

일부 라우팅 규칙에는 도메인 정보가 필요하지만, 애플리케이션이 코어에 전달할 때는 대상 IP만 제공할 수 있습니다. 인바운드의 스니핑 기능은 연결 초기 부분에서 HTTP 호스트 이름이나 TLS 핸드셰이크의 서버 이름을 찾아 라우팅에 활용할 정보를 보완할 수 있습니다. 일반적인 콘텐츠 복호화 기능은 아니며 모든 연결에서 도메인을 알아낼 수 있는 것도 아닙니다. 코어에 따라 지원하는 스니핑 프로토콜과 옵션이 다르므로 관련 필드를 추가하기 전에 현재 코어 문서를 확인하세요. 다른 코어의 예제를 통째로 복사하지 마세요.

스니핑에서는 ‘라우팅 판단에만 사용할지’와 ‘연결 대상을 바꿀지’도 구분해야 합니다. 일부 코어는 라우팅에만 영향을 주는 옵션을 제공하며, 원래 대상 주소를 변경하고 싶지 않을 때 유용합니다. 다만 모든 코어에서 지원되는 필드는 아닙니다. 문제를 확인할 때는 먼저 추가 스니핑을 끄고, 도메인이나 IP가 명확한 요청 하나가 성공하는지 확인한 뒤 항목별로 켜세요. 그렇지 않으면 인바운드의 원래 대상과 스니핑으로 얻은 이름이 뒤섞여 로그의 라우팅 결과를 해석하기 어려워집니다.

인바운드가 시작되지 않는 흔한 로컬 원인은 포트 충돌, 존재하지 않는 리스닝 주소, 권한 제한입니다. 한 기기에서 주소와 포트가 같은 클라이언트 두 개를 동시에 실행하면 보통 둘 다 리스닝할 수 없습니다. 충돌을 피하려고 리스닝 범위를 무작정 넓히지 마세요. 사용하지 않는 클라이언트를 종료하거나 계획적으로 포트를 변경한 뒤, 애플리케이션의 프록시 설정도 함께 업데이트하세요. 자세한 오류 확인 절차는 로그 확인을, 시스템 프록시 사용 방법은 사용 가이드를 참고하세요.

03 / OUTBOUNDS

outbounds: 아웃바운드 프로토콜과 전송 설정

아웃바운드 태그와 기본 순서

아웃바운드는 요청을 코어에서 목적지나 원격 프록시 서버로 전달합니다. protocol은 아웃바운드 프로토콜을 선택하고, settings에는 해당 프로토콜의 매개변수를 저장하며, streamSettings는 하위 전송 방식과 전송 보안을 설정합니다. 태그는 내부에서 대상을 참조하는 이름일 뿐입니다. 아웃바운드 이름을 proxy로 지정해도 프록시 기능이 생기지는 않습니다. 실제 객체와 유효한 매개변수가 있어야 하며, 라우팅 규칙에 선택되거나 기본 아웃바운드 위치에 있어야 요청을 처리합니다.

기본 설정에는 프록시, 직접 연결, 차단 아웃바운드가 함께 포함되는 경우가 많습니다. freedom 직접 연결은 코어가 실행 중인 기기에서 대상에 연결하고, blackhole은 규칙에 일치하는 요청을 종료합니다. ‘직접 연결’은 로컬 네트워크 스택을 거치지 않는다는 뜻도, 시스템 가상 네트워크 인터페이스를 반드시 우회한다는 뜻도 아닙니다. TUN이나 다른 전체 트래픽 처리 방식을 사용한다면 코어 자체 연결에 올바른 우회 경로가 있는지 확인하세요. 그렇지 않으면 요청이 다시 코어로 들어가는 루프가 발생할 수 있습니다.

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

노드 인증 정보와 전송 보안은 따로 확인

원격 프록시 아웃바운드에는 보통 서버 주소와 포트, 프로토콜에 필요한 인증 정보가 포함됩니다. VMess, VLESS, Trojan, Shadowsocks는 인증 정보 구조가 서로 다르므로 protocol만 바꾼다고 설정이 다른 프로토콜로 바뀌지는 않습니다. 구독을 가져오면 클라이언트가 노드 유형에 맞는 필드를 생성해 준다는 장점이 있습니다. 직접 수정할 때는 서비스 제공자가 안내한 정보를 항목별로 확인하고, 공유 링크의 모양만 보고 암호화 방식이나 전송 경로, 보안 설정을 추측하지 마세요.

아래는 Trojan 아웃바운드에서 흔히 사용하는 구조를 보여주는 예제입니다. proxy.example.com과 예시 비밀번호는 구조 설명용이므로 실제 서버에 연결할 수 없습니다. 서비스 제공자가 안내한 주소, 포트, 비밀번호, 인증서 이름으로 바꿔야 합니다. 이 예제는 앞의 직접 연결 예제와 용도가 다르므로 최상위 객체 전체를 그대로 합치지 마세요. 실제 사용 전에는 현재 코어가 해당 프로토콜과 전송 필드를 지원하는지도 확인하세요.

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "trojan",
      "settings": {
        "servers": [
          {
            "address": "proxy.example.com",
            "port": 443,
            "password": "your-password"
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "proxy.example.com",
          "allowInsecure": false
        }
      }
    }
  ]
}

전송 방식은 연결에서 데이터를 어떻게 전달하는지, TLS는 전송 보안을 어떻게 협상하는지, 프록시 프로토콜은 양쪽이 프록시 요청을 어떻게 주고받는지를 정의합니다. 이 세 가지를 각각 원격 서버 설정과 일치시켜야 합니다. 서버가 지원하는 전송 방식, 경로의 대소문자 구분 여부, 특정 호스트 이름의 필요 여부는 서버 설정을 기준으로 확인하세요. 클라이언트의 한 계층을 바꿔도 서버가 자동으로 바뀌지는 않습니다. 설정이 서로 맞지 않으면 즉시 연결이 끊기거나 핸드셰이크가 실패할 수 있고, 응답 없이 시간 초과될 수도 있습니다.

인증서 이름과 서버 주소는 서로 다른 필드

서버 주소는 원격 서버를 찾는 데 사용하고, TLS의 serverName은 핸드셰이크의 서버 이름 표시와 인증서 검증에 사용합니다. 일부 환경에서는 두 값이 다를 수 있습니다. 도메인을 IP 주소로 바꾸더라도 인증서에 해당하는 서버 이름은 그대로 유지해야 할 수 있습니다. 이름 오류를 장기적으로 덮기 위해 인증서 검증을 끄지 마세요. 먼저 시스템 시간, 인증서 적용 범위, 입력한 이름이 서로 맞는지 확인한 다음 서버 인증서 체인이나 네트워크 연결 문제를 살펴보세요.

연결 재사용, 하위 소켓, 고급 전송 매개변수는 이후에 조정할 최적화 항목이지 첫 설정의 필수 조건이 아닙니다. 노드가 기본 설정으로 작동한 뒤 특정 애플리케이션에서 연결이 반복 생성되거나 장시간 연결이 끊기는 문제가 있는지 확인하고, 코어가 지원하는 범위에서 조정하세요. ‘최적화 매개변수’를 한꺼번에 적용하면 변수가 여러 개 바뀌어 실패 원인을 재현하기 어렵습니다. 속도 측정 결과만 보고 프로토콜 인증 필드를 바꾸지 마세요. 성능 조정용 옵션이 아닙니다.

아웃바운드가 정상적으로 시작되지만 연결에 실패한다면 도메인 확인 실패, 원격 포트 연결 실패, TLS 협상 실패, 프로토콜 인증 실패를 구분해야 합니다. 앞 단계가 성공하지 않았다면 뒤 단계를 확인해도 의미가 없습니다. 인증서 관련 문제는 TLS 핸드셰이크와 SNI 문제 해결 노트를 참고하세요. 그래픽 클라이언트를 설치하거나 바꾸려는 경우에는 클라이언트 페이지에서 선택하면 됩니다. 코어 다운로드 페이지를 따로 찾을 필요는 없습니다.

04 / ROUTING

routing: 규칙 순서와 트래픽 분기

규칙은 순서대로 확인하며, 더 정밀한 규칙이 자동으로 앞에 오지 않습니다

라우팅 모듈은 연결 정보와 규칙을 차례로 비교한 뒤 일치하는 요청을 지정된 아웃바운드로 전달합니다. 흔히 사용하는 규칙은 type: "field"이며 도메인, 대상 IP, 포트, 네트워크 유형, 인바운드 태그 등을 기준으로 판단합니다. 규칙은 위에서 아래로 확인하며, 일반적으로 먼저 일치한 규칙이 결과를 결정합니다. 따라서 범위가 넓은 규칙보다 구체적인 예외를 앞에 배치하세요. 모든 연결을 처리하는 규칙을 맨 위에 두면 뒤에 있는 세부 규칙은 내용이 올바르더라도 실제로 적용되지 않습니다.

한 규칙에 여러 조건 필드를 지정하면 보통 모든 조건을 함께 충족해야 합니다. 같은 배열에 여러 후보를 넣으면 일반적으로 그중 하나만 일치해도 됩니다. 예를 들어 도메인 배열에는 여러 사이트를 넣을 수 있지만, 포트 조건도 함께 지정하면 요청 포트도 해당 조건을 만족해야 합니다. 서로 다른 용도의 조건을 한 규칙에 몰아넣고 서로 대체할 거라고 기대하지 마세요. 규칙을 읽을 때 ‘어떤 인바운드에서 어떤 대상에 어떤 네트워크로 접속해 어느 아웃바운드로 보낼지’를 먼저 말로 정리한 다음, 코드가 같은 의미인지 확인하면 됩니다.

도메인·정확히 일치·IP 대역

domain:은 도메인과 하위 도메인 범위를 지정할 때, full:은 도메인 전체가 정확히 일치해야 할 때 사용합니다. regexp:는 정규 표현식으로 처리합니다. 프록시 연결 계층에서는 보통 웹 페이지 경로 전체를 볼 수 없으므로 규칙에 웹 경로를 넣을 필요가 없습니다. 프로토콜과 경로가 포함된 URL을 도메인 조건으로 사용하면 대개 일치하지 않습니다. 고정 호스트 이름에는 단순한 매칭을 우선 사용하고, 패턴이 꼭 필요할 때만 정규식을 사용하면 유지 관리와 이스케이프 확인이 쉽습니다.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:telemetry.example.com"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "127.0.0.0/8",
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16",
          "::1/128",
          "fc00::/7"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

이 조각은 block과 direct 태그가 붙은 아웃바운드가 이미 있다고 가정합니다. 첫 번째 규칙은 두 번째 규칙의 적용 범위 안에 있는 예외이므로 앞에 놓아야 합니다. 사설 네트워크 대역 예제는 표시된 주소만 처리하며, 모든 특수 목적 네트워크를 포함하지는 않습니다. 링크 로컬 주소 같은 범위가 필요한 환경에서는 네트워크 용도에 맞게 추가하세요. 일치하는 규칙이 없으면 기본 아웃바운드가 사용됩니다. 마지막 규칙에 직접 연결이 있다고 해서 나머지 모든 연결이 직접 연결되는 것은 아닙니다.

domainStrategy는 라우팅을 위해 도메인을 확인하는 시점을 결정

AsIs는 현재 제공된 대상 정보를 기준으로 판단하며, IP 조건을 보완하기 위해 도메인을 적극적으로 확인하지 않습니다. IPIfNonMatch는 도메인 단계에서 일치하는 규칙이 없을 때 도메인을 확인한 뒤 IP 규칙을 추가로 확인할 수 있습니다. IPOnDemand는 IP 정보가 필요한 규칙을 만나면 도메인을 확인할 수 있습니다. 이 설정은 라우팅 판단 과정에 영향을 주며 DNS 서버 목록과는 다릅니다. 아웃바운드 연결 대상에 필요한 도메인 확인을 대신하지도 않습니다. 정책을 바꾸면 DNS 요청 수와 규칙 적용 결과가 달라질 수 있습니다.

애플리케이션이 IP 주소만 코어에 전달하면 도메인 규칙을 추가해도 원래 이름이 되살아나지는 않습니다. 애플리케이션의 프록시 방식, DNS 조회가 이뤄지는 위치, 적용 가능한 스니핑 기능 사용 여부를 확인하세요. 반대로 대상이 이미 도메인이라고 해서 사설 IP 규칙이 반드시 먼저 적용되는 것도 아닙니다. 도메인을 조회할지, 언제 조회할지는 현재 정책에 따라 달라집니다. 문제를 확인할 때는 브라우저 주소창만 보는 것보다 ‘인바운드가 도메인과 IP 중 무엇을 받았는지’를 기록하는 편이 유용합니다.

geosite와 geoip는 분류 데이터 참조이며 실시간 네트워크 조회 기능이 아닙니다. 코어가 해당 데이터 파일을 찾을 수 있어야 하고 분류 이름도 실제로 존재해야 합니다. 데이터가 없으면 시작에 실패할 수 있으며, 분류 내용이 바뀌면 설정을 그대로 둬도 업데이트 후 결과가 달라질 수 있습니다. 먼저 명확한 도메인 하나나 네트워크 대역 하나로 규칙을 확인한 다음 분류 참조를 사용하면 규칙 문법 문제와 분류 데이터 문제를 구분할 수 있습니다.

규칙을 관리할 때는 각 규칙의 용도와 수정 이유를 설정 파일 바깥에 기록하는 것이 좋습니다. 표준 JSON 안에 주석을 넣지 마세요. 기존 규칙을 삭제하기 전에 뒤에 있는 규칙이 순서에 의존하는지 확인하고, 특히 인바운드 태그 기반 분기와 최종 대체 규칙을 살펴보세요. 매칭 문법과 우선순위 예제는 사용자 지정 라우팅 규칙 노트에서 확인할 수 있습니다. 시스템 프록시와 전체 모드의 차이는 FAQ와 함께 살펴보세요.

05 / DNS

dns: DNS 조회 지점과 요청 경로

먼저 어느 계층에서 DNS를 조회하는지 확인

한 번의 접속에 애플리케이션 자체의 DNS 조회, 운영체제 DNS 조회, 코어 내장 DNS, 원격 프록시 측 DNS 조회가 포함될 수 있습니다. 설정의 dns는 코어 관련 조회 동작만 정의하며 기기의 모든 애플리케이션 DNS 설정을 자동으로 바꾸지는 않습니다. 브라우저가 자체 암호화 DNS를 사용할 수도 있고, 애플리케이션이 IP를 먼저 알아낸 뒤 프록시 요청을 보낼 수도 있습니다. 따라서 DNS가 적용됐는지 판단하려면 먼저 어떤 구성 요소가 조회를 수행하는지 확인해야 합니다. 시스템 설정 화면에 표시된 서버 주소만 봐서는 알 수 없습니다.

코어 DNS 사용 여부는 라우팅 정책, 아웃바운드 설정, 클라이언트의 설정 생성 방식에도 영향을 받습니다. 일부 요청은 도메인을 원격으로 전달하고, 다른 요청은 IP 라우팅 규칙에 맞추기 위해 로컬에서 조회할 수 있습니다. 두 동작이 함께 일어날 수도 있습니다. 웹 페이지가 열리는데 로그에 해당 조회가 보이지 않는다고 해서 설정이 반드시 무효인 것은 아닙니다. 인바운드가 도메인과 IP 중 무엇을 받았는지, 요청이 어느 아웃바운드에서 처리됐는지 확인한 뒤 예상한 DNS 조회가 어디서 일어나야 하는지 판단하세요.

servers, hosts, DNS 조회 주소 계열

servers는 DNS 서버를 지정합니다. 간단한 주소를 사용할 수도 있고, 코어 지원 여부에 따라 도메인 조건을 포함한 객체를 사용할 수도 있습니다. hosts는 이름을 명시적으로 매핑하며, 통제된 테스트나 고정된 내부 이름에 적합합니다. 아래 예제는 숫자 형식의 DNS 서버 주소를 사용하고, 예제용 예약 도메인을 문서용 주소에 연결합니다. 이 매핑은 설명을 위한 것으로 실제 접속 가능한 사이트가 아닙니다. 숫자 주소를 사용하면 시작 단계에서 DNS 서버 도메인을 먼저 조회해야 하는 의존성을 줄일 수 있습니다.

{
  "dns": {
    "hosts": {
      "lab.example.com": "192.0.2.10"
    },
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIP"
  }
}

UseIP는 IPv4와 IPv6 결과를 모두 조회할 수 있다는 뜻입니다. 다른 조회 정책의 지원 값은 사용하는 코어에 맞춰야 합니다. 일부 듀얼 스택 문제를 좁히기 위해 IPv4만 반환하도록 할 수 있지만, 이를 모든 환경에서 영구적으로 적용할 최적화로 봐서는 안 됩니다. IPv6가 필요한 네트워크에서는 오히려 사용 가능한 경로를 잃을 수 있습니다. 시스템에 IPv6 주소가 있더라도 네트워크에서 안정적인 종단 간 IPv6 연결이 된다는 뜻은 아니므로 주소 설정과 실제 연결 가능성을 따로 확인하세요.

DNS 서버 목록과 연결 아웃바운드 목록은 다릅니다

서버를 여러 개 나열해도 항상 순서대로 하나씩 대체 사용한다는 뜻은 아닙니다. 도메인 조건, 캐시, 폴백 방식, 코어 구현에 따라 실제 조회 결과가 달라질 수 있습니다. 도메인별로 다른 DNS를 사용하려면 어떤 이름을 어느 리졸버에 전달할지, 일치하지 않는 이름은 어떻게 처리할지 명확히 정하세요. 객체 형식의 도메인 조건은 라우팅 규칙과 비슷해 보이지만 적용 위치가 다릅니다. 앞의 설정은 DNS 서버를 선택하고, 라우팅 규칙은 연결 아웃바운드를 선택하므로 같은 규칙처럼 취급하면 안 됩니다.

암호화 DNS는 DNS 서비스까지의 전송을 보호할 수 있지만, 이 연결이 예상한 아웃바운드를 거친다는 보장은 없습니다. 현재 코어에서 해당 조회 방식이 어떤 경로로 전송되는지, 클라이언트가 별도의 DNS 라우팅을 설정했는지도 확인해야 합니다. DNS 서비스 주소가 도메인이고 서버에 접속하려면 먼저 해당 도메인을 조회해야 한다면 시작 의존성 루프가 생길 수 있습니다. 확인할 때는 먼저 명확하게 도달 가능한 숫자 주소로 기본 DNS 조회를 구성하고, 이후 목표 설정으로 단계적으로 바꾸세요.

캐시는 DNS 문제를 확인할 때 중요한 변수입니다. 클라이언트를 다시 불러오면 코어 캐시만 지워지고 브라우저나 운영체제에는 이전 기록이 남을 수 있습니다. 기존 연결은 조회 결과가 바뀌어도 자동으로 다시 연결되지 않습니다. 설정을 검증할 때는 새 연결을 사용하고, 필요한 경우 관련 애플리케이션을 종료한 뒤 다시 실행하세요. 테스트 시간과 조회 이름도 기록하세요. 페이지를 계속 빠르게 새로고침해 여러 계층의 캐시 결과를 뒤섞은 뒤 특정 서버가 적용되지 않는다고 판단하지 마세요.

DNS 시간 초과는 라우팅 루프 때문에 발생할 수도 있습니다. 예를 들어 DNS 요청이 서버 도메인을 먼저 조회해야 연결할 수 있는 프록시 아웃바운드로 전송되거나, 가상 네트워크 인터페이스가 코어 자체 트래픽을 다시 받아들일 수 있습니다. 이런 경우 공용 DNS 서버를 계속 추가해도 해결되지 않는 경우가 많습니다. 연결 간 의존성으로 돌아가 DNS 서비스 주소, 프록시 서버 주소, 코어 자체 연결의 경로를 각각 확인하세요. 각 단계의 선행 조건이 독립적으로 충족되어야 복잡한 도메인별 DNS 설정도 안정적으로 작동합니다.

v2rayN이나 v2rayNG에서 DNS를 조정할 때는 먼저 클라이언트에 있는 설정 메뉴를 사용하고, 최종 생성된 설정을 확인해 인터페이스 설정과 사용자 지정 조각이 서로 덮어쓰지 않는지 살펴보세요. 첫 연결이 목적이라면 변수를 최소화하는 편이 좋습니다. 특정 라우팅 동작을 확인하려면 테스트 도메인 하나를 정해 DNS 조회와 접속 단계를 따로 관찰하세요. 시스템 프록시 적용 범위나 애플리케이션별 DNS 조회에 대한 질문은 자주 묻는 질문에서 확인할 수 있습니다.

06 / POLICY

policy: 시간 초과, 사용자 레벨, 통계

policy는 노드 우선순위가 아닙니다

policy는 연결 리소스와 통계 관련 정책을 설정합니다. 주로 핸드셰이크 대기 시간, 유휴 시간 초과, 한쪽 연결 종료 후 유지 시간, 트래픽 통계 옵션이 포함됩니다. 노드 이름을 기준으로 아웃바운드를 선택하거나 라우팅 규칙을 대신하지 않습니다. 연결이 불안정하다면 먼저 아웃바운드 연결이 가능한지 확인한 뒤 시간 초과 정책이 실제 원인인지 살펴보세요. 모든 시간을 늘리면 원래 빨리 드러나야 할 오류까지 더 오래 기다리게 될 수 있습니다.

levels의 숫자 키는 사용자 레벨을 나타내며, JSON 객체의 키는 따옴표로 묶어야 합니다. 레벨은 시스템 권한이 아니며 숫자가 클수록 속도가 빠르다는 의미도 아닙니다. 프로토콜 사용자 설정의 level은 해당 레벨과 연결되고, 명시하지 않으면 기본 레벨이 사용되는 경우가 많습니다. 사용자 인증이 없는 로컬 인바운드를 주로 사용하는 환경에서는 여러 사용자 레벨을 설정하지 않을 수 있습니다. 이런 경우 높은 번호의 정책을 많이 정의해도 기대한 변화가 생기지 않습니다.

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5,
        "statsUserUplink": false,
        "statsUserDownlink": false
      }
    },
    "system": {
      "statsInboundUplink": false,
      "statsInboundDownlink": false
    }
  }
}

연결 단계별 시간 초과 이해

예제의 시간 필드는 보통 초 단위이며, 실제 사용 시에는 현재 코어의 필드 설명을 확인해야 합니다. handshake는 핸드셰이크 단계에서 허용할 대기 시간을 제한하고, connIdle은 데이터 활동이 없는 연결을 유지할 시간을 정합니다. uplinkOnly와 downlinkOnly는 한쪽이 연결을 닫은 후 다른 방향을 유지할 시간과 관련이 있습니다. 각 필드는 서로 다른 단계를 설명하므로 연결이 끊기는 모든 현상을 하나의 필드로 설명할 수는 없습니다.

핸드셰이크 시간이 너무 짧으면 지연이 크거나 일시적으로 혼잡할 때 연결이 완료되기 전에 종료될 수 있습니다. 너무 길면 실패 여부를 늦게 알게 됩니다. 유휴 시간 초과가 너무 짧으면 알림은 기다리지만 데이터 전송은 드문 애플리케이션에 문제가 생길 수 있고, 너무 길면 연결 리소스를 더 오래 점유합니다. 조정할 때는 재현 절차가 명확한 애플리케이션을 선택하고, 연결이 끊기기 전에 실제로 데이터가 없었는지 기록한 뒤 관련 필드를 조금씩 바꿔 보세요. 데이터가 계속 흐르던 전송 문제를 유휴 시간 초과 탓으로 돌리지 마세요.

네트워크 연결에서 한쪽 방향만 종료되는 일은 드물지 않습니다. 한쪽이 전송을 멈췄다고 해서 반대쪽이 응답을 끝냈다는 뜻은 아니므로, 한쪽 연결의 유지 시간은 일부 요청의 마무리 과정에 영향을 줍니다. 로그와 애플리케이션 동작이 실제로 반쯤 종료된 연결을 가리킬 때만 관련 매개변수를 조정하세요. 인증에 실패했거나 서버가 세션을 종료한 경우에는 클라이언트 시간 필드를 바꿔도 프로토콜 불일치가 해결되지 않으며 원격 서버가 연결을 유지하도록 강제할 수도 없습니다.

통계를 사용하려면 전체 수집 경로를 구성해야 합니다

사용자 업로드나 다운로드 통계를 켠다고 클라이언트에 값이 바로 표시되는 것은 아닙니다. 통계 모듈, 관련 사용자 식별자, API 서비스, 클라이언트의 조회 기능이 모두 연결되어야 합니다. 화면의 트래픽 수치가 가상 네트워크 인터페이스나 다른 통계 출처에서 표시될 수도 있습니다. 숫자가 보인다는 이유만으로 특정 policy 필드가 적용됐다고 단정하지 마세요. 이 예제는 별도의 인터페이스와 수집 설정을 추가하지 않도록 통계를 끄고 필드 위치만 보여줍니다.

시스템 수준 통계와 사용자 수준 통계는 집계 단위가 다릅니다. 인바운드 통계는 하나의 인바운드에서 처리된 여러 요청을 합산할 수 있지만, 사용자 통계는 프로토콜에서 식별 가능한 사용자 객체에 의존합니다. 애플리케이션별 트래픽을 확인하려면 사용자 통계만으로 충분하지 않을 수 있습니다. 인바운드 구분, 애플리케이션 연결 방식, 클라이언트의 관련 표시 기능도 확인해야 합니다. 화면 지표 하나를 얻으려고 제어 인터페이스를 로컬 네트워크에 공개하지 마세요. 실제 사용 범위에 맞춰 인터페이스 리스닝 범위를 제한해야 합니다.

통계나 다른 고급 모듈을 켠 뒤 시작에 실패하면 먼저 필요한 모듈이 있는지, 현재 코어가 해당 필드를 지원하는지, 클라이언트가 같은 이름의 설정을 이미 생성했는지 확인하세요. 서로 독립적인 API 설정 두 개를 함께 유지한 채 포트만 바꿔 모든 오류를 해결하려 하지 마세요. 연결 정책만 포함된 최소 설정으로 되돌린 뒤 통계 기능을 하나씩 추가하면 연결 처리 문제와 모니터링 기능 문제를 분리할 수 있습니다.

정책 변경을 평가할 때 한 번의 지연 시간 측정만 보지 마세요. 짧은 요청, 장시간 연결, 지속적인 데이터 전송은 영향을 받는 단계가 다르므로 한 가지 테스트로 모든 동작을 확인할 수 없습니다. 첫 연결이 완료되는지, 유휴 상태 이후 복구되는지, 진행 중인 작업이 갑자기 끊기는지 각각 확인하고 테스트가 끝나면 로그 수준을 기본값으로 되돌리세요. 특정 값이 어떤 문제를 해결하는지 설명할 수 없다면 계속 유지할 필요가 없습니다. 설정이 간결할수록 다른 코어로 옮길 때 호환성을 확인하기 쉽습니다.

07 / CLIENT INTEGRATION

클라이언트 설정 생성과 적용 범위

인터페이스 옵션이 실행 설정으로 바뀌는 과정

v2rayN, v2rayNG, v2flyNG는 그래픽 인터페이스와 코어의 연결 처리를 분리합니다. 클라이언트는 노드, 구독, 사용자 설정을 저장하고 현재 선택을 코어 실행에 필요한 설정으로 변환합니다. 덕분에 필드를 직접 작성하는 부담은 줄지만, 생성된 파일이 장기적으로 설정의 원본이 아닐 수 있습니다. 노드 전환, 코어 재시작, 라우팅 모드 변경, 구독 업데이트에 따라 설정이 다시 생성될 수 있습니다. 실행 파일을 직접 수정해도 다음 작업에서 덮어써질 수 있습니다.

데스크톱에서는 v2rayN을 우선 사용하고, 실제 코어와 시스템 환경에 맞춰 그래픽 기능을 선택하세요. Android에서는 Xray 코어를 사용하는 v2rayNG를 사용할 수 있으며, V2Fly 코어 대안으로 v2flyNG를 고려할 수 있습니다. 사용자 지정 설정을 연결하는 방식은 클라이언트마다 다를 수 있고 메뉴 이름도 바뀔 수 있으므로 현재 설치된 앱의 인터페이스를 기준으로 확인하세요. 옵션이 보이지 않는다면 다른 클라이언트의 전체 절차를 그대로 적용하지 말고, 현재 앱과 사용 중인 코어부터 확인하세요.

구독, 노드, 전체 설정 구분하기

구독 주소는 보통 업데이트할 수 있는 여러 노드 정보를 가리킵니다. 노드 공유 링크는 단일 서버의 프로토콜과 연결 매개변수를 설명하고, 전체 JSON에는 인바운드, 아웃바운드, DNS, 라우팅이 함께 포함될 수 있습니다. 이 세 가지는 같은 유형의 텍스트가 아니므로 서로 바꿔 가져올 수 없습니다. 노드 링크만 받는 가져오기 메뉴에 전체 설정을 붙여 넣거나 구독 주소를 아웃바운드 서버 주소로 입력하면 올바르게 작동하지 않습니다. 가져오기 전에 내용의 용도를 구분하면 실패 후 다른 버튼을 계속 눌러 보는 것보다 효과적입니다.

일부 클라이언트는 전체 설정 가져오기를 지원하고, 일부는 부분 사용자 설정이나 라우팅 규칙 관리만 지원합니다. 사용하기 전에 전체 설정을 교체하는지, 특정 객체를 병합하는지, 배열 항목만 추가하는지 확인하세요. 병합 방식에 따라 같은 조각도 결과가 달라질 수 있습니다. 아웃바운드 배열을 교체하면 기존 출구가 사라지고, 라우팅 규칙을 추가해도 앞선 규칙에 가려질 수 있습니다. 파일이 저장됐는지만 확인하지 말고 최종 생성 결과에 원하는 태그와 순서가 포함되어 있는지 살펴보세요.

시스템 프록시와 TUN은 서로 다른 연결 방식

시스템 프록시는 운영체제가 해당 설정을 따르는 애플리케이션에 프록시 정보를 제공합니다. 모든 프로그램의 트래픽을 자동으로 처리하지는 않습니다. TUN은 가상 네트워크 인터페이스와 관련 라우팅을 통해 트래픽을 클라이언트에 전달합니다. 둘 다 같은 코어를 사용할 수 있지만 동일한 JSON 옵션은 아닙니다. TUN에 필요한 권한, 가상 인터페이스, 시스템 라우팅은 대개 클라이언트가 관리합니다. 기존 인바운드 배열에 알 수 없는 프로토콜 이름을 추가하는 것만으로 시스템 전체 트래픽을 처리할 수 있다고 생각해서는 안 됩니다.

네트워크 프록시 도구를 여러 개 실행하는 경우 시스템 프록시 주소를 누가 바꾸는지, 기본 경로를 누가 관리하는지, DNS 설정을 누가 유지하는지 살펴보세요. 클라이언트 하나를 종료해도 다른 클라이언트가 포트를 계속 사용하거나 시스템 설정을 남겨둘 수 있습니다. 소프트웨어를 종료한 뒤 애플리케이션이 오히려 인터넷에 연결되지 않는다면 모든 소프트웨어를 바로 재설치하지 말고, 시스템 프록시가 중지된 로컬 엔드포인트를 가리키는지 먼저 확인한 다음 가상 네트워크 인터페이스와 시스템 라우팅을 점검하세요.

작은 변경으로 설정 출처 확인하기

사용자 지정 설정이 적용되는지 확인하려면 서비스 정보를 노출하지 않으면서 쉽게 관찰할 수 있는 항목을 바꿔 보세요. 예를 들어 로컬 인바운드 포트를 변경하고 테스트 애플리케이션의 설정도 함께 수정하거나, 기존 아웃바운드에 명확한 내부 태그를 붙일 수 있습니다. 관련 연결을 다시 시작한 뒤 리스닝 상태와 로그를 확인하세요. 최종 생성 설정이 바뀌지 않았다면 문제는 클라이언트의 설정 출처나 병합 방식에 있으므로 원격 네트워크를 계속 의심할 필요가 없습니다. 생성 결과가 올바르면 연결 단계의 문제를 확인하세요.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["http-in"],
        "outboundTag": "direct"
      }
    ]
  }
}

위의 부분 설정은 인바운드 태그를 기준으로 트래픽을 분기하는 방법만 보여줍니다. http-in이라는 인바운드와 direct 아웃바운드가 함께 있어야 합니다. 이 조각이 해당 객체를 만들지는 않으며, 기존 라우팅을 확인하지 않고 덮어쓰는 용도로 사용해서도 안 됩니다. 사용자 지정 설정을 관리할 때는 수정 목적, 적용할 코어, 의존하는 태그를 따로 기록하되 구독 주소나 비밀번호는 공개 메모에 적지 마세요. 기기를 바꾸기 전에 필요한 설정을 내보내고, 민감한 정보가 어떻게 저장되는지 클라이언트별로 확인하세요.

처음 사용하는 경우에는 사용 가이드에 따라 가져오기, 노드 선택, 연결 확인을 마친 다음 전체 설정 적용을 고려하는 것이 좋습니다. v2rayN의 설정 메뉴와 로그 영역을 살펴보려면 메인 화면 기능 안내를 참고하세요. 이 페이지는 필드와 적용 범위를 설명합니다. 클라이언트의 실제 버튼은 현재 화면을 기준으로 확인하고, 예제와 똑같이 만들기 위해 안정적으로 작동하는 기본 설정을 바꿀 필요는 없습니다.

08 / DIAGNOSTICS

로그 확인과 설정 복구 순서

먼저 프로세스가 정상적으로 시작되는지 확인

설정 문제를 확인할 때 첫 번째 기준은 코어가 계속 실행되는지 여부입니다. 시작 직후 종료된다면 웹 페이지를 테스트하지 말고 가장 먼저 발생한 오류를 확인하세요. JSON 구조 오류, 미지원 프로토콜이나 필드, 중복 리스닝, 필요한 데이터 파일 누락 등이 흔한 원인입니다. 이후에 연달아 표시되는 ‘연결 거부’는 코어가 종료된 결과일 수 있습니다. 애플리케이션의 후속 오류만 해결해서는 최초의 시작 오류를 고칠 수 없습니다.

로그에 파일 경로가 표시되면 현재 실행 중인 인스턴스의 경로인지 확인하세요. 클라이언트가 여러 개이거나 종료되지 않은 프로세스가 있으면 각각 다른 로그를 남길 수 있으며, 이전 창의 내용이 최근 테스트와 무관할 수도 있습니다. 재시작 시간을 기록하고 현재 인스턴스의 관련 로그만 확인한 뒤 설정 경로와 실제로 수정한 파일이 같은지 살펴보세요. 클라이언트에 시작 오류 세부 정보가 있으면 먼저 모듈 이름을 확인한 다음 파일에서 해당 부분을 찾으세요. 비슷해 보이는 필드를 먼저 일괄 교체하지 마세요.

로그 상세 수준을 임시로 높이기

연결 과정을 확인하려면 코어의 지원 여부를 확인한 뒤 로그 수준을 임시로 info로 설정할 수 있습니다. 더 상세한 디버그 수준은 문제 범위를 좁힌 뒤에만 사용하세요. 로그에는 대상 도메인, 연결 주소, 사용자 관련 정보가 포함될 수 있으므로 공유 전에 민감한 내용을 삭제해야 합니다. 로그가 많다고 문제를 더 쉽게 찾을 수 있는 것은 아닙니다. 특히 여러 애플리케이션이 동시에 연결되면 정상 요청에 실패 요청이 묻힐 수 있습니다. 테스트 중에는 애플리케이션 하나와 명확한 대상 하나만 사용하는 편이 좋습니다.

{
  "log": {
    "loglevel": "info"
  }
}

이 설정은 최상위 로그 모듈만 교체하는 예제이며, 단독으로 사용할 수 있는 전체 설정이 아닙니다. 변경 후에도 로그 상세 수준이 달라지지 않는다면 코어를 다시 시작해야 하는지, 클라이언트가 로그 옵션을 덮어쓰는지 확인하세요. 문제를 확인한 뒤에는 일반 로그 수준으로 되돌려 불필요한 접속 정보가 계속 기록되지 않도록 하세요. 로그를 파일에 저장한다면 디렉터리가 존재하는지, 현재 프로세스에 쓰기 권한이 있는지도 확인해야 합니다. 로그 파일을 만들 수 없는 문제 역시 별도의 오류를 일으킬 수 있으므로 연결 문제와 혼동하지 마세요.

인바운드, DNS, 라우팅, 아웃바운드를 차례로 확인

코어가 정상적으로 실행되면 테스트 요청이 해당 인바운드에 들어오는지 확인하세요. 기록이 전혀 없다면 애플리케이션의 프록시 유형, 주소, 포트, 시스템 프록시 상태를 점검합니다. 요청은 들어왔지만 대상 정보가 틀리다면 애플리케이션의 DNS 조회 방식과 스니핑을 확인하세요. 대상은 맞지만 잘못된 아웃바운드로 전달된다면 규칙 순서, 태그, 도메인 정책을 점검합니다. 예상한 아웃바운드가 선택된 것을 확인한 뒤에 서버 DNS 조회, 연결, TLS, 프로토콜 인증을 살펴보세요. 다른 계층의 문제를 넘겨짚지 않도록 합니다.

‘시간 초과’는 어떤 단계가 허용된 시간 안에 완료되지 않았다는 뜻일 뿐, 근본 원인을 알려주지는 않습니다. 서버 도메인 조회 시간 초과, 대상 포트 연결 시간 초과, 프로토콜 협상 시간 초과에는 서로 다른 확인 방법이 필요합니다. 로그에 마지막 메시지만 남았다면 로그 수준을 적절히 높여 한 번 재현하고 더 앞선 단계의 정보를 찾으세요. 시간 초과가 보인다고 DNS, 전송 방식, 인증 정보를 모두 바꾸면 우연히 복구되더라도 어떤 변경이 효과가 있었는지 알 수 없습니다.

수정 결과를 확인할 때는 새 요청과 애플리케이션의 실제 기능을 함께 살펴보세요. 기존 장시간 연결은 이전 아웃바운드를 계속 사용할 수 있고, 브라우저 캐시 때문에 새 요청이 발생하지 않았는데도 페이지가 정상인 것처럼 보일 수 있습니다. 관련 연결을 닫은 뒤 다시 테스트하고 요청이 예상한 인바운드와 아웃바운드를 거치는지, 애플리케이션에 필요한 다른 요청도 성공하는지 확인하세요. 실제 연결을 통한 속도 테스트는 서비스 접근성을 확인하는 데 도움이 되지만, 한 번의 성공만으로 모든 도메인, 프로토콜, 애플리케이션에서 라우팅이 예상대로 작동한다고 볼 수는 없습니다.

복구 목표는 설명 가능한 상태를 되찾는 것

여러 곳을 수정해 문제 원인을 알기 어려워졌다면 가장 최근에 정상 시작된 설정으로 되돌리고, 인바운드 하나, 작동이 확인된 아웃바운드 하나, 최소한의 규칙만 남기세요. 그런 다음 DNS, 트래픽 분기, 정책, 고급 기능을 순서대로 복원하면서 매번 같은 대상을 테스트하세요. 기능을 영구적으로 줄이라는 뜻이 아니라 복잡한 문제를 관찰 가능한 단계로 나누기 위한 방법입니다. 추가한 항목마다 결과를 명확히 확인해야 이후 설정이 설명하기 어려운 예외로 쌓이지 않습니다.

시작 오류를 더 세부적으로 분류하려면 Xray 로그로 설정 오류 찾기를 참고하세요. 시작은 정상적으로 되지만 프록시가 적용됐는지 확실하지 않다면 첫 연결 확인 노트를 확인하세요. 그래도 궁금한 점이 있으면 FAQ에서 증상별로 찾아보세요. 설정 참고 자료의 목표는 파일을 계속 길게 만드는 것이 아니라 각 필드의 역할을 설명할 수 있게 하는 것입니다.