V2Ray 설정 파일 구조와 매개변수 설명

02 / INBOUNDS

inbounds 인바운드 설정

리스닝 주소가 연결 가능한 범위를 결정합니다

인바운드는 로컬 애플리케이션이 트래픽을 커널에 넘기는 입구입니다. 가장 흔한 로컬 입구는 SOCKS와 HTTP 프록시입니다. listen은 어느 네트워크 주소에서 리슨할지, port는 포트를, protocol은 애플리케이션이 사용할 프록시 프로토콜을 결정합니다. 현재 기기에서만 사용할 때는 리스닝 주소를 127.0.0.1로 설정하는 것이 좋습니다. 이 주소는 로컬 연결만 허용하므로 브라우저, 시스템 프록시와 같은 기기의 다른 프로그램은 사용할 수 있지만 로컬 네트워크의 다른 기기는 직접 접속할 수 없습니다.

같은 로컬 네트워크의 휴대폰, TV 또는 다른 컴퓨터에서 데스크톱 클라이언트를 사용하게 하려면 인바운드는 보통 0.0.0.0 또는 구체적인 로컬 네트워크 주소에서 리슨합니다. 이 경우 시스템 방화벽, 네트워크 유형과 접근 제어도 함께 설정해야 하며 리스닝 주소만 바꾸어서는 안 됩니다. 공유 기기에는 127.0.0.1이 아니라 커널이 실행 중인 컴퓨터의 로컬 네트워크 주소와 인바운드 포트를 입력해야 합니다. 자세한 내용은 v2rayN 로컬 네트워크 연결 허용 설정 가이드를 참고하세요.

