왜 지금 Hysteria2인가

국제 회선이 불안정하거나 공유기·캠퍼스망처럼 버퍼블로트와 간헐적 손실이 잦은 환경에서는, 전통적인 TCP 기반 프록시가 한계에 부딪히는 경우가 있습니다. 연결은 붙었는데 속도가 들쭉날쭉하거나, 짧은 웹 요청만 반복해도 체감 지연이 커지는 현상은 흔합니다. Hysteria2는 이런 「나쁜 링크」를 전제로 설계된 계열로, QUIC과 현대적인 혼잡 제어 아이디어를 바탕으로 높은 처리량과 비교적 낮은 왕복 지연을 노립니다.

Mihomo(Clash Meta)는 별도 바이너리 없이 type: hysteria2 노드를 네이티브로 파싱합니다. 즉, GUI만 최신 코어를 따라가면 설정 파일 한 블록으로 바로 실험할 수 있다는 뜻입니다. 이 글은 특정 상용 서비스의 배포 스크립트를 따라 하게 만드는 문서가 아니라, 클라이언트 측에서 값을 정확히 맞추고 규칙까지 일관되게 묶는 방법에 초점을 맞춥니다. 법규·운영 정책은 지역마다 다르므로 합법적인 용도와 본인 책임 하에서만 활용하시기 바랍니다.

DNS·규칙 기초를 함께 다듬고 싶다면 Clash 사용 문서에서 fake-ip·DoH 흐름을 먼저 익히는 것을 권장합니다.

QUIC과 Hysteria2가 주는 체감 차이

QUIC은 TCP 위에 TLS를 얹는 방식과 달리, 전송과 암호화 핸드셰이크를 한층 단순한 경로로 묶는 편이라 연결 수립 지연이 상대적으로 짧습니다. 또한 스트림 단위로 손실을 격리하므로, 한 요청이 막혀도 다른 요청이 전부 멈추지 않는 구조가 기본에 가깝습니다. Hysteria2는 이런 QUIC의 장점을 살리면서, 클라이언트가 알려 주는 상·하향 대역폭 힌트를 혼잡 제어에 반영해 과도한 버퍼링이나 반대로 너무 소극적인 전송을 줄이려 합니다.

다만 「무조건 가장 빠르다」는 뜻은 아닙니다. 회선이 매우 깨끗하고 RTT가 낮다면 잘 튜닝된 TCP 경로가 더 나을 수도 있고, 일부 네트워크는 UDP 자체를 제한해 QUIC이 아예 막히기도 합니다. 그래서 Reality·TUIC 등과 병행해 두고 url-test·fallback으로 자동 전환하는 구성이 실전에서는 더 안전합니다.

설정 전에 확인할 것

1. 코어와 GUI 버전

Hysteria2는 비교적 최근 계열의 타입입니다. 오래된 Clash 코어에는 해당 파서가 없을 수 있으니, 앱 정보 화면에서 Mihomo 버전을 확인하고 필요하면 다운로드 페이지에서 검증된 패키지로 올리세요.

2. 서비스 제공자가 준 값

최소한 다음이 정확해야 연결이 성립합니다.

  • 서버 호스트명 또는 IP, 포트(대개 443)
  • 인증용 password(또는 제공자가 명명한 동일 역할의 비밀값)
  • TLS 검증에 쓰이는 SNI 또는 인증서 호스트 정보
  • 선택: obfs 종류와 obfs용 비밀번호
  • 선택: 커스텀 CA, ALPN 목록 등

3. 시간·DNS·UDP

시스템 시각이 크게 틀어지면 TLS 계열 전반이 불안정해집니다. 서버 도메인이 잘못 해석되면 타임아웃이 납니다. 모바일 데이터나 사내망에서 QUIC(UDP)이 막혀 있으면 아무리 설정이 맞아도 붙지 않으니, 가능하면 다른 회선에서도 한 번씩 대조 테스트하세요.

Mihomo proxies 기본 예시

아래는 config.yaml의 proxies에 넣을 수 있는 참고용 스켈레톤입니다. 값은 반드시 본인 구독·서버 정보로 바꿔야 합니다.

