VLESS + Reality가 주목받는 이유

프록시 프로토콜은 빠르기만큼이나 「겉으로 어떤 트래픽처럼 보이는가」가 중요해졌습니다. 전통적인 TLS 기반 프록시도 암호화는 강하지만, 지문·핸드셰이크 패턴이 반복되면 통신 특성만으로 분류될 여지가 있습니다. VLESS는 가벼운 전송 계층 설계로 유명하고, 여기에 Reality(실리티)를 얹으면 실제로 접속 가능한 웹사이트의 TLS 세션과 유사한 형태를 참조해 연결을 마무리할 수 있어, 많은 사용자가 「난독화와 은닉을 동시에 노리는 조합」으로 평가합니다.

이 글은 특정 서버 소프트웨어 설치법을 단계별로 따라 하게 만드는 문서가 아니라, 클라이언트(Mihomo·Clash Meta 계열)에서 노드를 올바르게 이해하고 붙이는 데 필요한 지식에 초점을 맞춥니다. 운영 정책·법규는 국가와 네트워크 환경마다 다르므로, 본인의 책임 하에 합법적인 용도로만 활용하시기 바랍니다.

Clash 규칙·DNS 기초를 함께 보고 싶다면 Clash 사용 문서를 먼저 훑어보는 것을 권장합니다.

VLESS란 무엇인가

VLESS는 인증 정보로 주로 UUID를 쓰는 경량 프로토콜입니다. 예전 VMess 계열과 비교해 헤더가 단순하고, TLS·XTLS 같은 외부 계층과 조합해 실제 전송을 보호하는 방식이 일반적입니다. 클라이언트 설정에서는 type: vless로 선언하고, 서버 주소·포트·UUID·전송 방식(tcp, grpc 등)·TLS 사용 여부를 맞춰 주면 됩니다.

「빠르다」는 인상은 프로토콜 자체보다 XTLS 같은 경로 최적화와 서버·회선 품질에 더 크게 좌우됩니다. 그중에서도 flow: xtls-rprx-vision은 TLS 내부에서 불필요한 이중 암호화를 줄이려는 흐름으로 널리 쓰이며, Reality와 함께 구성하는 사례가 많습니다.

Reality(실리티)의 핵심 아이디어

Reality는 한마디로 「실제로 존재하는 사이트의 TLS 지문을 참조해, 우리 연결이 마치 그 사이트와 통신하는 것처럼 보이게 만드는 메커니즘」에 가깝습니다. 서버가 해당 도메인의 인증서를 직접 소유하지 않아도, 미리 정해 둔 공개 키와 short-id 등으로 클라이언트와 합의된 Reality 핸드셰이크를 완성합니다.

클라이언트 설정에서 자주 등장하는 servername(또는 SNI에 해당하는 값)은 「어떤 대형 사이트의 TLS 프로필을 빌려올지」를 가리키는 경우가 많습니다. 다만 너무 눈에 띄이거나 차단된 도메인을 고르면 오히려 불리할 수 있으므로, 운영자가 안내하는 값을 그대로 쓰고 임의로 바꾸지 않는 것이 안전합니다.

참고: Reality는 만능이 아닙니다. 지역·회선·검열 장비의 버전에 따라 체감이 크게 달라질 수 있으며, 항상 대체 노드나 프로토콜을 준비해 두는 편이 현실적입니다.

설정 전에 확인할 것

1. 클라이언트 코어 버전

VLESS·Reality·XTLS Vision 조합은 최신 Mihomo(Clash Meta) 코어에서 안정적으로 다루는 경우가 많습니다. GUI를 쓴다면 앱 정보 화면에서 코어 버전을 확인하고, 오래된 빌드라면 다운로드 페이지에서 검증된 패키지로 올리는 것이 좋습니다.

2. 서버에서 받은 정확한 값

