V2Ray 고급 설정 가이드

되돌릴 수 있는 설정 작업 모델부터 만들기

문제를 진입점·판단·출구로 나누기

고급 설정이 복잡해지는 이유는 특정 매개변수가 어려워서라기보다 여러 계층이 동시에 바뀌기 때문인 경우가 많습니다. 하나의 연결은 최소 세 단계를 거칩니다. 애플리케이션 트래픽이 시스템 프록시나 가상 네트워크 어댑터로 들어가고, 커널이 도메인·IP·포트·프로세스 정보를 바탕으로 라우팅을 결정한 다음, 프록시·직접 연결·차단 또는 사용자 지정 아웃바운드가 처리합니다. 구독은 원격 서버를 제공하고, 라우팅은 트래픽을 어디로 보낼지 결정하며, DNS는 도메인을 주소로 변환하고, TUN은 트래픽이 커널로 들어오는 방식을 바꿉니다. 먼저 이 네 계층을 분리하면 문제 해결을 위해 클라이언트를 반복해서 재설치할 필요가 없습니다.

예를 들어 브라우저는 연결되지만 명령줄 도구가 연결되지 않는다면 먼저 진입 계층을 확인하세요. 브라우저는 시스템 프록시를 읽지만 터미널 프로그램은 직접 연결을 시도할 수 있습니다. 일반 프록시는 작동하는데 TUN을 켠 뒤 문제가 생겼다면 가상 네트워크 어댑터, 라우팅 테이블과 DNS 인계를 우선 점검하세요. 특정 도메인이 계속 잘못된 경로로 나간다면 곧바로 구독을 바꾸기보다 라우팅 규칙의 매칭 순서를 확인해야 합니다. 도메인은 해석되지만 연결을 만들 수 없는 경우에는 해석 결과 오류, 아웃바운드 도달 불가와 프로토콜 매개변수 불일치를 구분해야 합니다. 현상을 계층에 대응시키는 것이 이 가이드의 가장 중요한 문제 해결 방법입니다.

한 번에 변수 하나만 변경하기

실험을 시작하기 전에 현재 정상 작동하는 기준 상태를 보존하세요. 선택한 서버, 시스템 프록시 상태, 라우팅 모드, DNS 모드와 TUN 활성화 여부를 기록하고, 클라이언트가 설정 내보내기나 백업을 지원한다면 사본을 저장하세요. 이후에는 한 번에 관련 설정 한 묶음만 변경하고 즉시 검증합니다. 같은 작업에서 TUN 활성화, DNS 전환, 새 라우팅 가져오기와 서버 변경을 동시에 하지 마세요. 네 가지가 함께 바뀌면 연결이 복구되어도 실제 원인을 알기 어렵고, 연결이 끊기면 원인 파악 비용이 크게 늘어납니다.

검증도 계층별로 진행해야 합니다. 먼저 클라이언트 로그에서 커널이 정상적으로 시작했는지 확인하고, 로컬 수신 포트나 가상 네트워크 어댑터가 생성되었는지 점검한 다음 도메인 해석을 테스트하고 마지막으로 대상 애플리케이션을 테스트하세요. 로그의 첫 번째 오류는 이후에 연쇄적으로 발생하는 오류보다 더 중요할 때가 많습니다. 커널이 설정 형식 오류로 시작하지 못했다면 뒤의 연결 시간 초과는 결과일 뿐입니다. 시스템 명령으로 기본 상태를 확인할 수 있지만 명령 출력은 현재 운영 체제가 관찰한 결과만 보여 주며 클라이언트 로그를 대신할 수는 없습니다.

Windows:
ipconfig /flushdns
ipconfig /all

macOS:
scutil --dns
route -n get default

Linux:
resolvectl status
ip route

안정적인 검증 샘플 준비하기

검증 샘플은 세 가지 요청을 포함해야 합니다. 직접 연결이 예상되는 사이트, 프록시 사용이 예상되는 사이트, DNS 확인만을 위한 도메인입니다. 테스트 대상을 자주 바꾸면 대상 서비스 자체의 변동이 판단을 방해할 수 있습니다. 브라우저로 테스트할 때는 프록시나 DNS를 별도로 가로채는 확장 기능을 먼저 끄고 브라우저 자체의 보안 DNS 설정도 확인하세요. 터미널 테스트에서는 HTTP_PROXY, HTTPS_PROXY 및 ALL_PROXY 환경 변수를 읽을지 명확히 지정해야 합니다. 프로그램마다 프록시 경로로 들어가는 방식은 서로 다릅니다.

변경 전후의 시각도 기록하세요. v2rayN 로그는 계속 스크롤되므로 정확한 작업 시각이 해당 요청을 찾는 데 도움이 됩니다. 로그에 도메인 없이 IP만 표시된다면 애플리케이션이 커널에 들어오기 전에 이미 도메인을 해석했을 수 있습니다. 이 경우 도메인 라우팅 규칙만 작성해서는 매칭되지 않을 수 있으므로 스니핑, DNS 또는 IP 규칙을 조정해야 합니다. 로그에 예상한 도메인이 표시되는데도 최종 아웃바운드가 잘못되었다면 규칙 우선순위와 태그를 다시 확인하세요. 이 기준 상태를 마련하면 이후 각 장에서도 같은 복구 및 검증 방법을 사용할 수 있습니다.

구독 그룹 및 서버 필터링

그룹의 목적은 출처를 분리하는 것이지 태그를 쌓는 것이 아닙니다.

v2rayN에서는 수동 서버와 여러 구독 소스를 동시에 저장할 수 있습니다. 서버 수가 늘어나면 가장 먼저 해결해야 할 문제는 “더 많이 표시하는 방법”이 아니라 “출처를 추적하는 방법”입니다. 하나의 구독 주소마다 하나의 구독 그룹을 만들고, 그룹 이름에는 용도나 출처를 분명히 적으세요. “구독 1”, “백업 2”처럼만 쓰지 않는 것이 좋습니다. 특정 서버 묶음의 매개변수가 비정상적이거나 이름이 중복되거나 업데이트 후 사라졌을 때 출처가 명확하면 점검 범위를 바로 좁힐 수 있습니다. 수동으로 추가한 테스트 서버도 별도 그룹에 넣어 구독 업데이트 때 소속을 잘못 판단하지 않도록 하세요.

