VMess·VLESS·Trojan·Shadowsocks 비교: 프록시 프로토콜 4종 선택 가이드

1. 프로토콜 4종의 차이: 인증, 암호화, 외부 보호

프로토콜 4종을 단순히 ‘구형·신형’으로 나눌 수는 없습니다. VMess와 Shadowsocks는 자체 데이터 암호화 방식을 사용합니다. 일반적인 VLESS 설정은 프로토콜 계층에서 데이터를 암호화하지 않으므로 외부 보안 채널이 필요하고, Trojan은 보통 TLS를 사용해 배포합니다. 보안을 비교할 때는 프로토콜과 외부 보호를 함께 고려해야 합니다. 암호화되지 않은 VLESS와 암호화된 VMess 연결을 그대로 비교해서는 안 됩니다.

VMess의 alterId: 0은 최신 AEAD 구성에서 흔히 사용하는 호환성 필드이며, 암호화가 없다는 뜻은 아닙니다. Shadowsocks도 단순히 ‘SS 지원’만 확인해서는 안 됩니다. 기존 AEAD 방식과 2022 계열은 키 형식과 코어 버전 요구 사항이 다릅니다. 가져온 설정에서 코어가 암호화 방식 이름을 인식하지 못한다면, 표시 이름만 바꿔서는 해결되지 않습니다.

2. 사용 사례별 프로토콜 선택: 서버 조건부터 확인

구독 사용자는 보통 프로토콜을 직접 바꿀 필요가 없습니다. VMess 서버는 클라이언트의 유형을 VLESS로 바꾼다고 연결을 허용하지 않습니다. 직접 서버를 구축한다면 인증서 관리, 포트 개방, 전송 방식 지원, 클라이언트 버전을 함께 고려해야 합니다. 아래 권장 사항은 새 연결을 구성하고 양쪽을 직접 관리하며 해당 설정을 지원하는 경우에 한합니다. 모든 네트워크 환경에서의 속도 순위를 뜻하지는 않습니다.

3. 핸드셰이크 오버헤드와 속도: 항상 가장 빠른 프로토콜은 없습니다

핸드셰이크 오버헤드는 새 연결이 설정되는 시간에 영향을 줍니다. 지속적인 처리량은 회선 대역폭, 패킷 손실, 서버 부하, 단말 성능의 영향을 더 많이 받습니다. TCP 연결 설정, TLS 핸드셰이크, WebSocket의 HTTP Upgrade는 추가 왕복을 일으킬 수 있습니다. 연결 재사용 여부와 TLS 세션 재개 여부에 따라서도 실제 시간이 달라집니다. 따라서 프로토콜마다 고정된 지연 시간을 제시할 수는 없습니다.

일반적인 설정에서 VLESS는 프로토콜 계층의 데이터 암호화를 중복 수행하지 않습니다. 그렇다고 모든 VMess 또는 Shadowsocks 노드보다 반드시 빠른 것은 아닙니다. 노드마다 데이터 센터와 출구가 다르면 결과는 주로 회선 차이를 반영합니다. Vision도 ‘켜면 대역폭이 두 배가 되는’ 기능이 아닙니다. 역할과 적용 조건은 코어 문서와 양쪽 설정을 기준으로 확인해야 합니다.

1. 테스트 조건을 고정하세요. 가능하면 같은 서버, 같은 출구, 같은 테스트 리소스를 사용하세요. 조건을 통제할 수 없다면 결과를 노드 사용 경험 비교에만 활용하고 프로토콜 자체의 차이로 해석하지 마세요.
2. 연결 설정과 다운로드를 따로 측정하세요. 첫 응답 시간을 기록한 뒤 최소 30초 동안 전송을 지속해 평균 속도를 확인하세요. 한 번의 지연 시간 측정만으로 동영상이나 대용량 파일 사용 경험을 판단할 수는 없습니다.
3. 각 조건에서 3회 반복하세요. 중앙값을 사용하고 테스트 시간, 연결 재사용 여부, 백그라운드 다운로드 여부를 기록하세요. 가장 좋은 결과만 남기지 말고 실패 횟수도 기록해야 합니다.
4. 라우팅 조건을 일치시키세요. 테스트 요청이 실제로 측정 대상 아웃바운드를 통과하는지 확인하세요. 특정 테스트에서 직접 연결 규칙이 적용됐다면 측정 속도는 프록시 연결 속도가 아닙니다.

다중화도 별도로 평가해야 합니다. 일부 단기 연결의 오버헤드를 줄일 수 있지만, 적절하지 않은 구성이나 패킷 손실이 있는 환경에서는 연결 간 영향이 커질 수 있습니다. 먼저 클라이언트와 서버의 검증된 설정을 유지하고, 문제가 명확할 때만 별도로 조정하세요. 프로토콜, 다중화, DNS 설정을 한꺼번에 바꾸지 않는 것이 좋습니다.

4. TLS, REALITY, 전송 계층: 서로 대체할 수 없는 설정

TLS는 채널을 보호하고 서버 신원을 확인합니다. WebSocket은 전송을 감싸는 방식이고, REALITY는 Xray에서 제공하는 보안 메커니즘이지 다섯 번째 프록시 프로토콜이 아닙니다. TCP, WebSocket, 보안 계층은 각각 다른 설정 항목입니다. 서버가 TCP + REALITY를 제공한다면 임의로 WebSocket + TLS로 바꿔도 연결될 것이라고 기대해서는 안 됩니다.