proxies:
  - name: "HY2-Example"
    type: hysteria2
    server: your-server.example.com
    port: 443
    password: "your-password"
    sni: your-server.example.com
    skip-cert-verify: false
    udp: true
    alpn:
      - h3
    up: "100 Mbps"
    down: "200 Mbps"

udp: true는 음성·게임 등 UDP가 필요한 앱에 유리하지만, 제공자 정책과 맞지 않으면 끄거나 안내에 따르세요. skip-cert-verify: false가 기본 권장입니다. 불필요하게 검증을 끄면 중간자 공격 위험이 커집니다.

up / down 대역폭 힌트를 현실적으로 맞추기

up과 down은 실제 물리 대역폭을 「강제」하는 값이 아니라, 클라이언트가 자신의 회선 용량을 서버 쪽 알고리즘에 알려 주는 힌트에 가깝습니다. 너무 과장되게 쓰면 버퍼가 불필요하게 쌓이고, 너무 낮게 쓰면 처리량이 인위적으로 제한될 수 있습니다.

실무에서는 인터넷 속도 측정 사이트로 대략적인 상·하향을 잰 뒤, 그보다 약간 보수적인 값을 넣고 지연·처리량을 보면서 조정하는 방식이 무난합니다. Wi-Fi와 유선을 오가며 쓴다면 더 낮은 쪽 기준에 맞추거나, 별도 프로필을 두는 것도 방법입니다.

참고: 단위 문자열(Mbps 등) 표기는 코어 버전에 따라 허용 형식이 조금씩 다를 수 있습니다. 파싱 오류가 나면 Mihomo 릴리스 노트와 예시를 대조하세요.

TLS, SNI, obfs(살라만더 등)

많은 배포에서 sni는 서버 인증서가 발급된 호스트와 맞아야 합니다. 제공자가 별도의 위장 도메인을 지정했다면 그 값을 그대로 쓰고, 임의로 유명 도메인으로 바꾸지 마세요. alpn에 h3를 넣는 예시가 흔하지만, 서버가 HTTP/3 협상을 기대하지 않는 구성이라면 제거해야 할 수도 있습니다.

일부 서버는 QUIC 페이로드에 간단한 난독화 계층을 추가합니다. Mihomo에서는 obfs·obfs-password 같은 필드로 이를 표현하는 경우가 있습니다. 서버 측과 정확히 같은 obfs 모드·비밀값이어야 하며, 한쪽만 켜 두면 연결이 즉시 실패합니다.

proxies:
  - name: "HY2-Obfs"
    type: hysteria2
    server: your-server.example.com
    port: 443
    password: "your-password"
    sni: your-server.example.com
    obfs: salamander
    obfs-password: "your-obfs-secret"
    up: "50 Mbps"
    down: "150 Mbps"

프록시 그룹과 규칙에 편입하기

노드만 만들고 끝내면 트래픽이 전혀 타지 않습니다. proxy-groups에 HY2 노드를 멤버로 넣고, rules에서 목적지에 따라 그룹을 선택하세요. 대역폭이 중요한 대용량 다운로드와, 지연이 민감한 화상 회의를 서로 다른 그룹으로 나누면 튜닝이 쉬워집니다.

proxy-groups:
  - name: "Auto"
    type: url-test
    proxies:
      - HY2-Example
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300

rules:
  - DOMAIN-SUFFIX,google.com,Auto
  - MATCH,DIRECT

위는 최소 예시입니다. 실제 프로필에서는 GEOIP·geosite·rule-providers를 함께 쓰는 경우가 많습니다. 규칙 세트가 길어질수록 DNS와의 정합성이 중요해지므로, 문서의 DNS 섹션과 맞춰 보는 것이 좋습니다.

구독 링크로 받은 경우

GUI에서 구독만 추가하면 HY2 노드가 자동으로 채워지는 경우가 많습니다. 그런데 「지원하지 않는 타입」으로 뜨거나 필드가 비어 있으면 다음을 순서대로 점검하세요.

  1. 앱과 코어를 최신으로 올린다.
  2. 구독을 새로 고침하고, 해당 노드의 원시 설정이 Mihomo 문법과 맞는지 확인한다.
  3. 필요하면 proxies에 수동으로 블록을 넣어 필드명 오타·누락을 제거한다.