그룹 이름은 안정적으로 유지하고 서버 메모는 바꿀 수 있게 두세요. 지역·용도·프로토콜 정보를 모두 그룹 이름에 넣으면 메뉴와 필터 조건이 지나치게 길어집니다. 그룹에는 출처를 표시하고 서버 메모에는 노드 특성을 표시하는 방식이 더 적절합니다. 예를 들어 그룹에는 서비스 출처를 기록하고 메모에는 “지역｜회선｜프로토콜”처럼 고정된 순서를 사용하세요. 통일된 메모 형식은 키워드 필터링의 효과를 높이고 업데이트 전후에 같은 서버 묶음을 식별하기도 쉽습니다.

포함 필터부터 적용한 뒤 제외 조건 추가하기

서버 필터링에는 보통 두 가지 논리가 있습니다. 키워드와 일치하는 항목만 남기거나, 키워드와 일치하는 항목을 제외하는 방식입니다. 처음에는 지역명이나 용도 표시처럼 명확한 포함 키워드 하나를 사용하고 결과가 올바른지 확인한 뒤 제외 키워드를 추가하세요. 복잡한 정규 표현식은 간결해 보여도 유지 관리 비용이 높습니다. 구독 제공자가 이름 규칙만 바꿔도 기존 표현식이 모든 서버를 걸러낼 수 있습니다. 필터 결과가 비어 있으면 먼저 조건을 임시로 모두 지우고 그룹을 업데이트해 원본 데이터가 있는지 확인한 다음 조건을 하나씩 복원하세요.

정규 표현식을 사용할 때는 대소문자, 공백, 전각 기호와 괄호에 주의해야 합니다. 구독 메모에서 비슷해 보이는 가로선도 하이픈, 엔 대시 또는 다른 문자일 수 있습니다. 안정적인 표현은 장식 기호가 아니라 변하지 않는 텍스트를 기준으로 작성하는 것이 좋습니다. 아래 예시는 이름에 “도쿄” 또는 “서울”이 포함된 항목을 남기고 “테스트” 또는 “만료” 표시가 있는 항목을 제외합니다. 포함 및 제외 입력란을 따로 제공하는지는 클라이언트 인터페이스에 따라 다르므로 각각 입력하고, 읽기 어려운 하나의 표현식으로 두 논리를 합치지 마세요.

포함 조건:
도쿄|서울

제외 조건:
테스트|만료

업데이트·덮어쓰기·삭제의 차이 이해하기

구독을 업데이트하면 클라이언트가 구독 내용을 다시 읽고 해당 서버 목록을 갱신합니다. 특정 서버가 사라진 이유는 상위 소스에서 삭제되었거나, 필터 조건이 바뀌었거나, 그룹 선택이 잘못되었거나, 구독 파싱에 실패했기 때문일 수 있습니다. 같은 이름의 서버를 바로 수동으로 다시 추가하지 마세요. 먼저 업데이트 로그에서 구독 요청이 성공했는지 확인하고 필터링되지 않은 원본 결과를 살펴보세요. 수동 서버와 구독 서버의 메모가 같더라도 이름만으로 같은 항목이라고 판단하지 말고 주소, 포트, 프로토콜과 그룹 소속을 확인해야 합니다.

구독 주소를 수정하기 전에 기존 그룹을 편집하는지 새 그룹을 만드는지 확인하세요. 새 주소로 기존 그룹을 바로 덮어쓰면 과거 출처와 새 출처가 같은 이름 아래 섞일 수 있습니다. 출처가 실질적으로 바뀌었다면 새 그룹을 만들고 테스트를 완료한 뒤 기존 그룹을 비활성화하는 편이 일반적으로 복구하기 쉽습니다. 기존 그룹을 정리하기 전에는 현재 활성 서버가 해당 그룹에 속하는지, 라우팅 규칙이나 사용자 지정 설정에서 관련 태그를 참조하는지도 확인하세요.

다중 출처 정리 방법은 다중 구독 그룹 관리: v2rayN 서버 필터링과 메모 작성 실전에서 계속 확인할 수 있습니다. 필터링이 안정되면 다음 장에서 라우팅을 설정하세요. 필터 기능으로 라우팅 기능을 대신해서는 안 됩니다. 필터링은 목록에 어떤 서버를 표시할지 결정하고, 라우팅은 각 요청에서 어떤 아웃바운드를 사용할지 결정하므로 두 기능은 완전히 다른 계층에 있습니다.

라우팅 규칙 실전: 매칭 순서부터 아웃바운드 태그까지

규칙은 순서가 있는 의사 결정 체인입니다.

라우팅 시스템은 요청에 포함된 정보를 바탕으로 아웃바운드를 선택합니다. 일반적인 조건으로는 도메인, 대상 IP, 대상 포트, 네트워크 유형과 프로세스 이름이 있습니다. 중요한 것은 규칙의 개수가 아니라 매칭 순서입니다. 더 구체적인 규칙을 더 일반적인 규칙보다 앞에 배치하고, 마지막에는 기본 규칙으로 나머지 트래픽을 처리해야 합니다. “모든 도메인을 프록시로 보낸다”는 규칙이 “내부 도메인은 직접 연결”보다 앞에 있으면 후자는 실행될 기회가 없습니다. 규칙을 조정할 때는 로그에서 실제 요청 하나를 골라 규칙 목록을 위에서부터 판단해야 하며, 눈으로 추측해서는 안 됩니다.

도메인 규칙은 사이트 소속을 표현하는 데 적합하고, IP 규칙은 명확한 네트워크 대역을 처리하는 데 적합하며, 포트 규칙은 특정 서비스를 제한하는 데 적합합니다. 프로세스 규칙은 클라이언트와 운영 체제가 프로세스 정보를 가져올 수 있는지에 따라 달라지므로 플랫폼을 바꿀 때 다시 검증해야 합니다. 하나의 요청이 처음에는 도메인 형태로 커널에 들어온 뒤 IP로 해석될 수도 있습니다. 도메인 정보가 유지되는지는 진입점, 스니핑과 DNS 설정에 따라 달라집니다. 따라서 같은 도메인 규칙도 일반 시스템 프록시와 TUN 모드에서 다르게 동작할 수 있습니다.

먼저 아웃바운드를 정의하고 라우팅에서 태그를 참조하기