{
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ]
      }
    },
    {
      "tag": "http-in",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

SOCKS, HTTP와 투명 프록시의 차이

SOCKS 인바운드는 SOCKS 프록시를 명시적으로 지원하는 애플리케이션에 적합하며 TCP를 전달하고 설정에 따라 UDP도 처리할 수 있습니다. HTTP 인바운드는 HTTP CONNECT 또는 일반 HTTP 프록시로 연결하는 프로그램에 주로 사용됩니다. 두 방식 모두 애플리케이션이나 시스템 프록시가 해당 포트를 정확히 가리켜야 합니다. 프로그램이 HTTP 프록시로 설정되어 있다면 SOCKS 포트를 가리킬 수 없습니다. 포트는 맞지만 프로토콜 유형이 틀리면 연결이 즉시 끊기거나 브라우저에 프록시 응답 오류가 표시되고, 로그에 인식할 수 없는 핸드셰이크 데이터가 남는 경우가 많습니다.

TUN 모드는 일반 로컬 프록시와 다릅니다. 가상 네트워크 인터페이스로 더 넓은 범위의 시스템 트래픽을 수신하며, 클라이언트에서 라우팅 테이블, DNS 가로채기와 권한도 설정해야 합니다. TUN 설정을 SOCKS 인바운드를 하나 더 추가하는 것으로 이해해서는 안 됩니다. v2rayN은 인터페이스의 TUN 옵션에 따라 실행 매개변수를 구성하므로, 보통 클라이언트 화면에서 먼저 활성화한 뒤 로그를 확인해야 합니다. 다른 환경의 완전한 TUN 조각을 현재 설정에 그대로 붙여 넣지 마세요. 일반 시스템 프록시만으로 브라우저와 일반 데스크톱 프로그램을 사용할 수 있다면 ‘더 많이 적용’하려고 여러 가로채기 방식을 동시에 켤 필요도 없습니다.

sniffing이 도메인 라우팅을 돕는 방식

sniffing은 연결에 포함된 프로토콜 특징에서 대상 도메인을 복원하는 기능입니다. 일부 애플리케이션은 먼저 직접 도메인을 조회한 뒤 IP 주소를 프록시에 전달합니다. 이때 routing에 도메인 규칙만 있다면 커널이 순수 IP만 보게 되어 도메인 매칭을 할 수 없습니다. 스니핑을 활성화하면 HTTP 요청의 호스트 정보나 TLS 핸드셰이크의 서버 이름이 라우팅 모듈의 도메인 식별을 도울 수 있습니다. 예제의 destOverride는 식별된 HTTP 또는 TLS 대상을 사용해 원래 목적지 주소를 덮어쓸 수 있게 하며, 이후 규칙에서 이를 판단할 수 있도록 합니다.

스니핑은 DNS를 대신하지 않으며 모든 연결에서 도메인을 복원할 수 있는 것도 아닙니다. 식별 가능한 호스트 정보가 없는 프로토콜은 여전히 IP로만 표시됩니다. 암호화 핸드셰이크 방식과 애플리케이션 동작도 결과에 영향을 줍니다. 라우팅이 매칭되지 않을 때는 먼저 액세스 로그에 도메인과 IP 중 무엇이 기록되는지 확인한 뒤 domainStrategy 조정, IP 규칙 추가 또는 스니핑 설정 점검 여부를 결정하세요. 로그를 확인하지 않은 채 같은 도메인과 IP 조건을 반복해서 쌓으면 규칙만 관리하기 어려워집니다.

포트, 인증과 태그 설정 원칙

같은 주소의 포트는 두 프로세스가 동시에 사용할 수 없으며, 두 인바운드가 같은 주소와 포트에서 리슨할 수도 없습니다. 클라이언트 시작 직후 주소가 이미 사용 중이라는 메시지가 나오면 중복 실행된 인스턴스를 종료한 뒤 다른 프록시 도구나 이전 커널 프로세스를 확인하세요. 포트만 임의로 바꾸는 것은 충돌의 절반만 해결합니다. 시스템 프록시, 브라우저 확장 프로그램과 로컬 네트워크 기기의 포트도 함께 바꿔야 합니다. 혼동을 줄이려면 SOCKS와 HTTP 포트를 서로 가까운 번호로 정할 수 있지만, 특정 숫자만 보고 프로토콜 유형을 판단해서는 안 됩니다.

auth: "noauth"는 루프백 주소에서만 리슨하는 로컬 SOCKS 인바운드에 적합합니다. 로컬 네트워크 주소에서 리슨할 때는 클라이언트 지원 여부를 고려해 인증과 방화벽 제한을 함께 검토하고 신뢰할 수 있는 네트워크만 접근하도록 하세요. 태그는 각 인바운드에 고유한 이름을 붙여야 이후 inboundTag로 입구마다 다른 라우팅을 설정할 수 있습니다. 예를 들어 로컬 트래픽은 일반 분기 처리를 하고, 로컬 네트워크 공유 입구는 일부 포트만 허용할 수 있습니다. 태그를 바꾼 뒤에는 routing의 참조를 전체 검색해 이전 이름이 남아 있지 않은지 확인하세요.

04 / ROUTING

routing 라우팅 규칙

규칙은 위에서 아래로 매칭되며 첫 번째 결과가 적용됩니다

라우팅 모듈은 연결의 대상 도메인, IP, 포트, 네트워크 유형, 프로토콜 특징 또는 인바운드 태그에 따라 아웃바운드를 선택합니다. 가장 중요한 점은 규칙 순서입니다. 규칙은 보통 위에서 아래로 검사되며 하나가 매칭되면 해당 규칙의 outboundTag를 사용하고 이후 규칙은 더 이상 적용하지 않습니다. 따라서 더 구체적인 규칙을 위에, 더 포괄적인 규칙을 아래에 배치해야 합니다. ‘모든 TCP 트래픽을 프록시로 보낸다’를 첫 규칙에 두면 뒤의 직접 연결 도메인 규칙은 적용될 기회가 없습니다.

규칙을 설계할 때는 먼저 기본 정책을 정한 다음 예외를 나열하세요. 기본 출구가 프록시라면 차단 조건과 명시적인 직접 연결 조건을 먼저 두고 나머지는 기본 프록시로 보내면 됩니다. 기본 출구가 직접 연결이라면 프록시가 필요한 대상을 먼저 나열하세요. 아웃바운드 배열 순서, 복잡한 도메인 목록과 여러 폴백 규칙에 같은 의미를 동시에 맡기지 마세요. 명확한 기본 동작 하나를 선택하고 규칙은 예외만 설명해야 이후 유지 관리가 쉽습니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "protocol": [
          "bittorrent"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:intranet.example.com",
          "full:printer.example.net"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

도메인 매칭 방식이 규칙의 범위를 결정합니다

도메인 조건에는 전체 일치, 도메인과 하위 도메인 일치, 키워드 일치, 사전 정의된 도메인 집합 등이 흔히 사용됩니다. full:printer.example.net은 정확한 호스트 이름만 매칭하므로 범위가 분명한 단일 서비스에 적합합니다. domain:example.com은 일반적으로 해당 도메인과 하위 도메인을 포함하므로 관련 호스트 그룹에 적합합니다. 접두사가 없는 문자열은 문맥에 따라 다르게 해석될 수 있으므로, 유지 관리 시에는 매칭 유형을 명시해 나중에 의도를 잊지 않도록 하세요.

키워드 매칭은 범위가 넓어 짧은 문자열 하나가 관계없는 도메인에 우연히 매칭될 수 있습니다. 이름의 일부를 기준으로 분류해야 하는 경우가 아니라면 full 또는 domain을 우선 사용하세요. 규칙이 매칭되지 않을 때는 먼저 커널이 본 대상이 도메인인지 확인합니다. 애플리케이션이 대상을 이미 IP로 변환했고 인바운드 스니핑이 도메인을 복원하지 못했다면 아무리 정확한 도메인 규칙도 적용되지 않습니다. 이때 액세스 로그 확인, 적절한 sniffing 활성화 또는 알려진 주소 범위에 IP 조건 추가를 검토하세요.

domainStrategy는 도메인 규칙과 IP 규칙을 연결합니다

domainStrategy는 IP 규칙과 매칭하기 위해 어떤 경우에 도메인을 조회할지 제어합니다. AsIs는 수신된 대상 형식 그대로 판단하는 데 중점을 두며, 라우팅 매칭만을 위해 도메인을 IP로 적극 변환하지 않습니다. IPIfNonMatch는 일반적으로 도메인 규칙이 매칭되지 않은 뒤 주소를 조회하고 IP 규칙을 시도한다는 뜻입니다. 다른 전략은 더 적극적으로 조회할 수 있습니다. 전략이 적극적일수록 도메인 트래픽이 IP 분류에 참여할 가능성이 커지지만 DNS 동작과 라우팅 결과의 결합도도 높아집니다.

전략을 선택할 때는 먼저 현재 규칙이 도메인 중심인지 IP 중심인지 확인하세요. 대부분의 규칙이 명확한 도메인이고 일부 네트워크 대역만 추가로 판단해야 한다면 IPIfNonMatch가 이해하기 쉽습니다. 모든 도메인을 먼저 주소 기준으로 분류하려면 DNS 설정과 예상 출구가 일치해야 합니다. 그렇지 않으면 조회 서버, 캐시 또는 주소 체계에 따라 같은 도메인도 다른 결과를 얻어 라우팅이 달라질 수 있습니다. domainStrategy를 바꾼 뒤에는 도메인 규칙, IP 규칙과 미매칭 대상 세 가지를 모두 테스트하세요.

IP, 포트, 네트워크와 인바운드 태그를 조합할 수 있습니다

IP 조건에는 단일 주소, CIDR 네트워크 대역 또는 커널이 지원하는 사전 정의 집합을 사용할 수 있습니다. 사설 주소는 보통 직접 연결해야 라우터, 프린터 또는 로컬 네트워크 서비스 접속이 원격으로 전달되지 않습니다. 포트 조건은 53 또는 80,443처럼 범위가 명확한 서비스에 적합하며 범위로 표현할 수도 있습니다. 네트워크 조건에는 tcp, udp 또는 두 유형의 조합을 흔히 사용합니다. 서로 다른 필드를 한 규칙에 넣으면 일반적으로 모두 충족해야 하며, 같은 필드의 배열에 여러 값을 넣으면 그중 하나만 매칭되어도 됩니다.

inboundTag는 출처를 구분할 때 유용합니다. 예를 들어 socks-in은 일반 분기 처리를 하고 lan-in은 지정된 출구만 사용하게 할 수 있습니다. 출처마다 커널 인스턴스를 여러 개 실행할 필요가 없습니다. 설정할 때는 인바운드 태그가 실제로 존재하는지 먼저 확인하고, 출처 제한을 규칙 앞부분에 배치해 더 넓은 대상 규칙에 먼저 매칭되지 않도록 하세요. 포트와 프로토콜 차단도 보수적으로 설정해야 합니다. 범위가 너무 넓으면 일부 애플리케이션은 첫 화면만 열리고 재생, 로그인 또는 동기화가 되지 않을 수 있습니다.

추측하지 말고 로그로 규칙을 검증하세요

라우팅을 검증하는 가장 효과적인 방법은 목적이 분명한 테스트 항목을 준비하는 것입니다. 직접 연결되어야 하는 내부 도메인 하나, 프록시로 가야 하는 대상 하나, 차단되어야 하는 조건 하나를 준비한 뒤 액세스 로그의 아웃바운드 태그를 확인하세요. 로그에 대상만 표시되고 예상 태그가 보이지 않는다면 일시적으로 로그 상세 수준을 높이고, 테스트가 끝난 뒤 낮춰 로그가 계속 증가하지 않게 합니다. 규칙을 수정한 후에는 커널을 다시 시작하거나 다시 로드하고, 클라이언트가 이전 실행 설정을 계속 사용하지 않는지도 확인하세요.

규칙이 많아지면 각 규칙 그룹에 대해 설정 외부에 유지 관리 메모를 작성하고 ‘왜 필요한가’를 기록하는 것이 도메인 목록만 남기는 것보다 유용합니다. 표준 JSON에는 주석을 쓸 수 있으므로 별도 문서에 설명을 보관하세요. 구독 업데이트는 일반적으로 노드와 프록시 아웃바운드에 영향을 주며 수동 라우팅까지 함께 덮어쓰면 안 됩니다. 업데이트할 때마다 규칙이 사라진다면 임시 생성 파일을 편집하고 있다는 뜻일 수 있으므로 클라이언트가 제공하는 라우팅 설정 경로를 사용하세요.

06 / POLICY

policy 정책과 통계

policy는 실행 동작을 제어하며 분기 방향을 결정하지 않습니다

policy를 routing의 보완 기능으로 오해하기 쉽지만, 실제로는 연결 세션의 타임아웃, 유휴 판정과 통계 스위치를 주로 제어합니다. 트래픽이 프록시로 갈지 직접 연결될지는 여전히 routing과 아웃바운드가 결정합니다. 정책은 보통 사용자 레벨별로 구성하며, 아웃바운드 사용자 객체의 level로 해당 레벨을 연결할 수 있습니다. 별도 설정이 없으면 대부분 기본 레벨을 사용합니다. 세션 동작을 다르게 해야 할 때만 여러 레벨을 추가하세요.

타임아웃 매개변수는 짧을수록 좋은 것이 아닙니다. 짧은 시간 동안 데이터가 전송되지 않았다고 연결이 끊긴 것은 아닙니다. 롱 폴링, 간헐적인 파일 전송, 원격 터미널과 연결을 유지하는 애플리케이션은 유휴 구간이 발생할 수 있습니다. 유휴 시간을 너무 짧게 설정하면 애플리케이션이 자주 재연결하고, 너무 길게 설정하면 끊어진 연결이 늦게 정리됩니다. 클라이언트나 커널의 기본 동작에서 시작해 로그와 애플리케이션 증상으로 필요성이 확인될 때만 조정하세요.

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

handshake와 connIdle은 서로 다른 단계를 처리합니다

handshake는 연결 수립 단계에서 기다릴 수 있는 시간을 제한합니다. 아직 핸드셰이크가 완료되지 않은 연결에 적용되며 웹페이지 전체 로딩 시간 제한과는 다릅니다. 너무 짧으면 네트워크가 불안정하거나 원격 응답이 조금 느릴 때 조기에 실패하고, 너무 길면 수립할 수 없는 연결이 더 오래 리소스를 점유합니다. 핸드셰이크 타임아웃이 발생하면 먼저 서버 주소, 포트, 전송 계층과 로컬 네트워크를 점검하세요.

connIdle은 데이터 활동이 없을 때 연결을 얼마나 유지할지 결정합니다. 유휴 연결이 닫히면 애플리케이션은 보통 다시 연결하지만 일부 프로그램은 이를 세션 중단으로 표시합니다. 문제 발생 간격이 일정한지 비교해 보세요. 매번 비슷한 유휴 시간 뒤 끊긴다면 정책을 점검할 가치가 있고, 시간이 무작위이며 로그에 원격 재설정이 보인다면 링크나 서버 동작일 가능성이 높습니다.

uplinkOnly와 downlinkOnly는 한 방향으로만 데이터 활동이 있는 연결을 처리하는 데 사용됩니다. 업로드나 다운로드 속도 제한이 아니며 특정 애플리케이션에 대역폭을 할당하지도 않습니다. 기존 연결 동작을 모르는 상태에서 ‘최적화’를 위해 임의로 시간을 줄이지 마세요. 그래픽 클라이언트가 생성한 기본 정책은 일반적인 사용에 적합한 경우가 많으며, 장시간 연결, 리소스 제약 또는 명확한 서비스 환경에서만 별도로 평가하면 됩니다.

통계 스위치는 수집 허용 여부만 담당합니다

statsUserUplink, statsUserDownlink와 system 아래의 인바운드·아웃바운드 통계 필드는 해당 방향의 트래픽 정보를 커널이 기록하도록 허용합니다. 이 불리언 값을 켠다고 해서 눈에 보이는 차트나 화면 숫자가 자동으로 생기는 것은 아니며, 지원되는 통계 모듈과 조회 방식도 필요합니다. 클라이언트가 이 데이터를 사용하지 않는다면 모든 통계 항목을 켜는 것은 불필요한 상태 관리만 늘립니다.

통계 항목을 연결 성공 여부를 확인하는 지표로 사용하지 마세요. 한 방향의 바이트 수가 변했다는 것은 해당 카운터 범위에 데이터가 지나간 적이 있다는 뜻일 뿐, 대상 콘텐츠가 완전히 반환되었다거나 라우팅 선택이 예상과 맞다는 것을 단독으로 증명하지는 못합니다. 연결 품질은 접속 결과와 오류 로그를 함께 확인해야 합니다. 클라이언트 화면의 트래픽 통계는 시스템 인터페이스, 커널 인터페이스 또는 자체 카운터에서 가져올 수 있어 policy의 각 스위치와 집계 기준이 완전히 같지 않을 수 있습니다.

여러 사용자 레벨은 명확한 연결 관계가 필요합니다

설정에 여러 사용자 객체가 포함되어 있다면 사용자마다 다른 level을 지정하고 policy의 levels에서 해당 정책을 정의할 수 있습니다. JSON의 레벨 키는 "0", "1"처럼 문자열로 표시됩니다. 사용자가 설정되지 않은 레벨을 참조하면 구현에 따라 커널이 기본 동작을 사용하거나 관련 문제를 보고할 수 있습니다. 유지 관리 시 사용자 레벨과 정책 레벨을 함께 확인해 한쪽만 복사하지 않도록 하세요.

일반 클라이언트 아웃바운드에는 복잡한 레벨 체계가 보통 필요하지 않습니다. 노드 구독에서 제공하는 사용자 식별 정보는 원격 프로토콜 인증에 사용되는 것이며, 로컬에서 노드마다 policy 레벨을 만들어야 한다는 뜻은 아닙니다. 인바운드 서비스로 운영하면서 세션 정책을 구분해야 할 때 여러 레벨이 더 흔합니다. 이 페이지는 클라이언트 설정에 초점을 두므로 기본 레벨 하나를 유지하고 인바운드 보안, 아웃바운드 매개변수와 라우팅 가독성에 집중하는 편이 좋습니다.

로그 수준과 정책 점검을 함께 진행하세요

정책 문제는 ‘연결된 뒤 끊김’으로 나타나는 경우가 많아 로그의 시간 흐름이 필요합니다. 평소에는 warning처럼 절제된 수준을 사용하고, 문제를 재현할 때만 일시적으로 상세 수준을 높여 시작 시간과 재현 절차를 기록하세요. 로그 경로가 권한 없는 디렉터리라면 커널이 시작되지 않거나 진단 정보가 남지 않을 수 있습니다. 그래픽 클라이언트는 보통 로그 위치를 처리하므로 독립 커널을 수동 설정할 때 파일 경로를 특별히 점검하면 됩니다.

재현 후 연결 시작, 마지막 데이터 활동, 연결 종료라는 세 시점을 먼저 비교하세요. 종료 시점이 정책 임계값과 거의 일치한다면 한 항목만 조정해 다시 테스트합니다. 로그에 원격 종료나 하위 연결 실패가 명확히 표시된다면 policy가 주요 원인은 아닙니다. 디버깅이 끝나면 적절한 로그 수준으로 되돌리고 테스트를 위해 켠 통계 항목도 삭제해 실행 설정을 간결하게 유지하세요.

08 / TROUBLESHOOTING

설정 오류와 연결 장애 문제 해결

시작 즉시 실패할 때: 첫 번째 명확한 오류부터 확인하세요

커널 시작에 실패하면 로그 뒤에 여러 연쇄 메시지가 이어질 수 있지만 실제 원인은 보통 가장 먼저 나온 명확한 오류 부근에 있습니다. JSON 파싱 실패, 알 수 없는 필드, 데이터 형식 불일치, 포트 사용 중, 접근할 수 없는 파일 경로, routing에서 참조한 태그 없음 등이 흔한 유형입니다. 첫 번째 오류를 먼저 처리한 뒤 다시 시작하세요. 후속 메시지만 보고 여러 영역을 한꺼번에 수정하면 안 됩니다. 뒤의 오류는 앞선 실패의 결과일 수 있습니다.

JSON 파싱 오류에는 보통 행 번호나 문자 위치가 표시됩니다. 해당 줄 앞뒤에 쉼표가 빠졌거나 불필요한 쉼표가 들어갔는지, 따옴표가 닫히지 않았는지, 복사 과정에서 전각 문장 부호가 섞이지 않았는지 확인하세요. 오류 위치는 파서가 문제를 발견한 지점일 뿐 실제 누락은 이전 줄에 있을 수도 있습니다. 파일이 길다면 최근 추가한 객체 전체를 잠시 제거해 기본 설정이 복구되는지 확인한 뒤 조각을 단계적으로 다시 넣으세요.

커널은 실행되지만 애플리케이션이 로컬 프록시에 연결되지 않음

이 경우 먼저 원격 노드를 확인하지 마세요. 애플리케이션의 프록시 주소가 127.0.0.1인지, 포트가 인바운드와 일치하는지, 프록시 유형이 맞는지 확인하세요. 시스템 프록시를 사용한다면 클라이언트에서 해당 모드를 활성화했는지 점검합니다. 커널만 시작한다고 시스템 설정이 자동으로 바뀌는 것은 아닙니다. 브라우저 확장 프로그램, 애플리케이션 내 프록시와 시스템 프록시가 동시에 있으면 중복 프록시가 되거나 이전 포트를 가리킬 수 있으므로 테스트할 때는 경로 하나만 명확하게 유지하세요.

Windows, macOS 또는 Linux 데스크톱에서는 이전 프로세스가 포트를 점유하는 일이 흔합니다. 클라이언트를 종료한 뒤 커널 프로세스도 함께 끝났는지 확인하고 다시 실행하세요. 인바운드 포트를 바꿨다면 시스템 프록시도 함께 업데이트해야 합니다. Android 클라이언트는 시스템 네트워크 인터페이스를 통해 애플리케이션 트래픽을 가로채므로 데스크톱 로컬 SOCKS 포트와 점검 방식이 다릅니다. 먼저 클라이언트가 연결 상태인지, 실행 로그에 커널이 정상 시작되었다고 표시되는지 확인하세요.

로컬 프록시에는 연결되지만 원격 핸드셰이크가 실패함

로그에 연결 거부, 핸드셰이크 실패 또는 원격의 조기 종료가 나타나면 ‘주소와 포트 → 사용자 식별 정보 → 프로토콜 → 전송 → 보안 계층’ 순서로 확인하세요. 도메인이 조회된다고 해서 해당 포트가 올바른 서비스로 연결된다는 뜻은 아니며, TCP 연결이 된다고 TLS 이름과 애플리케이션 계층 전송이 일치한다는 의미도 아닙니다. 구독 노드는 먼저 정상 업데이트를 한 번 실행해 현재 항목에 이전 매개변수가 남아 있지 않은지 확인하세요. 수동 노드는 원본 설정과 항목별로 비교합니다.

시스템 시간이 크게 틀리면 시간에 의존하는 보안 연결에 영향을 줄 수 있으므로 먼저 기기 시간을 정상화하세요. 네트워크를 전환한 뒤 문제가 사라졌다면 프로토콜만 수정하지 말고 현재 네트워크, DNS 또는 주소 체계도 점검해야 합니다. 노드 타임아웃은 노드 타임아웃 점검 순서에 따라 단계적으로 확인하고, 로컬 네트워크와 시스템 시간을 건너뛴 채 아웃바운드 객체만 반복해서 바꾸지 마세요.

일부 웹사이트나 애플리케이션만 실패함

일부 대상만 실패한다면 기본 인바운드와 최소 하나의 아웃바운드는 작동한다는 뜻일 가능성이 높습니다. 다음으로 라우팅, DNS, UDP와 대상의 특징을 확인하세요. 성공한 대상과 실패한 대상이 각각 어떤 아웃바운드를 사용하는지 비교한 뒤, 실패 항목이 커널에 들어올 때 도메인인지 IP인지 확인합니다. 잘못된 규칙이 특정 도메인을 direct로 보내면 노드가 정상이어도 해당 연결에는 사용되지 않습니다. domainStrategy가 다른 주소를 조회하도록 만들면 예상한 도메인 규칙과 결과가 달라질 수도 있습니다.

애플리케이션의 로그인, 음성, 동영상 또는 동기화 기능은 서로 다른 도메인, 포트와 네트워크 유형을 사용할 수 있습니다. 첫 화면이 열린다는 것은 일부 요청만 성공했다는 뜻입니다. 메인 페이지 결과만 보고 애플리케이션 전체 도메인을 너무 넓은 규칙 하나에 넣지 마세요. 재현할 때 실패한 기능의 로그 대상을 기록하고 필요한 조건을 하나씩 추가합니다. UDP가 관련되면 SOCKS 인바운드가 UDP를 허용하는지, 프록시 프로토콜과 서버가 현재 경로를 지원하는지, routing이 UDP를 올바른 출구로 보내는지 확인하세요.

규칙은 올바르게 보이지만 계속 매칭되지 않음

먼저 규칙 위치를 확인하세요. 앞에 더 넓은 domain, IP, network 또는 port 조건이 있지는 않나요? 다음으로 대상 형식을 확인합니다. 로그에 완전한 도메인, 하위 도메인, IP 또는 sniffing으로 복원된 이름 중 무엇이 보이나요? 이어서 매칭 접두사가 요구 사항에 맞는지 점검하세요. full은 모든 하위 도메인을 자동으로 포함하지 않으며 키워드는 지나치게 넓을 수 있습니다. 마지막으로 outboundTag 철자와 현재 실행 파일을 확인해 백업 파일을 수정하고 실제로는 다른 설정을 로드하는 일이 없도록 하세요.

특정 규칙을 검증하려면 임시로 앞부분으로 옮기고 대상을 명확한 도메인 하나로 제한하세요. 테스트 후 로그의 아웃바운드 태그를 확인합니다. 여전히 매칭되지 않으면 대상 형식이 잘못되었거나 설정이 로드되지 않은 것입니다. 앞부분으로 옮겼을 때 매칭된다면 원래 위치 앞의 규칙이 먼저 가로챈 것입니다. 원인을 확인한 뒤 순서를 다시 정리하세요. 새 규칙을 모두 맨 위에 쌓는 방식을 장기간 사용하면 구체적인 규칙끼리도 점점 서로 덮어쓰게 됩니다.

연결이 일정 시간 뒤 끊김

먼저 끊김이 일정한 시간 간격으로 발생하는지 확인하세요. 매번 connIdle 또는 단방향 연결 정책의 시간과 비슷하다면 policy를 점검하고, 시간이 무작위라면 원격 재설정, 네트워크 전환, 기기 절전과 주소 변경을 확인합니다. 노트북이 한 네트워크에서 다른 네트워크로 전환되면 기존 연결이 무효화되는 것은 정상이며 클라이언트가 경로를 다시 수립해야 할 수 있습니다. 절전 모드에서 깨어난 뒤 한 번 발생한 중단을 곧바로 노드 매개변수 문제로 단정하지 마세요.

로그의 timeout, context canceled와 connection reset은 서로 다른 단계와 원인을 나타내므로 단순히 ‘오류’라는 이유만으로 같은 방식으로 처리하면 안 됩니다. timeout은 앞선 로그를 함께 보고 DNS, 다이얼링 또는 핸드셰이크 중 어디서 발생했는지 판단해야 합니다. context canceled는 상위 요청이 능동적으로 종료했을 수 있고, reset은 어느 한쪽이 연결을 재설정했다는 뜻입니다. 시간 흐름에서 가장 이른 이상을 먼저 찾고 뒤의 오류가 취소 및 정리 과정에 불과한지 확인하세요.

재현 가능한 문제 해결 기록을 만드세요

복잡한 설정은 클라이언트 이름, 현재 커널 계열, 인바운드 포트, 기본 아웃바운드, 최근 수정 영역과 재현 절차를 포함한 짧은 기록을 남기는 것이 좋습니다. 노드의 민감한 정보는 기록할 필요 없이 구조만 설명하면 됩니다. 매 테스트마다 ‘무엇을 바꿨는지, 무엇을 예상했는지, 실제 로그가 무엇이었는지’를 적으면 두세 차례만으로도 대부분의 추측을 배제할 수 있습니다. 여러 옵션을 반복해서 전환하면서 기록하지 않으면 문제가 우연히 사라진 뒤에도 원인을 확인할 수 없습니다.

복구가 필요하면 먼저 최소한의 사용 가능한 설정으로 돌아간 뒤 DNS, 분기와 정책을 하나씩 추가하세요. 최소 설정에서도 실패한다면 클라이언트 설치, 로컬 네트워크 또는 노드 자체의 문제일 가능성이 높으므로 빠른 시작 경로로 돌아가 가져오기와 연결 단계를 다시 확인할 수 있습니다. 사용자 지정 규칙만 실패한다면 검증된 노드 아웃바운드는 유지하고 routing과 대상 로그에 집중하세요. 클라이언트를 다시 설치할 필요는 없습니다.