다음 항목은 한 글자라도 어긋나면 연결이 바로 실패합니다.

  • 서버 호스트명 또는 IP, 포트(대개 443)
  • UUID
  • servername(위장에 쓰는 SNI로 안내되는 도메인)
  • public-key와 short-id
  • 필요 시 flow 지정 여부(vision 등)

3. 네트워크·시간 동기화

TLS 계열은 시스템 시간이 크게 어긋나면 실패하기 쉽습니다. 또한 일부 캡티브 포털 Wi-Fi에서는 UDP·특정 포트가 막혀 있을 수 있으니, 가능하면 다른 회선에서도 한 번씩 테스트해 보세요.

Mihomo(Clash Meta) 설정 예시

아래는 config.yaml의 proxies 블록에 넣을 수 있는 참고용 예시입니다. 값은 반드시 본인의 서비스 제공자가 준 정보로 바꿔야 합니다.

proxies:
  - name: "VLESS-Reality"
    type: vless
    server: your-server.example.com
    port: 443
    uuid: "your-uuid-here"
    network: tcp
    tls: true
    udp: true
    flow: xtls-rprx-vision
    servername: www.microsoft.com
    reality-opts:
      public-key: "your-public-key-base64"
      short-id: "your-short-id"

flow: xtls-rprx-vision은 XTLS Vision 경로를 켭니다. 제공자가 flow 없이 쓰라고 했다면 해당 줄을 제거하거나 안내에 맞게 조정합니다. udp: true는 음성·게임 등 UDP가 필요한 앱에 유리하지만, 서버 정책과 맞지 않으면 꺼야 할 때도 있습니다.

노드를 만든 뒤에는 proxy-groups에 편입하고, rules에서 어떤 트래픽이 이 노드를 탈지 정합니다. 규칙 작성이 낯설다면 문서의 기본 템플릿을 복사한 뒤 조금씩 고쳐 나가는 방식이 실수가 적습니다.

필드별로 읽는 법

servername

클라이언트가 SNI로 보내는 값으로, Reality에서 참조하는 「겉모습」과 맞물립니다. 임의로 유명 도메인을 바꾸면 서버 설정과 불일치해 실패하므로, 반드시 제공된 값을 사용합니다.

reality-opts.public-key

서버의 Reality 공개 키입니다. Base64 문자열이 한 줄로 들어가며, 공백이나 줄 바꿈이 섞이지 않게 붙여 넣습니다.

reality-opts.short-id

짧은 식별자로, 서버 구성에 여러 개가 있을 수 있습니다. 안내 받은 것 중 하나를 그대로 선택하면 됩니다.

tls · skip-cert-verify

Reality 경로에서는 일반적인 인증서 검증과 다른 흐름이 섞이므로, 클라이언트가 skip-cert-verify를 요구하는 프리셋이 있더라도 보안과 호환성 측면에서 제공자 문서를 우선하십시오. 불필요하게 검증을 끄면 중간자 공격 위험이 커질 수 있습니다.

구독 링크로 받은 경우

많은 GUI 클라이언트는 구독 URL만 넣으면 자동으로 노드 목록을 채웁니다. 이때 Reality 관련 필드가 누락되거나 오래된 파서가 실패하면 「지원하지 않는 타입」으로 뜰 수 있습니다. 대처 순서는 다음과 같습니다.

  1. 앱과 코어를 최신으로 올린다.
  2. 구독을 새로 고침하고, 해당 노드의 원시 JSON/YAML이 클라이언트에 맞는지 확인한다.
  3. 그래도 실패하면 proxies에 수동으로 위 예시 형태를 넣어 필드명 오타를 제거한다.

구독 포맷은 서비스마다 조금씩 다르므로, 공개된 Mihomo 문법과 비교해 보는 것이 빠릅니다. 코어 변경 이력은 Mihomo GitHub 저장소에서 확인할 수 있으며, 실행 파일은 사이트 다운로드 페이지를 통해 받는 편이 버전 관리에 유리한 경우가 많습니다.