하위 설정에서는 보통 태그로 라우팅과 아웃바운드를 연결합니다. 예를 들어 proxy는 현재 프록시 아웃바운드, direct는 직접 연결, block은 차단을 뜻합니다. 태그는 내부 참조 이름일 뿐 해당 기능을 자동으로 만들지는 않습니다. 라우팅 규칙이 존재하지 않는 태그를 참조하면 커널이 시작을 거부하거나 설정 생성 단계에서 오류를 낼 수 있습니다. v2rayN의 그래픽 라우팅 편집기를 사용하면 일부 연결 관계가 자동으로 처리되지만, 사용자 지정 JSON을 가져올 때는 태그가 일치하는지 직접 확인해야 합니다.

{
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    },
    {
      "protocol": "blackhole",
      "tag": "block"
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:intranet.example"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

위 구조는 규칙 관계를 보여 주지만 proxy 아웃바운드는 현재 서버를 바탕으로 클라이언트가 생성하므로 이 조각만 따로 저장해 완전한 실행 설정으로 사용할 수 없습니다. 사설 주소 규칙을 앞에 두면 로컬 네트워크 장치가 원격으로 전송되는 것을 막을 수 있습니다. 그다음 명확한 도메인 규칙이 매칭되고, 마지막 규칙이 남은 TCP와 UDP를 처리합니다. 일부 트래픽만 프록시로 보내려면 전체 트래픽을 포착하는 규칙을 추가하지 말고 대상 도메인에 프록시 규칙을 만든 뒤 기본 아웃바운드는 직접 연결로 유지하세요.

적절한 도메인 전략 선택하기

AsIs는 라우터로 들어온 도메인 정보를 그대로 사용하며 IP 규칙을 위해 적극적으로 해석하지 않는 방식입니다. IPIfNonMatch는 도메인 규칙이 매칭되지 않을 때 IP를 해석한 뒤 IP 규칙을 다시 시도합니다. IPOnDemand는 IP 판단이 필요할 수 있는 요청을 더 적극적으로 해석합니다. 전략이 적극적일수록 DNS가 라우팅 결과에 미치는 영향도 커집니다. 규칙이 주로 도메인을 기준으로 한다면 일반적으로 도메인 정보를 유지하는 방식부터 시작하고, 지리적 IP 데이터에 의존한다면 매칭 실패 시 해석하는 방식을 고려하세요.

“매칭률을 높이기 위해” 많은 도메인 규칙과 IP 규칙을 동시에 쌓지 마세요. 도메인의 해석 결과는 바뀔 수 있고 콘텐츠 전송 서비스가 주소를 공유하기도 합니다. 지나치게 넓은 IP 범위는 관련 없는 사이트까지 잘못 처리할 수 있습니다. 고정된 내부 네트워크 대역에는 IP 규칙이 적합하지만 공용 사이트에는 도메인 분류를 우선하고 로그로 확인하세요. 규칙이 매칭되지 않을 때 로그에 완전한 도메인, 하위 도메인 또는 순수 IP 중 무엇이 표시되는지 확인해야 합니다. IP만 보인다면 도메인 항목을 계속 늘리기보다 DNS와 스니핑 계층으로 돌아가야 합니다.

“열린다”가 아니라 라우팅 결과를 검증하기

웹페이지가 열린다고 해서 라우팅이 올바른 것은 아닙니다. 잘못된 아웃바운드를 통해 우연히 성공했을 수도 있습니다. 검증할 때는 연결 로그에서 대상, 매칭된 규칙과 최종 아웃바운드 태그를 확인하세요. 직접 연결이 예상되는 샘플과 프록시가 예상되는 샘플을 각각 요청해 서로 다른 경로로 가는지 확인합니다. 로컬 네트워크 서비스는 호스트 이름과 IP로 모두 접속해 보세요. 호스트 이름은 DNS를 통해 사설 주소로 해석될 수 있지만 IP를 직접 입력하면 도메인 단계가 생략되기 때문입니다.

규칙이 작동하지 않을 때는 “규칙 순서, 조건 형식, 요청에서 보이는 정보, 아웃바운드 태그” 네 가지를 점검하세요. 먼저 대상 규칙을 일시적으로 맨 위로 옮깁니다. 그래도 매칭되지 않으면 조건을 줄여 도메인이나 IP 하나만 남기고, 진입점에 필요한 정보가 포함되는지 확인한 다음 태그가 존재하는지 점검하세요. 이렇게 하면 복잡한 규칙을 검증 가능한 최소 샘플로 되돌릴 수 있습니다. VLESS, VMess, REALITY 같은 용어와 라우팅의 관계는 용어집에서 확인할 수 있지만, 프로토콜 이름 자체를 라우팅 결과의 대체 지표로 사용해서는 안 됩니다.

DNS 설정 최적화: 누가 어디에서 해석하는지 명확히 하기

먼저 해석 경로를 명확히 그리기

DNS 문제의 가장 흔한 원인은 “여러 해석 주체가 동시에 존재하는 것”입니다. 애플리케이션이 직접 해석할 수도 있고, 운영 체제에는 시스템 리졸버가 있으며, 브라우저는 별도의 보안 DNS를 사용할 수 있습니다. v2rayN 커널도 DNS를 처리할 수 있고 TUN 모드는 시스템 조회를 인계할 수 있습니다. 설정하기 전에 세 가지 질문에 답해야 합니다. 누가 도메인 조회를 시작하는지, 어느 서버에 조회를 맡기는지, 조회 자체가 직접 연결인지 프록시인지입니다. 경로를 확인하지 않고 DNS 주소만 바꾸면 로그는 정상처럼 보이지만 실제 요청은 기존 캐시를 사용하는 일이 생깁니다.

일반 시스템 프록시에서는 많은 애플리케이션이 먼저 로컬에서 도메인을 해석한 뒤 IP를 프록시에 전달합니다. 반면 SOCKS의 원격 해석 기능을 통해 도메인을 커널에 전달하는 애플리케이션도 있습니다. TUN 모드에서는 시스템 트래픽을 통합적으로 인계하기 쉬워지지만 브라우저 내부 해석은 여전히 예상 경로를 우회할 수 있습니다. 문제를 확인할 때는 먼저 애플리케이션 계층의 독립 DNS를 꺼서 비교하고 시스템 캐시를 비운 다음, 전에 접속하지 않은 하위 도메인 요청을 새로 보내 클라이언트 로그에 해당 조회가 나타나는지 확인하세요.

로컬 DNS와 원격 DNS의 역할 분담

안정적인 전략은 모든 도메인을 하나의 해석기에 맡기는 것이 아니라 용도에 따라 나누는 것입니다. 로컬 네트워크 호스트 이름과 내부 도메인은 이를 인식할 수 있는 로컬 해석기에 맡기고, 프록시 측 관점에서 해석해야 하는 공용 도메인은 프록시를 통해 접근하는 DNS에 맡길 수 있습니다. 일반 직접 연결 도메인은 시스템 또는 지정한 로컬 DNS를 사용하세요. 트래픽을 분리하기 전에 사설 주소와 내부 접미사에 대한 직접 연결 경로를 유지해야 합니다. 그렇지 않으면 프린터, 라우터 관리 페이지와 개발 환경 서비스가 해석되지 않을 수 있습니다.

DNS 서버 주소의 형식도 부트스트랩 과정에 영향을 줍니다. 암호화된 DNS 엔드포인트를 도메인 형식으로 사용하면 클라이언트가 먼저 엔드포인트 자체를 해석해야 하므로 “해석기를 해석하는” 부트스트랩 문제가 생깁니다. 사용 가능한 부트스트랩 DNS를 제공하거나 명확한 IP 엔드포인트를 사용하고 서버 이름을 올바르게 처리해야 합니다. 서로 의존하는 두 해석기를 순환 구조로 설정하지 마세요. A의 도메인을 B에 맡기고 B의 도메인을 다시 A에 맡기면 시작 후 오래 기다리거나 주기적으로 시간 초과가 발생합니다.

{
  "dns": {
    "hosts": {
      "router.internal": "192.168.1.1"
    },
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": [
          "domain:internal"
        ],
        "skipFallback": true
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

이 예시는 정적 호스트 매핑, 내부 도메인 전용 해석기와 보조 해석기를 보여 줍니다. 실제로 사용할 때는 192.168.1.1을 로컬 네트워크에서 실제로 사용할 수 있는 DNS 주소로 바꾸고 해당 주소가 조회에 응답하는지 확인하세요. skipFallback은 지정된 도메인과 매칭된 뒤 다른 서버로 넘어가지 않도록 하며 내부 도메인에 적합합니다. 전용 해석기가 불안정하면 이 설정이 장애를 그대로 드러내므로 먼저 별도로 테스트해야 합니다.

조회 전략과 주소 체계 이해하기

DNS는 IPv4, IPv6 또는 두 주소를 모두 반환하며 애플리케이션은 그중 하나를 선택해 연결합니다. 네트워크의 IPv6 지원이 불완전한 경우 해석기가 IPv6 주소를 반환해도 경로가 사용 가능하다는 뜻은 아닙니다. 흔히 첫 연결이 지연된 뒤 IPv4로 전환됩니다. 이때는 먼저 시스템에 완전한 IPv6 라우팅이 있는지 확인한 다음 조회 전략을 결정하세요. 한 번 연결이 느렸다는 이유만으로 특정 주소 유형을 영구적으로 끄지 말고 시스템 네트워크 도구로 기본 경로, DNS 응답과 대상 도달 가능성을 확인해야 합니다.

UseIP, UseIPv4, UseIPv6 같은 전략은 커널이 어떤 결과를 허용하거나 우선할지 제어하며, 지원 범위는 현재 커널에 따라 다릅니다. 여러 장치로 설정을 옮길 때 주소 체계 전략을 그대로 복사해서는 안 됩니다. 유선 데스크톱 네트워크, 무선 네트워크와 모바일 핫스팟의 지원 수준이 다를 수 있습니다. 고정 네트워크에 적합한 설정이 다른 네트워크에서는 해석은 성공하지만 연결은 실패하게 만들 수 있습니다.

조정을 완료한 뒤 클라이언트 캐시, 시스템 캐시와 애플리케이션 캐시를 차례로 비우고 새 도메인을 테스트하세요. 웹페이지만 새로 고치면 브라우저가 기존 연결을 재사용해 DNS 변경이 반영되지 않을 수 있습니다. DNS 최적화의 목표는 해석기 수를 계속 늘리는 것이 아니라 경로를 명확하게 하고 장애를 관찰 가능하게 만드는 것입니다. 역할이 분명한 해석 입구 두세 개가 긴 자동 전환 주소 목록보다 보통 유지 관리하기 쉽습니다.

TUN 모드: 시스템 트래픽을 인계하되 경계를 숨기지 않기

TUN과 시스템 프록시는 서로 다른 문제를 해결합니다.

시스템 프록시는 애플리케이션이 프록시 설정을 능동적으로 읽어야 합니다. 브라우저와 대부분의 데스크톱 애플리케이션은 지원하지만 일부 명령줄 도구, 게임 프로그램 또는 사용자 지정 네트워크 구성 요소는 무시할 수 있습니다. TUN 모드는 가상 네트워크 어댑터와 시스템 라우팅을 통해 더 많은 IP 트래픽을 커널로 보내므로 적용 범위가 넓지만, 라우팅 테이블·DNS 인계·권한·가상 네트워크 어댑터 드라이버라는 새로운 변수가 생깁니다. 이는 시스템 프록시의 “더 강한 스위치”가 아니라 다른 진입 경로입니다.

TUN을 활성화하기 전에 동일한 서버가 일반 프록시 모드에서 안정적으로 연결되는지 확인하세요. 이렇게 하면 원격 프로토콜, 구독 매개변수와 서버 도달 가능성을 일시적으로 문제 범위에서 제외할 수 있습니다. 그런 다음 현재 시스템 DNS, 기본 게이트웨이와 클라이언트 라우팅 모드를 기록하고, 다른 가상 네트워크 어댑터를 만들 수 있는 네트워크 도구를 끈 뒤 TUN을 활성화하세요. 첫 테스트에서는 기본 라우팅만 유지하고 FakeDNS와 복잡한 사용자 지정 규칙을 동시에 켜지 마세요.

권한·가상 네트워크 어댑터·라우팅 테이블

가상 네트워크 어댑터를 만들고 시스템 라우팅을 설정하려면 보통 높은 권한이 필요합니다. 권한이 부족하면 화면의 스위치는 바뀌어도 로그에 어댑터 생성이나 라우팅 설정 실패가 표시될 수 있습니다. Windows에서는 가상 네트워크 어댑터 상태, 방화벽과 라우팅 우선순위를 중점적으로 확인하고, macOS에서는 시스템 권한, 네트워크 확장 상태와 DNS 서비스 순서를 확인해야 합니다. Linux에서는 TUN 장치 권한, 정책 라우팅, 네트워크 관리 서비스와 방화벽 규칙을 점검하세요. 문제가 발생하면 스위치를 반복해서 누르기보다 로그의 첫 번째 시스템 호출 오류부터 확인해야 합니다.

가상 네트워크 어댑터가 생성된 뒤 예상한 주소와 라우팅이 추가되었는지 확인하세요. 기본 경로가 바뀌지 않았다고 반드시 실패한 것은 아닙니다. 일부 구현은 더 구체적인 경로나 정책 라우팅으로 트래픽을 인계합니다. 반대로 새 기본 경로가 보인다고 해서 모든 트래픽이 올바르게 돌아온다는 뜻도 아닙니다. 사설 네트워크 대역, 현재 게이트웨이와 DNS 서버가 잘못 프록시로 보내져 루프를 만들지 않는지도 확인해야 합니다. 로컬 네트워크 접속이 끊기면 먼저 사설 주소가 직접 연결되는지, “로컬 네트워크 연결 허용”과 같은 수신 설정이 로컬 방화벽과 일치하는지 점검하세요.

MTU와 UDP 경계

TUN 연결은 수립되지만 일부 사이트가 멈춘다면 MTU를 고려해야 합니다. 추가 캡슐화로 패킷이 커지고 하위 네트워크가 올바르게 조각화하지 못하거나 경로 MTU 정보를 전달하지 못하면 큰 요청이 조용히 손실될 수 있습니다. 일반적인 증상은 작은 페이지나 텍스트 요청은 정상인데 업로드, 이미지와 장시간 연결이 비정상적인 경우입니다. MTU는 조금씩 조정하고 매번 같은 요청을 테스트하세요. 값을 곧바로 지나치게 낮추면 조각화와 처리 오버헤드가 늘어납니다.

UDP도 별도로 검증해야 합니다. DNS는 UDP를 자주 사용하지만 일부 애플리케이션은 다른 UDP 프로토콜도 사용합니다. 서버 아웃바운드, 커널, TUN 스택과 라우팅 규칙이 해당 트래픽을 모두 허용해야 합니다. TCP는 정상인데 UDP만 비정상이라면 먼저 라우팅 로그에서 UDP 요청이 커널에 들어왔는지 확인한 뒤 아웃바운드 기능과 로컬 방화벽을 점검하세요. 모든 UDP 장애를 DNS 탓으로 돌려서는 안 됩니다. DNS도 TCP나 암호화된 전송을 사용할 수 있기 때문입니다.

TUN 종료 후 시스템 상태 복구하기

클라이언트를 정상적으로 종료하면 가상 네트워크 어댑터, 라우팅과 DNS 설정이 정리되어야 합니다. 시스템 강제 종료, 클라이언트 충돌 또는 권한 변경이 발생하면 이전 상태가 남을 수 있습니다. TUN을 끈 뒤에도 네트워크가 비정상이라면 먼저 클라이언트를 완전히 종료하고 가상 네트워크 어댑터와 라우팅이 남아 있는지 확인한 다음 현재 네트워크에 다시 연결하세요. 필요하면 시스템 네트워크 서비스를 재시작하되, 정체를 알 수 없는 시스템 인터페이스를 바로 삭제하지 마세요. 잘못된 인터페이스를 삭제하면 정상 네트워크에 영향을 줄 수 있습니다.

안정성 테스트는 시작, 종료, 절전 모드 복귀, 네트워크 전환과 시스템 재시작을 포함해야 합니다. 한 번 연결에 성공했다고 해서 수명 주기 처리가 완전하다는 뜻은 아닙니다. 이 모든 상황에서 복구되는지 확인한 뒤 FakeDNS 설정으로 넘어가세요. 브라우저와 일반 데스크톱 소프트웨어만 프록시로 사용하면 된다면 시스템 프록시의 유지 관리 비용이 더 낮습니다. 프록시 설정을 읽지 않는 프로그램이 실제로 있을 때만 TUN의 추가 복잡성이 분명한 이점을 제공합니다.

FakeDNS: 도메인 정보를 유지하는 주소 매핑

“가상 주소”의 용도 이해하기

일부 애플리케이션은 로컬에서 DNS 해석을 완료한 뒤 대상 IP만 TUN에 전달합니다. 커널이 순수 IP만 받으면 해당 요청이 원래 어떤 사이트를 대상으로 했는지 도메인 라우팅 규칙으로 판단하기 어렵습니다. FakeDNS는 전용 주소 풀에서 도메인마다 임시 주소를 할당하고, 애플리케이션이 이 주소에 연결하면 커널이 매핑을 통해 원래 도메인을 복원하는 방식입니다. 이렇게 하면 TUN이 IP 트래픽을 계속 인계하면서도 도메인 규칙을 사용할 수 있습니다.

전용 주소는 실제 원격 호스트를 가리키지 않으며 로컬 프록시 경로 안에서만 의미가 있습니다. 따라서 FakeDNS는 매핑을 인식할 수 있는 진입점, DNS와 라우팅이 함께 작동해야 합니다. 주소 풀만 설정하고 시스템 조회가 FakeDNS로 들어가도록 하지 않으면 매핑이 생성되지 않습니다. 시스템이 가상 주소를 받았더라도 트래픽이 해당 TUN으로 들어가지 않으면 연결은 바로 실패합니다. 설정할 때는 “조회가 가상 주소를 반환하고 연결이 커널에서 원래 대상으로 복원되는” 전체 흐름을 하나의 폐쇄 루프로 구성해야 합니다.

주소 풀은 기존 네트워크와 겹치지 않게 설정하기

FakeDNS 주소 풀은 로컬 네트워크, 기업 네트워크, 컨테이너 네트워크와 다른 가상 네트워크 어댑터의 대역을 피해 설정해야 합니다. 주소 풀이 실제 라우팅과 겹치면 운영 체제가 연결을 잘못된 인터페이스로 보낼 수 있고 커널이 요청을 보지 못할 수도 있습니다. 주소 풀을 선택하기 전에 현재 라우팅 테이블을 확인하고 장치가 자주 연결하는 네트워크 환경도 고려하세요. 노트북이 가정용 네트워크에서 작동한다고 해서 사무실 네트워크로 바꾼 뒤에도 충돌하지 않는다는 보장은 없습니다.

주소 풀의 크기는 저장할 수 있는 매핑 수에 영향을 줍니다. 일반적인 데스크톱 환경에서는 지나치게 넓은 범위보다 안정성과 비충돌이 중요합니다. 매핑에는 수명이 있으며 애플리케이션 캐시 시간, 커널 캐시와 시스템 DNS 캐시가 일치하지 않으면 원래 도메인을 찾을 수 없는 이전 가상 주소가 남을 수 있습니다. 주소 풀을 바꾸거나 FakeDNS 모드를 전환한 뒤에는 시스템과 애플리케이션 DNS 캐시를 비우고 연결을 새로 만들어야 합니다.

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "inbounds": [
    {
      "tag": "tun-in",
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls",
          "fakedns"
        ]
      }
    }
  ]
}