코어 변경 이력과 타입 정의는 Mihomo GitHub 저장소에서 확인할 수 있습니다. 실행 파일·GUI 패키지는 신뢰할 수 있는 빌드를 사이트 다운로드 페이지에서 받는 편이 버전 관리에 유리한 경우가 많습니다.

연결이 불안정할 때 점검 순서

  • 비밀번호·obfs 문자열 오타: 복사 시 앞뒤 공백, 잘린 줄이 없는지 다시 붙여 넣습니다.
  • SNI·포트 불일치: 서버가 기대하는 호스트명과 다른 SNI를 쓰면 인증서 오류나 조용한 차단이 납니다.
  • UDP 차단: 사내망·일부 이통사 NAT에서 QUIC이 막히면 TCP 기반 노드로만 전환됩니다.
  • MTU·분할 터널: VPN·다른 TUN 앱과 동시에 켜 두면 패킷이 조각나며 실패하는 사례가 있습니다.
  • 대역폭 힌트 과대·과소: 체감이 이상하면 up/down을 현실 값 근처로 조정해 봅니다.
주의: 동일 노드에 짧은 시간에 과도한 재시도를 걸면 일부 네트워크에서 이상 트래픽으로 분류될 수 있습니다. 테스트는 필요한 최소 횟수로 나누세요.

TCP 기반 노드·다른 QUIC 계열과의 역할 나누기

HY2는 손실이 큰 링크에서 강점을 내는 편이지만, 검열 회피나 TLS 지문 위장만 놓고 보면 VLESS+Reality 같은 조합이 더 적합한 환경도 있습니다. 반대로 RTT가 낮고 링크가 매우 깨끗하면 잘 튜닝된 전통 TCP도 충분히 빠릅니다.

실사용 구성에서는 HY2·TUIC·Reality·Shadowsocks 등을 한 그룹에 넣고 url-test나 fallback으로 자동 선택하게 하거나, 규칙으로 앱별·도메인별로 갈라 보내는 방식이 흔합니다. 한 가지 프로토콜에만 의존하기보다 2~3가지 경로를 폴백해 두는 편이 장애 대응에 유리합니다.

보안과 운영 습관

프로토콜이 아무리 최신이어도, 신뢰할 수 없는 구독을 그대로 불러오거나 오래된 클라이언트를 쓰면 의미가 반감됩니다. 공식·검증된 GUI를 사용하고, 구독 URL을 공개 채팅에 올리지 않으며, 가능하면 비밀번호를 주기적으로 교체하세요. 공용 Wi-Fi에서는 금융 거래를 피하고, 기기 OS 업데이트와 악성코드 점검을 병행하는 것이 좋습니다.

정리 및 Clash 클라이언트 선택

Hysteria2는 QUIC의 이점을 살려 열악한 회선에서도 사용 가능한 처리량과 응답성을 노리는 현실적인 선택지입니다. 다만 UDP 제한·SNI·대역폭 힌트·obfs 일치 같은 변수가 많으므로, 값을 하나씩 검증하고 DNS·규칙까지 함께 맞추는 것이 성공 확률을 가장 크게 올립니다.

직접 코어를 빌드하거나 여러 포크를 오가며 맞추는 대신, 검증된 GUI와 코어가 묶인 배포본을 쓰면 파싱 오류와 버전 괴리를 줄일 수 있습니다. 특히 HY2처럼 필드가 늘어난 타입은 최신 Mihomo 계열이 규칙·구독·DNS를 한 파일에서 다루는 이점이 큽니다.

HY2 노드가 계속 실패 아이콘으로만 표시된다면, 다운로드 페이지에서 운영체제에 맞는 최신 Clash 패키지를 받아 코어를 맞춰 보세요. 같은 서버 정보라도 파서·버전 차이로 성공 여부가 갈리는 경우가 흔합니다.

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