• TLS: serverName과 인증서 도메인이 일치하는지 확인하세요. 연결 주소로 IP를 사용하더라도 인증서 검증에는 올바른 서버 이름이 필요합니다. SNI와 WebSocket의 Host는 서로 다른 항목입니다.
• REALITY: 서버 공개 키, shortId, 허용된 serverName, 지문 설정을 확인하세요. 공개 키는 서버 키에 대응하는 값이며 웹사이트 인증서에서 임의로 가져온 문자열이 아닙니다.
• Vision: 일반적으로 사용하는 flow 값은 xtls-rprx-vision입니다. 서버와 전송 방식 조합이 지원하는 경우에만 입력하세요. 모든 VLESS 노드에 일괄 추가하면 안 됩니다.
• WebSocket: 대소문자와 앞쪽 슬래시까지 경로가 정확히 일치해야 합니다. HTTP 404가 표시되거나 핸드셰이크에 실패하면 UUID를 바꾸기 전에 리버스 프록시 전달 설정과 경로부터 확인하세요.

다음은 Xray JSON에서 VLESS + TCP + TLS 아웃바운드를 구성하는 예시입니다. example.net은 문서용 예시 도메인이고 UUID도 예시 값이므로 실제로 연결할 수 있는 노드가 아닙니다. 사용 시에는 서버에서 제공한 주소, 식별 정보, 인증서 도메인을 입력해야 합니다. REALITY 노드에는 이 TLS 설정을 그대로 적용할 수 없습니다.

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "example.net",
            "port": 443,
            "users": [
              {
                "id": "6e7d180b-486c-4f4a-89c4-574ca70b83d2",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "example.net",
          "allowInsecure": false
        }
      }
    }
  ]
}

여기서 outbounds는 아웃바운드만 설명하며 로컬 인바운드와 라우팅 설정은 포함하지 않습니다. v2rayN에서 노드를 관리한다면 노드 편집 화면에서 매개변수를 설정하세요. 클라이언트가 생성한 실행 설정을 직접 덮어쓰면 다음 시작이나 구독 업데이트 때 다시 생성될 수 있습니다. 각 항목의 역할은 JSON 설정 안내서에서 확인하세요.

5. 클라이언트와 코어: 이름이 같아도 지원 조합은 다릅니다

v2rayN은 데스크톱 클라이언트이며, 지원 프로토콜은 실제로 실행하는 코어와 버전에 따라 달라집니다. Android용 v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. Project V, V2Fly, Xray는 기술적 연관성이 있지만 프로젝트마다 설정 항목과 확장 기능이 다릅니다. 특히 REALITY, Vision, 최신 전송 방식은 서로 호환된다고 단정할 수 없습니다.

구독 링크는 노드 설정을 배포하는 수단이지 다섯 번째 프록시 프로토콜이 아닙니다. 가져오기에 성공하더라도 구독 형식을 변환하는 과정에서 일부 확장 항목이 누락될 수 있습니다. ‘같은 노드가 한 클라이언트에서는 작동하지만 다른 클라이언트에서는 작동하지 않는’ 경우에는 프로토콜, 포트, 전송 방식, 보안 계층, SNI, flow, 인증 정보를 차례로 비교한 뒤 코어 기능의 차이인지 판단하세요.

6. 포트, UDP, 라우팅: 연결의 각 단계를 구분하세요

서버 포트, 로컬 프록시 포트, 앱의 대상 포트는 서로 다른 역할을 합니다. 아래 숫자 세 개는 설정 위치를 구분하기 위한 예시일 뿐, 모든 노드의 기본값이나 성능 권장값이 아닙니다. 실제 수신 주소와 포트는 현재 클라이언트 설정을 확인하세요.

서버 포트를 443으로 설정한다고 TLS가 자동으로 활성화되지는 않습니다. 프로토콜 핸드셰이크와 보안 계층도 올바르게 설정해야 합니다. 마찬가지로 브라우저가 로컬 SOCKS 포트에 접속하는 단계와 클라이언트가 원격 서버의 443 포트에 연결하는 단계는 서로 다릅니다. 시스템 프록시는 해당 설정을 따르는 앱에만 영향을 주며, 모든 트래픽이 프록시를 통과한다는 뜻은 아닙니다.

• 웹은 되지만 실시간 앱이 작동하지 않음: 앱이 프록시를 사용하는지, 클라이언트 인바운드와 원격 아웃바운드, 방화벽에서 UDP를 모두 허용하는지 확인하세요.
• 도메인은 연결되지 않지만 일부 IP에는 연결됨: 프로토콜이 불안정하다고 단정하기 전에 DNS 요청 경로, 조회 결과, 라우팅 규칙을 확인하세요.
• 일부 사이트에서 로컬 출구로 표시됨: 직접 연결 규칙이 적용됐는지 확인하세요. VMess를 VLESS로 바꿔도 라우팅 정책은 자동으로 바뀌지 않습니다.

7. 자주 묻는 질문: 가져온 뒤 연결 문제 해결하기