이 조각은 FakeDNS 주소 풀과 진입점 스니핑의 관계를 설명하기 위한 것이며 단독으로 실행할 수 있는 완전한 설정이 아닙니다. v2rayN은 보통 인터페이스 옵션에 따라 진입점과 라우팅을 생성하므로 설정을 수동으로 병합할 때 같은 이름의 인바운드가 중복 정의되지 않았는지 확인해야 합니다. destOverride는 커널이 식별 가능한 정보를 바탕으로 대상을 복원하도록 하지만 스니핑은 콘텐츠를 복호화하는 기능이 아니라 연결 수립 단계에서 보이는 프로토콜 정보를 사용하는 기능입니다. 식별할 수 없는 트래픽은 FakeDNS 매핑이나 IP 규칙에 의존해야 합니다.

FakeDNS에 맡기기 적합하지 않은 요청

로컬 네트워크 호스트 이름, 내부 서비스 검색 도메인과 다른 장치에 실제 주소를 반환해야 하는 조회에는 일반적으로 FakeDNS를 사용하지 않아야 합니다. 이런 요청은 로컬 DNS에 맡기고 사설 주소 규칙으로 직접 연결해야 합니다. 프린터, 저장 장치 또는 개발 환경 도메인을 가상 주소로 매핑하면 애플리케이션은 요청을 커널로 보낼 수 있어도 로컬 네트워크 검색, 인증서 검증이나 우회 장치 접근이 실패할 수 있습니다. 내부 접미사에는 명확한 DNS 분리 규칙을 만들고 공용 해석 규칙보다 앞에 배치하세요.

