프록시 서버
프록시 서버는 요청을 상위 프록시로 전달합니다. Chute는 HTTP/HTTPS/SOCKS5/SOCKS5-TLS/SS/SSR/Trojan/VMess/VLESS/AnyTLS/TUIC/Hysteria2/WireGuard/AmneziaWG/ShadowTLS/MASQUE/SSH 프록시 프로토콜을 지원합니다.
[Proxy] 섹션은 프록시 서버를 선언합니다. 다양한 규칙에 대해 여러 프록시 서버를 생성할 수 있습니다.
예:
[Proxy]
ProxyHTTP = http, 1.2.3.4, 443, username, password
ProxyHTTPS = https, 1.2.3.4, 443, username, password, sni=example.com
ProxySOCKS5 = socks5, 1.2.3.4, 443, username, password
ProxySOCKS5TLS = socks5-tls, 1.2.3.4, 443, username, password, sni=example.com
SS = ss, 1.2.3.4, 443, method, password, obfs=http
SSR = ssr, 1.2.3.4, 443, method, password, protocol=auth_chain_f, protocol_param=user:pass, obfs=http_post, obfs_param=example.com
Trojan = trojan, 1.2.3.4, 443, password=password, tls=true, sni=example.com, skip-cert-verify=false, ws=true
VMess = vmess, 1.2.3.4, 443, uuid=uuid, sni=example.com, tls=true, ws=true
VLESS = vless, 1.2.3.4, 443, uuid=uuid, sni=example.com, xtls=true
AnyTLS = anytls, 1.2.3.4, 443, password, sni=example.com
TUIC = tuic, 1.2.3.4, 443, uuid=uuid, password=password, sni=example.com
Hysteria2 = hysteria2, 1.2.3.4, 443, auth=password, sni=example.com, up=10, down=100
WireGuard = wireguard, private-key=base64key, peer-public-key=base64key, section-name=wg0, self-ip=10.0.0.2
AmneziaWG = amneziawg, section-name=awg0
ShadowTLS = shadowtls, 1.2.3.4, 443, password=password, sni=example.com, skip-cert-verify=false, fingerprint=chrome
ProxyMASQUE = masque, 1.2.3.4, 443, token=auth-token, mode=connect-udp, sni=example.com, alpn=h3, skip-cert-verify=false
SSH = ssh, 1.2.3.4, 22, root, password=pw
SCHEME = scheme, ssr://....
주의: Trojan 정책에는 명시적인
tls=true가 필요합니다 — TLS가 암묵적으로 적용되지 않습니다. 이것이 없으면(그리고 언제나 TLS 위에서 동작하는grpc=true도 없으면) 정책은 평문으로 연결하며, 구성을 로드할 때 로그에 그 사실이 남습니다:Trojan policy <name> has no tls=true; it connects without TLS. Clash/mihomo 프로필을 가져오면 모든 Trojan 노드에tls=true가 기록됩니다.주의:
scheme은 다음 종류의 공유 링크를 받습니다:ss://,ssr://,anytls://,tuic://,hysteria2://,shadowtls://. 그 밖의 종류의 링크를 쓰면 그 줄은 구성 오류가 됩니다.
매개변수
| 유형 | 사용자 이름 | 비밀번호 | 메서드 | TLS | XTLS | WebSocket | QUIC |
|---|---|---|---|---|---|---|---|
| HTTP | √ | √ | |||||
| HTTPS | √ | √ | TLS | ||||
| Socks | √ | √ | |||||
| SOCKS5-TLS | √ | √ | TLS | ||||
| Shadowsocks | √ | 메서드, OBFS | TLS, 지문, ECH | WS | |||
| ShadowsocksR | √ | 메서드, 프로토콜, OBFS | TLS, 지문, ECH | WS | |||
| Trojan | √ | TLS, 지문, ECH | WS, gRPC, XHTTP | ||||
| VMess | uuid | TLS, 지문, ECH | WS, gRPC, XHTTP | ||||
| VLESS | uuid | TLS, 지문, ECH | XTLS | WS, gRPC, XHTTP | |||
| AnyTLS | √ | TLS | |||||
| TUIC | uuid | √ | TLS | √ | |||
| Hysteria2 | auth | TLS | √ | ||||
| WireGuard | private-key | 네이티브 WireGuard | |||||
| AmneziaWG | private-key | 네이티브 WireGuard | |||||
| ShadowTLS | √ | TLS, 지문 | |||||
| MASQUE | token | TLS, 모드, 멀티플렉싱 | √ | ||||
| SSH | √ | 인증 | |
TLS 프록시 매개변수
tls: 선택.
tls=true
TLS 전송을 활성화합니다.
skip-cert-verify: 선택
skip-cert-verify=true
이 옵션을 활성화하면 Chute는 서버의 인증서를 확인하지 않습니다. true, 1, yes 모두 이 옵션을 켜므로, insecure=1로 쓰인 공유 링크도 동작합니다. Shadowrocket이 socks5-tls 줄에 쓰는 skip-common-name-verify=true도 같은 옵션으로 읽힙니다.
sni (기본값: 호스트명)
sni=exmaple.com
TLS 핸드셰이크 중 서버 이름 표시(SNI)를 사용자 정의할 수 있습니다. 기본적으로 Chute는 대부분의 브라우저처럼 호스트명을 SNI로 보냅니다.
fingerprint: 선택.
fingerprint=chrome
시스템 기본값 대신 브라우저의 TLS ClientHello를 보내어 핸드셰이크가 프록시
클라이언트의 것으로 눈에 띄지 않도록 합니다. 사용할 수 있는 값은 chrome,
firefox, safari, ios 그리고 edge, 360, qq, android, random이며
뒤의 값들은 모두 Chrome으로 처리됩니다. mihomo, sing-box, Xray가 쓰는 이름도 받아들여
이 네 가지 프리셋에 대응시킵니다: 예를 들어 randomized, chrome_pq, hellochrome_131은
Chrome, hellofirefox_120은 Firefox, hellosafari_16_0은 Safari, helloios_14는 iOS로
처리됩니다. Xray의 hellogolang에는 대응하는 프리셋이 없습니다.
TLS를 사용하는 Trojan, VMess, VLESS에 적용되며 WebSocket 및 gRPC 전송도
포함합니다. WebSocket과 TLS를 사용하는
Shadowsocks와 ShadowsocksR에도 적용됩니다. REALITY와 ShadowTLS는 각자의 섹션에
같은 이름의 옵션이 있습니다. 개별 지정이 없는 모든 정책에 하나의 지문을 적용하려면
global-client-fingerprint를
사용하세요. 이 설정은 ShadowTLS 정책에는 항상 적용되고, VLESS 정책에는 tls=true나
reality=true를, Trojan과 VMess 정책에는 tls=true를, Shadowsocks 정책에는 ws=true와
tls=true를 모두 설정했을 때 적용됩니다. gRPC 전송을 쓰는 정책도 tls=true를 써야 합니다.
ShadowsocksR 정책에는 적용되지 않습니다.
이 프로토콜들에서 fingerprint=none은(unsafe도 같은 뜻입니다) 시스템 TLS 스택을 선택하며,
global-client-fingerprint보다 우선합니다. REALITY와 ShadowTLS는 브라우저식 핸드셰이크 없이는
동작하지 않으므로 거기서는 none도 연결을 거부하게 합니다. Chute가 인식하지 못하는 값은 어느
프로토콜에서든 시스템 TLS로 돌아가지 않고 그 정책의 연결을 거부하게 합니다: 서버에는 아무것도
보내지 않고, 연결은 실패로 끝나며(url-test나 fallback 그룹은 다른 실패와 똑같이 셉니다), 구성을 로드할 때 로그에
Policy <name>: fingerprint '<value>' is not supported; connections through this policy are refused가
남습니다. 반면 인식하지 못하는 global-client-fingerprint는 무시될 뿐입니다.
지문을 설정하면 양자 내성 키 교환도 함께 켜집니다. Chute는 X25519와 더불어 X25519MLKEM768 하이브리드 그룹을 제시하므로, 오늘 기록된 세션을 훗날 양자 컴퓨터를 손에 넣은 공격자가 복호화할 수 없습니다. 이 그룹을 모르는 서버는 그냥 X25519를 고르므로 문제가 생기지 않습니다. 지문을 설정하지 않으면 시스템 TLS 스택을 사용하며 이 그룹은 제시되지 않습니다 — ECH에 지문이 필요한 것과 같은 이유입니다.
Shadowsocks 프록시 매개변수
method: 필수.
현재 지원:
rc4-md5
aes-128-cfb
aes-192-cfb
aes-256-cfb
aes-128-ctr
aes-192-ctr
aes-256-ctr
bf-cfb
camellia-128-cfb
camellia-192-cfb
camellia-256-cfb
salsa20
chacha20
chacha20-ietf
aes-128-gcm
aes-192-gcm
aes-256-gcm
chacha20-ietf-poly1305
xchacha20-ietf-poly1305
Shadowsocks 2022 메서드
Chute는 BLAKE3 기반 키 파생 및 AEAD 암호를 사용하는 Shadowsocks 2022 프로토콜을 지원합니다. 메서드 이름이 암호 스위트를 결정합니다:
2022-blake3-aes-128-gcm
2022-blake3-aes-256-gcm
2022-blake3-chacha20-poly1305
비밀번호 형식:
SS2022의 비밀번호 필드는 :(콜론)으로 구분된 하나 또는 두 개의 base64 인코딩 키로 구성됩니다.
단일 사용자 모드 (키 1개):
SS2022 = ss, 1.2.3.4, 443, 2022-blake3-aes-256-gcm, "base64-key"
ID 헤더가 있는 다중 사용자 모드 (키 2개):
2022-blake3-aes-128-gcm 및 2022-blake3-aes-256-gcm의 경우, :으로 구분하여 ID 헤더 키와 사용자 키를 제공할 수 있습니다:
SS2022 = ss, 1.2.3.4, 443, 2022-blake3-aes-256-gcm, "header-base64-key:user-base64-key"
각 키는 base64로 인코딩된 문자열입니다(표준 및 URL-safe base64 모두 지원). 필요한 키 길이:
| 메서드 | 사용자 키 길이 | 헤더 키 길이 |
|---|---|---|
2022-blake3-aes-128-gcm |
16바이트 | 16바이트 |
2022-blake3-aes-256-gcm |
32바이트 | 32바이트 |
2022-blake3-chacha20-poly1305 |
32바이트 | N/A (ID 헤더 지원 없음) |
키 생성:
openssl rand -base64 32
참고: SS2022 메서드는
obfs매개변수를 지원하지 않습니다.2022-blake3-chacha20-poly1305메서드는 다중 사용자 모드를 지원하지 않습니다.
Shadowsocks AEGIS 메서드
Chute는 AEGIS 계열 AEAD 암호도 지원합니다. AES 라운드 함수 위에 구축되어 있으며, 하드웨어 AES를 갖춘 프로세서(최근의 iPhone, iPad, Apple TV, Mac이 모두 해당)에서는 AES-GCM이나 ChaCha20-Poly1305보다 뚜렷하게 빠릅니다:
aegis-128l
aegis-256
설정 방법은 위의 기존 AEAD 메서드와 같으며, 비밀번호는 base64 키가 아닌 일반 암호구입니다:
AEGIS = ss, 1.2.3.4, 443, aegis-128l, your-password
| 메서드 | 키 | Nonce | 인증 태그 |
|---|---|---|---|
aegis-128l |
16바이트 | 16바이트 | 16바이트 |
aegis-256 |
32바이트 | 32바이트 | 16바이트 |
나머지는 모두 SIP004를 그대로 따릅니다: salt는 키와 길이가 같고, 세션 서브키는 HKDF-SHA1(key, salt, "ss-subkey")이며, TCP 페이로드는 길이 접두사가 붙은 AEAD 청크로 전달되고 각 연산 후 nonce가 증가하며, UDP는 전부 0인 nonce를 사용합니다.
서버는 직접 운영해야 합니다. AEGIS는 Shadowsocks 사양의 일부가 아닙니다. 이를 정의하는 SIP가 없으며, shadowsocks-rust, shadowsocks-libev, shadowsocks-go, sing-box, Xray를 포함한 주요 Shadowsocks 서버 중 어느 것도 구현하지 않았습니다. 이 메서드를 선택해도 이를 지원하도록 구축된 본인 소유의 서버에 대해서만 연결됩니다. 상용 또는 공유 노드에 연결하는 경우에는 위의 상호 운용 가능한 메서드를 사용하세요.
obfs: 선택.
현재 지원:
tls
http
obfs_param: 선택.
obfs_param=example.com
obfs 계층이 사용하는 Host를 설정합니다. 설정하지 않으면 기본값은 cloudfront.net입니다.
WebSocket(v2ray-plugin): 선택.
ws=true, ws-path=/path, ws-headers=Host:example.com, tls=true, sni=example.com, skip-cert-verify=false
v2ray-plugin의 websocket 모드와 같은 방식으로 Shadowsocks 스트림을 WebSocket 안에 실어 나릅니다. 그래서 v2ray-plugin 뒤에서 동작하는 Shadowsocks 서버에, 앞에 CDN이 있는 경우까지 포함해 연결할 수 있습니다. 사용하는 옵션은 WebSocket 전송과 TLS의 옵션입니다. Shadowsocks 2022 메서드도 이 위에서 동작하며, ShadowsocksR 정책도 자체 프로토콜과 obfs를 유지한 채 같은 옵션을 받습니다.
ws-path의 기본값은/이며, 앞의 슬래시 없이 쓴 경로에는 슬래시가 붙습니다.- 업그레이드 요청의
Host로는ws-headers에 있는 Host를 쓴 그대로 사용합니다. 없으면sni(sni가 없으면 서버 주소)에:<port>를 붙인 값입니다. tls=true는 WebSocket 아래에서 TLS를 실행합니다.sni,skip-cert-verify, fingerprint, ECH 옵션은 Trojan에서와 같이 동작합니다.ws=true가 없으면tls=true는 아무 일도 하지 않습니다: 정책은 TLS 없이 연결하고, 그 줄에는 권고Shadowsocks tls=true only applies with ws=true (the v2ray-plugin transport); this policy connects without TLS가 붙습니다.ws-mux(기본값true)는 각 WebSocket에 mux.cool 세션을 하나 엽니다. 이것은 기본값mux=1로 시작한 v2ray-plugin 서버가 기대하는 방식입니다.mux=0으로 시작한 서버에는ws-mux=false를 쓰세요.- 같은 줄에
obfs=도 있으면 WebSocket이 사용되고 simple-obfs는 적용되지 않습니다. 구성을 로드할 때 로그에Policy <name> ignored unsupported option(s): obfs가 남습니다. - UDP는 플러그인을 거치지 않습니다: 일반 Shadowsocks UDP로
host:port에 직접 보내지므로 CDN을 통과하지 못합니다. CDN을 거쳐 연결하는 서버에는udp-relay=false를 쓰세요. 플러그인 뒤의 Shadowsocks 서버가 UoT를 지원하면 대신udp-over-tcp=true를 쓸 수 있습니다. UDP가 정책의 스트림 안에 실리므로 WebSocket도 거칩니다. - v2ray-plugin의 quic 모드는 지원하지 않습니다.
Shadowrocket의 표기도 읽습니다: obfs=websocket(또는 obfs=ws)이고, Host는 obfsParam이나 obfs-host에, 경로는 path나 obfs-uri에 씁니다. 저장할 때는 ws=true로 씁니다. Shadowsocks가 읽을 수 없는 그 밖의 obfs 값 — Quantumult X의 wss나 오타 등 — 은 권고에서 이름이 밝혀지며, 정책은 일반 Shadowsocks로 연결합니다: Shadowsocks over WebSocket (the v2ray-plugin transport) is written ws=true, with ws-path= and ws-headers=; obfs=<value> is not read, so this policy would connect as plain Shadowsocks.
SS = ss, 1.2.3.4, 443, aes-256-gcm, password, ws=true, ws-path=/ws, ws-headers=Host:cdn.example.com, tls=true, sni=cdn.example.com
udp-over-tcp: 선택.
udp-over-tcp=true, udp-over-tcp-version=2
정책의 UDP를 서버의 UDP 릴레이 대신 정책 자신의 TCP 연결 안에 실어 보냅니다 — sing-box의 UDP over TCP(UoT)입니다. UDP 흐름마다 서버가 알아보는 약속된 주소(sp.v2.udp-over-tcp.arpa, 버전 1은 sp.udp-over-tcp.arpa)로 연결을 하나씩 엽니다. 이 연결들은 정책의 일반 연결이므로 다른 연결처럼 underlying-proxy를 따릅니다. 그래서 HTTP 프록시처럼 UDP를 나르지 않는 상위를 거쳐도 UDP가 동작하고, WebSocket 전송도 거칩니다. 서버가 UoT를 지원해야 하며, sing-box와 mihomo 서버는 지원합니다. Shadowsocks 2022 메서드에서도 쓸 수 있습니다.
udp-over-tcp-version(기본값2): 버전 2는 각 연결의 처음에 목적지를 알리는 요청을 보내고, 이후 데이터그램마다 길이로 구분합니다. 버전 1은 요청 없이 데이터그램마다 앞에 주소를 붙입니다. mihomo의 기본값은 버전 1이므로, mihomo에서 가져온 프로필에는 버전이 명시됩니다. 그 밖의 값은 알림을 남기고2로 사용하며, 프로필을 저장할 때는 적힌 그대로 남깁니다.udp-relay=false는 여전히 그 정책의 UDP를 끕니다.- 앱의 Shadowsocks 편집기에서는 UDP over TCP 스위치와 UoT 버전 선택이 이에 해당합니다.
SS = ss, 1.2.3.4, 8388, aes-256-gcm, password, udp-over-tcp=true
ShadowsocksR/ShadowsocksRR/ShadowsocksR-Akarin 프록시 매개변수
method: 필수.
현재 지원:
rc4
rc4-md5-6
rc4-md5
aes-128-cfb
aes-192-cfb
aes-256-cfb
aes-128-ctr
aes-192-ctr
aes-256-ctr
bf-cfb
camellia-128-cfb
camellia-192-cfb
camellia-256-cfb
cast5-cfb
des-cfb
idea-cfb
rc2-cfb
seed-cfb
salsa20
chacha20
chacha20-ietf
protocol: 선택.
현재 지원:
origin
auth_sha1
auth_sha1_v2
auth_sha1_v4
auth_aes128_md5
auth_aes128_sha1
auth_chain_a
auth_chain_b
auth_chain_c
auth_chain_d
auth_chain_e
auth_chain_f
auth_akarin_rand
auth_akarin_spec_a
protocol_param: 선택.
obfs: 선택.
현재 지원:
plain
http_simple
http_post
tls1.2_ticket_auth
obfs_param: 선택.
WebSocket 프록시 매개변수
WebSocket 전송은 Trojan, VMess, VLESS에서 사용할 수 있고, Shadowsocks와 ShadowsocksR에서도 사용할 수 있습니다. 뒤의 둘에서는 v2ray-plugin의 websocket 모드에 해당하며, 달라지는 점은 WebSocket(v2ray-plugin)을 참고하세요.
ws: 선택.
ws=true
WebSocket 전송을 활성화합니다.
ws-path: 선택.
ws-path=/exmaple
WebSocket HTTP 요청의 경로를 변경합니다.
ws-headers: 선택.
ws-headers=Header1:Value1|Header2:Value2
WebSocket HTTP 요청의 HTTP 헤더를 수정합니다.
gRPC 프록시 매개변수
gRPC 전송은 Trojan, VMess 및 VLESS 프로토콜에서 사용할 수 있습니다. HTTP/2 기반 gRPC 프레이밍을 TLS 위에서 사용하여 특정 네트워크 제한을 우회하는 데 도움이 될 수 있습니다.
grpc: 선택.
grpc=true
gRPC 전송을 활성화합니다. 이 전송은 정책의 tls 값과 관계없이 언제나 TLS 위에서 동작합니다. 정책이 global-client-fingerprint를 받아야 한다면 그래도 tls=true를 쓰세요. gRPC 정책은 tls=true를 설정했을 때만 이 설정을 받습니다.
grpc-service-name: grpc=true일 때 필수.
grpc-service-name=MyService
멀티플렉싱을 위한 gRPC 서비스 이름/경로를 지정합니다. 서버에 구성된 서비스 이름과 일치해야 하며, 기본값은 없습니다.
grpc-multi-mode: 선택.
grpc-multi-mode=true
Xray의 다중 모드(multi mode)를 사용합니다: 터널이 /<service>/Tun 대신 /<service>/TunMulti를 호출하며, 여러 번의 쓰기가 하나의 gRPC 메시지에 담겨 전달됩니다. 서버가 다중 모드를 지원해야 합니다. 터널마다 여전히 자체 연결을 가집니다.
VMess 및 gRPC 예:
VMess = vmess, 1.2.3.4, 443, uuid=uuid, tls=true, grpc=true, grpc-service-name=GunService, sni=example.com
XHTTP 프록시 매개변수
XHTTP 전송은 Trojan, VMess, VLESS 프로토콜에서 사용할 수 있습니다. 연결 하나를 계속 열어 두는 대신 일반 HTTP 요청 안에 터널을 담습니다. 다운로드는 끝나지 않는 응답 하나로 오고, 업로드는 연속된 POST이거나 끝나지 않는 POST 하나입니다. CDN을 통과할 수 있다는 점이 WebSocket이나 gRPC 대신 이것을 고르는 주된 이유입니다.
HTTP 버전은 직접 설정하지 않습니다. TLS가 없으면 HTTP/1.1이고, TLS가 있으면 HTTP/2이며,
alpn이 정확히 http/1.1이면 HTTP/1.1, 정확히 h3이면 HTTP/3이 됩니다. REALITY는 항상
HTTP/2를 사용합니다.
xhttp: 선택.
xhttp=true
XHTTP 전송을 활성화합니다.
xhttp-mode: 선택.
xhttp-mode=packet-up
업로드를 실어 나르는 방식입니다. auto(기본값)는 packet-up과 같으며, REALITY를 쓸
때는 stream-one과 같습니다.
packet-up— 업로드가 번호가 붙은 POST의 연속입니다. 호환성이 가장 좋고 CDN과도 가장 잘 맞습니다.stream-up— 업로드는 끝나지 않는 POST 하나이고 다운로드는 별도 요청입니다.stream-one— 요청 하나가 송수신을 모두 담당합니다. 서버와 중간 장비가 전이중 HTTP를 지원해야 합니다.
서버는 보통 모드를 고정하며, 맞지 않으면 400으로 응답합니다.
xhttp-path: 선택.
xhttp-path=/yourpath
요청 경로이며 기본값은 /입니다. 서버가 XHTTP를 제공하는 경로와 일치해야 합니다.
xhttp-host: 선택.
xhttp-host=example.com
Host 헤더와 요청 URL에 사용하는 호스트 이름입니다. 기본값은 sni이며, 설정되지 않은
경우 서버 주소를 사용합니다.
xhttp-headers: 선택.
xhttp-headers=Header1:Value1|Header2:Value2
추가 HTTP 헤더이며 형식은 ws-headers와 같습니다.
xhttp-padding: 선택.
xhttp-padding=100-1000
모든 요청이 싣는 패딩 길이 범위이며 MIN-MAX 또는 단일 숫자로 쓰고 기본값은
100-1000입니다. 서버는 패딩을 필수로 요구하고 길이를 검증합니다. 따라서 이 범위는
서버가 허용하는 구간 안에 있어야 하며, 패딩이 없거나 길이가 맞지 않으면 400이
반환됩니다.
xhttp-max-post-bytes: 선택.
xhttp-max-post-bytes=1000000
업로드 POST 하나의 최대 바이트 수이며 기본값은 1000000입니다. 더 큰 쓰기는 여러 POST로
나뉩니다.
xhttp-min-post-interval: 선택.
xhttp-min-post-interval=30
연속된 업로드 POST 사이의 최소 간격(밀리초)이며 기본값은 30입니다.
xhttp-xmux-max-concurrency, xhttp-xmux-max-connections, xhttp-xmux-max-reuse-times, xhttp-xmux-max-lifetime: 선택.
xhttp-xmux-max-concurrency=4
XMUX는 하위 HTTP/2 연결을 풀링하여 여러 터널이 연결 하나를 공유하게 합니다. 터널마다
연결을 여는 대신 평범한 브라우저 세션처럼 보이게 됩니다. 네 항목 모두 기본값은 0이며
풀링이 꺼진 상태입니다.
xhttp-xmux-max-concurrency— 연결 하나를 공유할 수 있는 터널 수.xhttp-xmux-max-connections— 서버당 허용하는 연결 수.xhttp-xmux-max-reuse-times— 연결 하나가 터널 몇 개를 처리한 뒤 새 터널을 받지 않을지.xhttp-xmux-max-lifetime— 몇 초가 지나면 새 터널을 받지 않을지.
XHTTP 정책에서는 프로토콜과 관계없이 mux=true가 거부되며, 구성을 로드할 때 로그에
Policy <name> ignored unsupported option(s): mux가 남습니다. XHTTP에는 자체 멀티플렉싱이 있어 범용 멀티플렉싱을
얹으면 두 겹이 되기 때문입니다.
xhttp-download-server, xhttp-download-port: 선택.
xhttp-download-server=cdn.example.com
다운로드만 다른 주소로 — 보통 같은 서버 앞단의 CDN — 보내고 업로드는 주 주소를 계속 사용합니다. 둘은 같은 서버에 도달해야 합니다. 세션은 서버 측 상태이므로 경로를 바꾸는 것은 괜찮지만 서버를 바꿀 수는 없습니다.
VLESS와 XHTTP 예시:
VLESS = vless, 1.2.3.4, 443, uuid=uuid, tls=true, xhttp=true, xhttp-mode=packet-up, xhttp-path=/yourpath, sni=example.com
XTLS 프록시 매개변수
xtls: 선택.
xtls=true
전송을 XTLS로 감쌉니다. 이것만으로는 어떤 flow도 알리지 않습니다. VLESS 요청의 addons 블록이 비어 있어 flow가 협상되지 않기 때문입니다. flow를 알리려면 아래의 flow=xtls-rprx-vision을 사용하세요. xtls-rprx-direct는 구현되어 있지 않습니다.
flow: 선택.
flow = xtls-rprx-vision
XTLS 흐름 제어를 선택합니다. 지원되는 값은 xtls-rprx-vision 하나뿐이며, Vision 프레이밍을 활성화합니다. 이 흐름 값은 VLESS addons를 통해 서버로 전달됩니다.
skip-cert-verify: 선택
skip-cert-verify=true
TLS와 동일합니다.
sni (기본값: 호스트명)
sni=exmaple.com
TLS와 동일합니다.
REALITY 프록시 매개변수
REALITY는 프록시 트래픽을 실제 웹사이트로의 일반 TLS 트래픽과 구별할 수 없게 만드는 TLS 기반 난독화 기술입니다. VLESS 프로토콜과 함께 사용할 수 있습니다.
reality: 선택.
reality=true
REALITY 난독화를 활성화합니다. 위장 대상으로 사용될 대상 서버가 필요합니다.
public-key: 필수.
public-key=BASE64KEY
서버의 X25519 공개 키(base64)입니다. 이 키 없이는 REALITY 핸드셰이크를 구성할 수 없습니다.
short-id: 선택.
short-id=abcd1234
REALITY 인증에 사용되는 짧은 식별자입니다. 일반적으로 16진수 문자열입니다.
server-name: 선택.
server-name=www.microsoft.com
TLS 핸드셰이크 중 표시할 SNI(서버 이름 표시)입니다. 최상의 위장 효과를 위해 실제로 자주 접속되는 웹사이트여야 합니다. 대상 서버의 인증서가 이 이름과 일치해야 합니다.
fingerprint: 선택.
fingerprint=chrome
모방할 TLS 클라이언트 지문입니다. 지원되는 값으로는 chrome, firefox, safari, ios, edge, 360, qq, android, random, 그리고 fingerprint에 나열한 그 밖의 이름이 있습니다. 일반적인 브라우저 지문을 사용하면 탐지를 피하는 데 도움이 됩니다. 여기서 android와 random은 별도의 지문이 아니라 chrome으로 처리된다는 점에 유의하세요. none과 Chute가 인식하지 못하는 값은 연결을 거부하게 합니다. 이 핸드셰이크는 시스템 TLS 스택으로 할 수 없기 때문입니다.
spiderx: 선택.
spiderx=/path
REALITY 스파이더 위장을 위한 사용자 정의 경로입니다.
VLESS 예:
VLESS = vless, 1.2.3.4, 443, uuid=uuid, reality=true, public-key=BASE64KEY, server-name=www.microsoft.com, short-id=abcd, fingerprint=chrome
참고: REALITY는 기존 인증서를 사용하지 않습니다. 연결은 위장 서버의 실제 인증서를 사용합니다.
ECH 프록시 매개변수
Encrypted Client Hello는 연결을 지켜보는 쪽으로부터 서버 이름을 숨깁니다. 실제
이름은 핸드셰이크 내부에 암호화되어 전달되고, 경로에 드러나는 것은 서버의
ECHConfig가 공개한 public_name입니다.
ECH는 클라이언트 지문과 같은 구현 위에 올라가 있으므로 정책에
fingerprint도 함께 설정해야 합니다. 지정하지 않으면
ech=true는 아무 일도 하지 않고 실제 이름이 그대로 전송됩니다. 일반 TLS를 사용하는
Trojan, VMess, VLESS에 적용되며 WebSocket 전송도 포함합니다. WebSocket과 TLS를 사용하는
Shadowsocks와 ShadowsocksR에도 적용됩니다.
주의: gRPC와 XHTTP 전송은 ECH를 지원하지 않습니다.
grpc=true나xhttp=true이면ech=true는 조용히 무시되고 실제 서버 이름이 그대로 전송됩니다. (클라이언트 지문과 양자 내성 키 교환은 gRPC와 XHTTP에도 적용됩니다.)
ech: 선택.
ech=true
ECH를 활성화합니다. ech-config가 설정되어 있지 않으면 Chute는 브라우저와 같은
방식으로 서버 이름의 DNS HTTPS 레코드에서 ECHConfig를 조회합니다.
ech-config: 선택.
ech-config=AEX+DQBBAAAgACD...
base64 ECHConfigList이며 DNS 조회 대신 사용됩니다. 서버가 HTTPS 레코드를 게시하지
않거나 특정 설정으로 고정하고 싶을 때 지정합니다. 이 값을 설정하면 그것만으로
ECH가 켜지므로 ech=true를 따로 쓸 필요가 없습니다.
ech-public-name: 선택.
ech-public-name=cover.example.com
평문으로 전송되는 가림용 이름을 덮어씁니다. 기본값은 ECHConfig 안의
public_name이며 서버가 기대하는 값입니다. 설정을 다른 호스트가 대신 게시하는
배포에서만 지정하세요.
Trojan 예시:
Trojan = trojan, 1.2.3.4, 443, password=pw, tls=true, sni=secret.example.com, fingerprint=chrome, ech=true
서버가 ECH를 거부하면(대개 설정이 오래되어서입니다) 가림용 이름으로 응답하고 그 이름의 인증서를 제시하며, 핸드셰이크는 바깥쪽 TLS로 폴백합니다. 인증서 검증이 켜져 있는 한 연결은 조용히 이어지지 않고 인증에 실패합니다. 반면
skip-cert-verify=true이면 그 이름을 확인하는 것이 아무것도 없어 세션이 가림용 이름 아래에서 조용히 이어집니다.ech-config를 갱신하거나 삭제해 DNS 조회로 되돌리세요.
TCP Fast Open (실험적)
tfo: 선택
tfo=true
TCP Fast Open에 대한 자세한 정보는 Wikipedia에서 확인할 수 있습니다. TCP Fast Open을 활성화하면 예기치 않은 연결 실패가 발생할 수 있습니다. Chute Android는 tfo를 무시합니다.
공통 매개변수
udp-relay: 선택 (기본값: true)
udp-relay=false
정책을 TCP 전용으로 표시합니다. 프로토콜이 지원하는 경우 UDP 릴레이는 기본적으로 켜져 있으며, 정책을 UDP 트래픽 릴레이에서 제외하려면 udp-relay=false를 설정하세요. Trojan은 서버 포트로 맺은 일반 TLS 연결 위로 UDP를 릴레이합니다 — WebSocket, gRPC, XHTTP 없이, ECH도 없이, 다만 정책의 지문은 사용해서 — 따라서 그런 전송 중 하나로만 서비스하는 서버를 상대로는 udp-relay=false를 설정하세요.
mux: 선택
mux=true
연결 재사용/멀티플렉싱을 활성화합니다. 별칭 multiplex 및 reuse도 허용됩니다. HTTP/HTTPS, SOCKS5/SOCKS5-TLS, Trojan, VMess, VLESS, Hysteria2, Shadowsocks(R), ShadowTLS 및 MASQUE에서 지원됩니다. AnyTLS, TUIC, SSH는 어느 플랫폼에서도 멀티플렉싱되지 않습니다. 이들에는 mux=true가 적용되지 않으며, 구성을 로드할 때 로그에 그 사실이 남습니다: Policy <name>: mux=true is not applied: <reason>.
Hysteria2와 MASQUE는 공유하는 하나의 QUIC 연결 위에서 멀티플렉싱합니다. 그 밖의 프로토콜은 멀티플렉싱한 연결을 Chute 고유의 프레이밍으로 실어 나르므로, 이를 이해하는 서버만 분리할 수 있습니다: 표준 Xray, sing-box, Shadowsocks 서버는 분리하지 못하므로 이런 서버에는 mux를 켜지 마세요.
cert-fingerprint-sha256: 선택
cert-fingerprint-sha256=<hex>
SHA-256 지문으로 서버 인증서를 고정합니다. 별칭 cert-fp도 허용됩니다. 현재는 MASQUE에서만 유효합니다.
encrypt-method (VMess): 선택 (기본값: auto)
encrypt-method=aes-128-gcm
VMess 페이로드 암호화입니다. 지원되는 값: aes-128-gcm, chacha20-poly1305, aes-128-cfb(별칭 legacy), none.
alpn: 선택
alpn=h2|http/1.1
여러 ALPN 값은 |로 구분합니다. 이 값을 읽는 것은 TUIC, Hysteria2, MASQUE뿐이며(셋 다 지정하지 않으면 h3이 기본값입니다), 그 밖에는 XHTTP에서 전송이 사용할 HTTP 버전을 고르는 데 쓰입니다. 나머지 프로토콜은 이 옵션을 무시하고 전송이 정하는 ALPN을 제시합니다: gRPC는 h2이고, fingerprint를 지정하면 WebSocket은 http/1.1, 일반 TLS는 h2,http/1.1이며, 지정하지 않으면 둘 다 아무것도 제시하지 않습니다. 그때는 시스템 TLS 스택이 핸드셰이크를 하기 때문입니다.
underlying-proxy: 선택.
underlying-proxy=OtherProxy
프록시 체이닝: 이 정책의 트래픽을 운반할 다른 정책 또는 정책 그룹의 이름을 지정합니다. 상위 연결을 먼저 연 뒤 자신의 서버로 연결하므로 A = ..., underlying-proxy=B는 A를 B를 통해 보냅니다. B가 다시 상위를 지정하면 여러 홉이 됩니다. 비워 두거나 DIRECT를 쓰면 직접 연결합니다. 공백이나 쉼표가 들어간 이름은 underlying-proxy="HK 01"처럼 따옴표로 묶으세요. 존재하지 않는 이름이면 연결을 거부하고(fail-closed) 로그를 남기며, DIRECT로 대체하지 않습니다.
고정된 참조로만 이루어진 순환(릴레이 그룹 첫 번째 멤버 자신의 underlying-proxy를 거쳐 되돌아오는 순환 포함)은 구성을 불러올 때 거부됩니다. 정책 그룹이 지금 무엇을 선택했는지 때문에만 생기는 순환은 영구히 거부되지 않습니다. 그룹이 다른 것을 선택하면 정책이 동작하지만, 순환이 이어지는 동안에는 그것을 거치는 모든 연결이 거부됩니다. 체인이 어떤 형태이든, 상위가 16단계를 넘게 중첩되는 연결은 끝없이 펼쳐지지 않고 거부됩니다.
이 정책의 서버 이름도 상위가 해석합니다. 체이닝된 서버는 로컬 리졸버로 조회하지 않으며 Chute가 직접 테스트하지도 않습니다. 릴레이 그룹에서 첫 번째 멤버 뒤에 오는 정책도 마찬가지입니다. 지연 시간은 그룹 상태 확인과 지연 시간 테스트에서 얻으며, 둘 다 체인을 통해 서버에 도달합니다 — url-test, fallback, load-balance 그룹은 체이닝된 멤버를 실제 연결과 같은 경로로 측정합니다.
Tailscale(내장 TAILSCALE 정책. 그 엔진이 직접 연결을 엽니다)을 제외한 모든 프로토콜을 체이닝할 수 있습니다. 서버에 스트림으로 연결하는 정책 — HTTP, SOCKS5, Shadowsocks, VMess, VLESS, Trojan, AnyTLS, SSH, HTTP/1.1 또는 HTTP/2 기반 XHTTP 등 — 은 그 스트림을 상위를 거쳐 엽니다. Hysteria2, TUIC, MASQUE와 HTTP/3 기반 XHTTP(TLS와 alpn=h3)는 QUIC을 쓰고, WireGuard와 AmneziaWG는 자체 데이터그램을 보내므로 상위의 UDP 릴레이를 거칩니다. 상위(그룹이면 현재 선택된 것)는 UDP를 나를 수 있어야 합니다. Shadowsocks, SOCKS5, VMess, VLESS, Trojan, Hysteria2는 가능하지만 HTTP나 HTTPS 프록시는 불가능합니다. UDP를 나르지 않는 상위 위에서는 이들을 거치는 모든 연결이 거부되고 로그에 기록되며 절대 직접 전송되지 않습니다. 체이닝된 QUIC 정책은 최대 1200바이트의 데이터그램을 보내고, WireGuard나 AmneziaWG 터널은 MTU를 적지 않는 한(mtu 또는 섹션의 wg-mtu) 내부 MTU 1280을 사용하므로, 감싼 데이터그램도 1500바이트 경로에 들어갑니다. WireGuard, AmneziaWG, SSH는 모든 트래픽을 자신의 상위를 거친 연결 하나로 나르므로, 어느 것도 릴레이 그룹의 두 번째 이후 멤버가 될 수 없습니다.
UDP도 체인을 거칩니다. VMess, VLESS, Trojan, AnyTLS는 UDP를 스트림 안에 실으므로 어떤 상위 위에서도 UDP가 동작합니다. Shadowsocks(ShadowsocksR와 Shadowsocks 2022 포함)와 SOCKS5는 UDP를 데이터그램으로 중계하며, QUIC 계열 프로토콜과 WireGuard도 마찬가지입니다. 이들의 UDP는 상위가 UDP를 나를 때만 동작합니다. 다만 udp-over-tcp를 쓰는 Shadowsocks 노드는 UDP를 스트림 안에 실으므로 어떤 상위 위에서도 동작합니다. SSH, HTTP, HTTPS 정책은 UDP를 전혀 나르지 않습니다. 체이닝된 정책이 나를 수 없는 UDP는 udp-policy-not-supported-behaviour(기본값 REJECT)를 따릅니다.
mihomo의 dialer-proxy와 sing-box의 detour는 이 옵션으로, 프록시 제공자의 override: dialer-proxy는 제공자의 underlying-proxy로 가져옵니다. Clash 또는 mihomo의 relay 그룹은 멤버 순서를 그대로 유지한 릴레이 그룹으로 남습니다. 정책 그룹의 모든 멤버를 하나의 상위를 거쳐 보내려면 그룹에 underlying-proxy를 설정하세요. 모든 프록시 정책을 하나의 상위를 거쳐 보내려면 [General]에 global-underlying-proxy를 설정하세요.
test-url: 선택.
test-url=http://www.gstatic.com/generate_204
이 정책이 url-test 또는 fallback 그룹의 멤버일 때 쓰는 지연 시간 테스트 URL입니다. 그룹은 그룹의 url 대신 이 URL로 해당 멤버를 측정합니다. 지정하지 않으면 그룹의 URL을 사용합니다.
interface: 선택
interface=en0
이 정책이 서버로 맺는 TCP 연결을 기본 경로가 고르는 인터페이스 대신 지정한 네트워크 인터페이스 — 예를 들어 Mac의 en0, Android의 wlan0 — 로 내보냅니다. 그 인터페이스를 사용할 수 없으면 연결은 다른 경로로 나가지 않고 실패합니다. allow-other-interface=true를 쓰면 대신 기본 경로를 따릅니다. Chute Mac과 Chute Android에서 동작하며, iOS와 tvOS는 이 옵션을 무시합니다. UDP 릴레이는 바인딩되지 않으며, QUIC 기반 프로토콜(TUIC, Hysteria2, MASQUE), WireGuard, Tailscale도 마찬가지입니다.
AnyTLS 프록시 매개변수
AnyTLS는 패딩 난독화가 포함된 TLS 기반 프록시 프로토콜입니다.
AnyTLS = anytls, 1.2.3.4, 443, password, sni=example.com, skip-cert-verify=false
password: 필수.
인증에 사용되는 비밀번호/암호입니다.
sni (기본값: 호스트명)
sni=exmaple.com
TLS와 동일합니다.
skip-cert-verify: 선택
skip-cert-verify=true
TLS와 동일합니다.
패딩 방식: 선택
패딩은 stop=N과 숫자로 된 패킷별 키로 구성됩니다:
AnyTLS = anytls, 1.2.3.4, 443, password, sni=example.com, stop=2, 0=30-30, 1=100-400+c
| 매개변수 | 설명 |
|---|---|
stop |
패딩되는 패킷 수 |
0, 1, 2, ... |
각 패킷의 패딩 방식 (숫자 키) |
각 방식은 +로 연결된 세그먼트 목록이며, 세그먼트는 c(체크) 또는 min-max 바이트 범위(최대 16384)입니다. 예: stop=2, 0=30-30, 1=100-400+c. ,도 구분자로 동작하지만 값을 따옴표로 감쌌을 때만 그렇습니다 — 1="100-400,c" — 따옴표가 없으면 쉼표가 필드를 끝내 버려 줄이 깨지기 때문입니다. +를 권합니다.
TUIC 프록시 매개변수
TUIC는 멀티플렉싱된 TCP 및 UDP 릴레이를 제공하는 QUIC 기반 프록시 프로토콜입니다. 키워드 tuic-v5(Surge의 표기)도 허용되며, 저장할 때는 tuic으로 기록됩니다.
TUIC = tuic, 1.2.3.4, 443, uuid=uuid, password=password, sni=example.com, skip-cert-verify=false, alpn=h3
uuid: 필수.
인증을 위한 UUID입니다.
password: 필수.
인증을 위한 비밀번호입니다.
sni (기본값: 호스트명)
sni=exmaple.com
TLS와 동일합니다.
skip-cert-verify: 선택
skip-cert-verify=true
TLS와 동일합니다.
alpn: 선택
alpn=h3
QUIC 연결을 위한 ALPN 문자열을 지정합니다.
Hysteria2 프록시 매개변수
Hysteria2는 높은 처리량 시나리오를 위한 QUIC 기반 프록시 프로토콜입니다.
Hysteria2 = hysteria2, 1.2.3.4, 443, auth=password, sni=example.com, skip-cert-verify=false, up=10, down=100, alpn=h3
auth: 필수.
인증 비밀번호/토큰입니다.
sni (기본값: 호스트명)
sni=exmaple.com
TLS와 동일합니다.
skip-cert-verify: 선택
skip-cert-verify=true
TLS와 동일합니다.
up: 선택 (Mbps)
up=10
업로드 대역폭(Mbps)입니다. 받아들여 보존하지만 사용하지는 않습니다. 이 값은 Hysteria2의 Brutal 혼잡 제어를 위한 것이고, 이 엔진은 그것을 실행하지 않습니다. 이를 설정한 정책마다 알림이 기록됩니다. 실제로 전송되는 것은 down= 쪽으로, 인증 시 클라이언트가 선언하는 속도입니다.
down: 선택 (Mbps)
down=100
다운로드 대역폭(Mbps)입니다.
alpn: 선택
alpn=h3
QUIC 연결을 위한 ALPN 문자열을 지정합니다.
obfs: 선택
obfs=salamander
QUIC 트래픽에 대한 Salamander 난독화를 활성화합니다. Salamander는 BLAKE2b-256 XOR을 사용하여 QUIC 패킷을 난독화하여 DPI(심층 패킷 검사)에 저항성을 갖게 합니다.
obfs-password: 선택
obfs-password=your-obfuscation-key
Salamander 난독화에 사용되는 비밀번호/키입니다. obfs=salamander가 설정된 경우 필수입니다.
WireGuard 프록시 매개변수
WireGuard는 현대적인 VPN 프로토콜입니다. Chute는 WireGuard를 인라인 또는 명명된 [WireGuard] 섹션을 참조하여 아웃바운드 프록시 서버로 지원합니다.
인라인 구성:
WireGuard = wireguard, private-key=base64key, peer-public-key=base64key, self-ip=10.0.0.2, server=1.2.3.4, port=51820
섹션 참조 (권장):
WireGuard = wireguard, section-name=wg0
[WireGuard] 섹션 구문은 WireGuard 구성을 참조하세요.
private-key: 필수 (인라인 전용).
Base64로 인코딩된 WireGuard 개인 키입니다.
peer-public-key: 필수 (인라인 전용).
Base64로 인코딩된 WireGuard 피어 공개 키입니다.
self-ip: 선택 (인라인).
WireGuard 인터페이스에 할당된 로컬 IP 주소입니다(예: 10.0.0.2).
self-ip-v6: 선택 (인라인).
WireGuard 인터페이스에 할당된 로컬 IPv6 주소입니다.
server: 필수.
원격 WireGuard 서버 주소입니다(정책 줄 대신 참조된 [WireGuard] 섹션에서 가져올 수 있음).
port: 필수.
원격 WireGuard 서버 포트입니다(정책 줄 대신 참조된 [WireGuard] 섹션에서 가져올 수 있음).
preshared-key: 선택.
양자 내성을 위한 Base64 인코딩 사전 공유 키입니다.
allowed-ips: 선택 (인라인).
allowed-ips="10.0.0.0/8, 192.168.0.0/16"
피어가 운반하는 목적지로, 쉼표로 구분한 CIDR 목록입니다. 값에 쉼표가 들어가므로 따옴표로 감싸세요. 이 범위 밖의 목적지는 피어가 응답을 되돌려 보낼 수 없으므로 거부되거나 버려집니다. 지정하지 않으면 모든 목적지를 운반합니다. 섹션 형식은 WireGuard 구성을 참조하세요.
keepalive: 선택 (초).
keepalive=25
NAT 통과를 위한 지속적 킵얼라이브 간격입니다. 지정하지 않으면 킵얼라이브를 보내지 않습니다.
mtu: 선택.
mtu=1420
WireGuard 인터페이스의 MTU입니다.
reserved: 선택.
reserved=0,1,2
WireGuard 패킷 헤더용 예약 바이트입니다. 현재 엔진에서는 파싱만 되고 효과가 없습니다 — BoringTun FFI가 이 값을 지원하지 않아 경고를 남기고 무시됩니다.
ShadowTLS 프록시 매개변수
ShadowTLS는 표준 TLS 1.3 세션 내에서 트래픽을 캡슐화하는 TLS 기반 프록시 프로토콜입니다. Chute가 사용하는 것은 ShadowTLS v3입니다. 비밀번호는 ClientHello의 session_id에 HMAC으로 실려 가므로, 인증은 핸드셰이크가 끝난 뒤가 아니라 핸드셰이크 안에서 이루어집니다.
맺어진 터널 안에서 Chute는 인증 없는 SOCKS5 그리팅과 SOCKS5 CONNECT를 보냅니다. 따라서 ShadowTLS 뒤의 서버는 인증이 없는 SOCKS5 프록시여야 합니다. SOCKS5 포트가 아니라 Shadowsocks 포트로 넘기는 shadow-tls 배포는 TLS 핸드셰이크까지는 끝낸 뒤 실패합니다.
ShadowTLS = shadowtls, 1.2.3.4, 443, password=password, sni=example.com, skip-cert-verify=false, fingerprint=chrome
password: 필수.
ShadowTLS 핸드셰이크 인증에 사용되는 비밀번호입니다.
sni (기본값: 호스트명)
sni=example.com
TLS와 동일합니다. 이 값을 쓰는 것이 곧 가림용 인증서 검증을 켜는 일이기도 합니다 — 아래를 보세요.
skip-cert-verify: 선택
skip-cert-verify=true
검증을 켜는 것은 sni=입니다. sni=를 쓰고 skip-cert-verify가 없거나 false이면, 가림용 사이트가 제시하는 인증서의 체인과 호스트명이 그 이름을 기준으로 검증되며, 검증에 실패하면 연결도 실패합니다. sni=가 없으면 인증서는 검증되지 않고 정책당 한 번, 처음 쓸 때 경고가 기록됩니다. 알 수 있는 이름이 중계 서버의 것뿐이고 그것은 가림용 사이트의 이름이 아니기 때문입니다. skip-cert-verify=true는 어느 경우든 검증을 건너뜁니다.
fingerprint: 선택
fingerprint=chrome
모방할 TLS 클라이언트 지문입니다. 지원되는 값으로는 chrome, firefox, safari, ios, edge, 360, qq, android, random, 그리고 fingerprint에 나열한 그 밖의 이름이 있습니다. 일반적인 브라우저 지문을 사용하면 탐지를 피하는 데 도움이 됩니다. 여기서 android와 random은 별도의 지문이 아니라 chrome으로 처리된다는 점에 유의하세요. none과 Chute가 인식하지 못하는 값은 연결을 거부하게 합니다. 이 핸드셰이크는 시스템 TLS 스택으로 할 수 없기 때문입니다.
MASQUE 프록시 매개변수
MASQUE는 QUIC를 통해 트래픽을 터널링하는 HTTP/3 기반 프록시 프로토콜입니다. MASQUE 정책에는 type, host, port가 필요하며 인증 token은 선택 사항입니다.
ProxyMASQUE = masque, 1.2.3.4, 443, token=auth-token, mode=connect-udp, sni=example.com, alpn=h3, skip-cert-verify=false, mux=true
token: 선택
token=auth-token
MASQUE 서버에 사용할 수 있는 선택적 Bearer 인증 토큰입니다. 별칭 masque-token=도 허용됩니다.
mode: 선택
mode=connect-udp
호환성을 위해 허용되지만 터널링 동작을 변경하지 않습니다: TCP 흐름은 항상 일반 CONNECT 터널을 사용하고 UDP 흐름은 항상 connect-udp를 사용합니다. 별칭 masque-mode=도 허용됩니다.
mux: 선택
mux=true
공유 QUIC 연결에서 멀티플렉싱을 활성화합니다.
sni / alpn / skip-cert-verify: 선택
TLS와 동일합니다. MASQUE는 QUIC 위에서 동작하므로 일반적으로 alpn=h3을 사용합니다.
SSH 프록시 매개변수
전체 문서는 SSH 프록시를 참조하세요.
이 페이지는 영어판의 번역본입니다. 내용이 다를 경우 영어판이 우선합니다.