연결이 안 될 때 점검 순서

아래는 현장에서 자주 걸리는 원인입니다. 위에서 아래로 차례로 확인해 보세요.

  • UUID·short-id·공개 키 오타: 복사 시 앞뒤 공백, 잘린 문자열이 없는지 다시 붙여 넣습니다.
  • 포트·방화벽: 로컬 방화벽이나 회사 보안 에이전트가 아웃바운드 443을 가로막는지 확인합니다.
  • DNS: 서버 도메인이 잘못 해석되면 타임아웃이 납니다. nslookup이나 GUI 내 DNS 설정을 점검합니다.
  • flow 불일치: 서버가 Vision을 요구하는데 빠졌거나, 반대로 일반 TLS만 허용하는데 Vision을 강제한 경우입니다.
  • 다른 앱 점유: 동일 포트에서 로컬 프록시가 충돌하면 루프가 납니다. 시스템 프록시·TUN 설정을 정리합니다.
주의: 같은 설정을 여러 기기에서 짧은 시간에 과도하게 시도하면 일부 네트워크에서 일시 차단으로 보일 수 있습니다. 테스트는 필요한 최소 횟수로 나누는 것이 좋습니다.

다른 프로토콜과의 역할 분담

Reality는 은닉 측면에서 강점이 있지만, 항상 최고 속도를 보장하지는 않습니다. 회선이 불안정하고 대역폭이 필요하면 Hysteria2나 TUIC 같은 QUIC 계열이 더 나은 경우도 있습니다. Mihomo에서는 여러 노드를 그룹으로 묶고, 지연 테스트·폴백 규칙으로 자동 전환을 걸어 두면 일상 사용이 훨씬 편해집니다.

한 가지 프로토콜만 고집하기보다, 용도별로 2~3가지를 병행하는 구성이 장애 대응에 유리합니다. Reality는 「차단 회피가 급선무인 구간」에 두고, 국내 직통이나 대역폭이 중요한 다운로드는 DIRECT나 다른 노드로 보내는 식의 규칙 분리가 흔합니다.

보안 습관

프로토콜이 아무리 강해도, 기기 자체가 악성코드에 감염되거나 신뢰할 수 없는 구독을 그대로 불러오면 의미가 없어집니다. 공식·검증된 클라이언트를 쓰고, 구독 URL을 남에게 노출하지 않으며, 가능하면 정기적으로 UUID를 교체하는 습관을 권장합니다. 공용 Wi-Fi에서는 VPN·프록시와 무관하게 HTTPS 사이트 위주로 이용하고, 금융 거래는 신뢰 회선에서 처리하세요.

정리 및 Clash 클라이언트 선택

VLESS + Reality는 TLS 지문 측면에서 우아한 우회 전략을 제공하지만, 정확한 매개변수와 최신 코어 없이는 쉽게 실패합니다. 이 글의 순서대로 필드를 검증하고, 규칙·DNS까지 한 번에 맞추면 재현성이 크게 올라갑니다.

직접 코어를 빌드하거나 여러 저장소를 오가며 패치를 맞추는 대신, 검증된 GUI와 코어가 묶인 배포본을 쓰면 설정 오타와 버전 괴리를 줄일 수 있습니다. 특히 Reality처럼 필드가 많은 노드는 파서 호환이 생명이므로, 다른 도구에 비해 Mihomo 계열이 규칙·구독·DNS를 한 파일에서 일관되게 다루는 장점이 여전히 큽니다.

지금 쓰는 앱에서 Reality 노드가 계속 빨간색으로만 표시된다면, 다운로드 페이지에서 운영체제에 맞는 최신 Clash 패키지를 받아 보세요. 설정 흐름이 단순해지면 같은 노드라도 연결 성공률이 달라지는 경우가 흔합니다.

→ Clash를 무료로 내려받고, 안정적인 Reality 노드 연결을 직접 확인해 보세요