해석 결과를 사용자에게 직접 보여 주거나 다른 프로그램에 전달하는 도구도 주의해야 합니다. 명령줄 조회에서 전용 주소가 보이는 것은 예상된 동작이지만 후속 프로그램이 TUN을 거치지 않으면 그 결과를 사용할 수 없습니다. 문제 해결 스크립트, 모니터링 프로그램과 컨테이너 환경에서는 “호스트에서 해석하고 다른 네트워크 네임스페이스에서 연결하는” 상황이 자주 발생합니다. 조회와 연결이 같은 프록시 입구를 통과하는지 확인하는 것이 FakeDNS의 적합성을 판단하는 핵심입니다.

폐쇄 루프 방식으로 매핑 실패 점검하기

점검 순서는 네 단계로 고정하는 것이 좋습니다. 먼저 DNS 조회가 클라이언트로 들어오는지 확인하고, 반환된 주소가 설정한 주소 풀에 속하는지 확인한 다음, 해당 주소에 대한 애플리케이션 연결이 TUN으로 들어오는지 확인합니다. 마지막으로 로그에서 원래 도메인이 복원되고 올바른 라우팅 규칙과 매칭되는지 확인하세요. 첫 단계가 실패하면 시스템 또는 애플리케이션 DNS를 점검하고, 두 번째가 실패하면 FakeDNS 규칙과 캐시를 점검합니다. 세 번째가 실패하면 가상 네트워크 어댑터와 라우팅을, 네 번째가 실패하면 매핑 수명·스니핑·규칙 순서를 확인하세요.

활성화 후 일부 프로그램만 비정상이라면 곧바로 주소 풀을 확장하지 마세요. 먼저 문제가 있는 프로그램과 정상 프로그램의 DNS 동작을 비교하고 독립 해석 사용 여부, 이전 주소 캐시, 시스템 라우팅 우회 여부 또는 해석 결과를 다른 프로세스에 전달하는지 확인하세요. FakeDNS는 “TUN에 들어오기 전에 도메인 정보가 사라지는” 문제를 해결하는 데 적합할 뿐 모든 DNS 장애를 고치는 기능은 아닙니다. 일반 DNS와 TUN이 안정된 상태에서 활성화해야 구체적인 변화가 명확히 보입니다.

다중 구독 관리: 업데이트·마이그레이션·장애 격리

구독을 설정 출처로 관리하기

구독 수가 늘어나면 관리의 초점은 “가장 빠른 서버 고르기”에서 “설정 변경 통제”로 옮겨갑니다. 각 구독은 계속 변하는 외부 출처입니다. 서버가 추가·삭제·이름 변경되거나 매개변수가 조정될 수 있습니다. 출처의 용도, 업데이트 방식, 마지막 성공 업데이트 시각과 현재 일상적인 선택에 참여하는지 여부를 기록하세요. 클라이언트 그룹 이름은 출처를 표현하고, 메모 접두사는 서버 특성을 표현하며, 필터 조건은 보기를 좁히는 역할을 합니다. 이 세 계층을 섞지 마세요.

구독은 자주 사용, 백업과 테스트 세 종류로 나누는 것이 좋지만 복잡한 계층으로 만들 필요는 없습니다. 자주 사용하는 출처는 일상 업데이트에 참여시키고, 백업 출처에는 검증용 샘플을 소수만 남기며, 테스트 출처는 새 설정을 관찰하는 용도로 사용하세요. 새 구독은 먼저 테스트 그룹에 넣고 파싱·연결·DNS·라우팅 검증을 마친 뒤 자주 사용하는 목록에 포함합니다. 이렇게 하면 새 출처에 비정상적인 매개변수가 있어도 현재 작동하는 경로를 즉시 대체하지 않습니다.

관찰 가능한 업데이트 절차 마련하기

모든 구독을 동시에 업데이트하면 편리하지만 실패 원인을 찾기 어렵습니다. 처음 정리할 때는 그룹별로 수동 업데이트하며 각 그룹의 성공 여부, 서버 수의 큰 변화 여부와 필터링 후 결과가 남아 있는지를 기록하세요. 안정성이 확인된 뒤 일괄 업데이트를 사용하면 됩니다. 특정 그룹의 업데이트가 실패했을 때 짧은 간격으로 계속 재시도하지 마세요. 먼저 응답 오류인지, 파싱 오류인지, 필터 결과가 비어 있는지 확인해야 합니다. 네트워크 요청 성공은 콘텐츠를 받았다는 뜻일 뿐 클라이언트가 올바르게 파싱했다는 의미는 아닙니다.

업데이트 전에 검증된 활성 서버 하나를 유지하고 업데이트 직후 이전 항목을 바로 정리하지 마세요. 새 결과에서 하나를 골라 먼저 테스트하고 연결과 라우팅이 정상인지 확인한 뒤 명확히 작동하지 않는 데이터만 삭제하세요. 업데이트가 그룹 전체를 덮어쓰는 방식이라면 큰 변경 전에 클라이언트 설정을 내보내는 것이 좋습니다. 백업의 가치는 구독 주소만 저장하는 데 있지 않고 그룹, 메모와 규칙 관계를 복구할 수 있다는 데 있습니다.

중복 서버와 메모 변경 관리하기

두 출처가 매개변수는 같지만 메모가 다른 서버를 제공할 수도 있고, 같은 메모가 서로 다른 매개변수를 가리킬 수도 있습니다. 중복을 제거할 때 이름만 봐서는 안 됩니다. 최소한 프로토콜, 주소, 포트, 전송 방식, 보안 계층 매개변수와 주요 식별자를 비교하세요. 매개변수가 완전히 같다면 출처가 더 안정적이고 이름이 명확한 항목을 남길 수 있습니다. 일부만 같다면 서로 다른 설정으로 보고 병합하지 마세요.

메모 변경은 키워드 필터링을 망가뜨릴 수 있습니다. 해결책은 정규 표현식을 계속 늘리는 것이 아니라 중요한 서버에 로컬 통일 메모를 만들거나 필터 단어가 비교적 안정적인 지역과 용도 필드만 의존하게 하는 것입니다. 업데이트 때 클라이언트가 메모를 초기화한다면 필터 논리를 더 느슨하게 설계하고 그룹으로 범위를 좁히세요. 필터 표현식이 상위 소스의 서식에 많이 의존할수록 유지 관리 빈도도 높아집니다.

장치를 옮길 때 계층별로 복구하기

장치를 옮길 때 시스템 관련 설정을 한 번에 모두 복사하지 마세요. 먼저 플랫폼에 맞는 클라이언트를 설치합니다. 데스크톱에서는 v2rayN을 우선 사용하고, Android에서는 커널 요구 사항에 따라 v2rayNG 또는 v2flyNG를 선택할 수 있습니다. 그런 다음 구독과 그룹을 가져오고 일반 프록시 연결을 확인한 뒤 라우팅 규칙과 DNS를 옮기고 마지막으로 새 시스템의 기능에 맞춰 TUN을 다시 설정하세요. 가상 네트워크 어댑터 권한, DNS 서비스와 프로세스 규칙은 플랫폼마다 다르므로 이전 장치의 설정을 그대로 복사해서는 안 됩니다.

마이그레이션 후 첫 번째 검증에서는 구독 하나, 서버 하나와 간단한 라우팅 한 세트만 선택하세요. 안정된 뒤 필터 조건과 다중 출처 업데이트를 복원합니다. 이전 장치에서 내보낸 사용자 지정 설정에 절대 파일 경로, 로컬 포트 또는 로컬 네트워크 DNS 주소가 포함되어 있다면 하나씩 교체해야 합니다. 특히 127.0.0.1 수신 포트는 새 장치에서 다른 프로그램이 사용 중일 수 있어 커널 시작 실패를 일으킬 수 있습니다.

자주 삭제하기보다 장애 격리 구조 만들기

비정상 서버를 발견하면 먼저 비활성화 또는 테스트 그룹으로 옮기고 로그와 매개변수를 비교용으로 보존하세요. 바로 삭제하면 비교 샘플을 잃고 다음 구독 업데이트 때 다시 나타날 수도 있습니다. 출처에서 제거된 것이 확인되거나, 매개변수가 장기간 작동하지 않거나, 중복 항목으로 대체된 경우에만 기록을 정리하세요. 업데이트 후 구독 전체가 비정상이라면 자동 선택에 계속 참여시키지 말고 해당 그룹을 임시로 비활성화하세요.

장기 유지 관리는 짧은 주기를 정해 진행할 수 있습니다. 구독 업데이트, 실패 로그 확인, 자주 사용하는 서버 검증, 작동하지 않는 필터 단어 정리와 설정 백업을 수행하세요. 매일 모든 절차를 반복할 필요는 없지만 큰 변경 전에는 실행해야 합니다. 클라이언트 자체 업데이트와 구독 내용 업데이트도 따로 처리하세요. 클라이언트 설치 패키지를 바꾸기 전에는 다운로드 페이지의 플랫폼 안내를 확인해 현재 플랫폼과 클라이언트 모델을 확인한 뒤 기준 상태에 따라 설정을 복구하세요.

사용자 지정 아웃바운드: 로컬 서비스 연결과 명확한 폴백 경로

사용자 지정 아웃바운드가 필요한 경우

일반적인 사용에는 현재 서버가 생성하는 프록시 아웃바운드, 직접 연결과 차단이면 충분합니다. 사용자 지정 아웃바운드는 특정 트래픽을 로컬의 다른 SOCKS 서비스로 보내거나, 특정 대상에 독립된 출구를 지정하거나, 제어 가능한 폴백 체인을 만드는 등 명확한 엔지니어링 요구에 적합합니다. 구독 설정 오류를 감추는 용도로 사용해서는 안 됩니다. 현재 서버 자체가 연결되지 않는다면 먼저 프로토콜 매개변수와 네트워크 도달 가능성을 수정한 뒤 아웃바운드 추가를 고려하세요.

사용자 지정 아웃바운드를 설계할 때는 세 가지 정보를 먼저 명확히 적으세요. 어떤 규칙이 진입 요청과 매칭되는지, 대상 아웃바운드가 어떤 프로토콜과 주소를 사용하는지, 아웃바운드 실패 후 폴백을 허용할지입니다. 각 아웃바운드에는 local-socks, direct처럼 고유하고 의미가 분명한 태그를 사용하세요. proxy1, proxy2처럼 의미 없는 이름은 설정이 커지면 로그에서 실제 경로를 판단하기 어렵습니다.

로컬 SOCKS 아웃바운드 연결하기

아래 예시는 domain:service.example과 매칭되는 트래픽을 로컬 127.0.0.1:1081의 SOCKS 서비스로 보냅니다. 해당 로컬 서비스가 이미 실행 중이어야 하며 트래픽을 다시 현재 v2rayN 입구로 보내 루프를 만들면 안 됩니다. 수신 주소에 루프백 인터페이스를 사용하면 접근 범위를 제한할 수 있습니다. 로컬 네트워크 서비스에 연결해야 한다면 방화벽과 접근 제어를 별도로 검토하세요.

{
  "outbounds": [
    {
      "tag": "local-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1081
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": [
          "domain:service.example"
        ],
        "outboundTag": "local-socks"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

저장하기 전에 JSON 구조, 포트 유형과 태그 철자를 확인하세요. 포트는 숫자여야 하며 따옴표가 붙은 텍스트로 작성하면 안 됩니다. v2rayN에서 설정 조각 병합 기능을 사용한다면 병합 위치도 확인해야 합니다. 완전한 outbounds 배열을 클라이언트 생성 설정에 덮어쓰면 현재 서버에 해당하는 프록시 아웃바운드가 삭제될 수 있습니다. 클라이언트가 지원하는 사용자 지정 아웃바운드 또는 고급 설정 진입점을 사용하고, 생성된 실행 설정에 기존 아웃바운드가 남아 있는지 확인하는 편이 안전합니다.

루프와 이중 프록시 피하기

루프는 보통 두 로컬 서비스가 서로에게 트래픽을 넘길 때 발생합니다. 예를 들어 v2rayN 입구가 127.0.0.1:10808에서 수신하고, 사용자 지정 아웃바운드가 다른 로컬 서비스에 연결했는데 그 서비스의 상위 서버가 다시 127.0.0.1:10808을 가리키는 경우입니다. 로그에는 반복 연결, 포트 고갈 또는 연결 시간 초과가 빠르게 나타납니다. 애플리케이션에서 최종 네트워크 출구까지 단방향 경로를 그려 어느 단계도 상위 입구로 돌아가지 않는지 확인하세요.

시스템 프록시와 환경 변수도 보이지 않는 루프를 만들 수 있습니다. 로컬 상위 프로그램이 시스템 프록시를 자동으로 읽으면 아웃바운드 연결이 다시 v2rayN으로 들어갈 수 있습니다. 로컬 상위 프로그램을 실행할 때 시스템 프록시를 무시하는지 명확히 확인하거나 해당 프로세스에 직접 연결 규칙을 설정하세요. 프로세스 규칙 지원 여부는 플랫폼마다 다르므로 대상 주소 직접 연결을 보완책으로 준비할 수도 있지만 주소가 바뀌면 관리해야 합니다.

폴백은 자동 “장애 허용”이 아닙니다.

여러 아웃바운드가 나란히 존재한다고 해서 커널이 실패한 경로에서 다음 경로로 자동 전환하는 것은 아닙니다. 폴백, 부하 분산 또는 상태 확인에는 그에 맞는 정책 객체와 관찰 가능한 조건이 필요합니다. 명확히 설정하지 않았다면 각 라우팅을 결정된 선택으로 간주하세요. 매칭되면 지정된 아웃바운드로 전달됩니다. 문제 해결을 명확하게 하려면 처음에는 사용자 지정 아웃바운드 하나만 설정하고 안정성을 확인한 뒤 정책을 추가하세요.

폴백 경로에서는 연결 실패와 애플리케이션 응답 실패도 구분해야 합니다. 커널은 보통 네트워크 연결이 수립되었는지는 확인할 수 있지만 모든 애플리케이션 계층 상태를 “경로를 바꿔야 하는 실패”로 판단할 수는 없습니다. 지나치게 적극적인 폴백은 같은 요청을 반복 전송할 수 있어 제출 작업에는 적합하지 않습니다. 정책은 모든 실패를 재시도 가능하다고 보지 말고 프로토콜과 업무 성격에 따라 설계해야 합니다.

시작 로그부터 단일 요청 검증까지

사용자 지정 설정을 저장한 뒤 먼저 커널을 재시작하고 설정 로드 단계의 로그를 확인하세요. 알 수 없는 필드, 존재하지 않는 태그, 포트 형식 오류 또는 배열 덮어쓰기가 나타나면 첫 번째 오류부터 수정합니다. 커널이 정상적으로 시작되면 대상 요청 하나만 보내 로그에 대상 도메인, 매칭 규칙과 local-socks 태그가 표시되는지 확인하세요. 이후 로컬 SOCKS 서비스를 중지하고 다시 요청해 오류가 로컬 포트를 정확히 가리키는지 관찰합니다. 이 역방향 테스트를 통해 트래픽이 실제로 사용자 지정 아웃바운드를 통과했는지 확인할 수 있습니다.

커널을 시작한 직후 바로 종료된다면 로그를 한 줄씩 읽어 설정 오류 찾기를 참고하세요. 시스템 프록시를 켠 뒤 브라우저와 터미널의 동작이 다르다면 브라우저와 터미널을 나누어 문제 해결하기를 읽어 보세요. 사용자 지정 아웃바운드 설정을 완료한 뒤 작동하는 설정 사본을 저장하고 필요한 로컬 포트와 서비스 시작 순서를 기록하세요. 이렇게 하면 시스템 재시작, 클라이언트 마이그레이션 또는 포트 충돌이 발생해도 명확한 기준 상태로 빠르게 복구할 수 있습니다.