Configuration

Configuration

Shadowsocks

Shadowsocks Protocol.

AEAD ciphers

AEAD ciphers. aes-128-gcm, aes-256-gcm, chacha20-poly1305, and non-standard but de facto popular aes-192-gcm and xchacha20-poly1305 are supported.

• In V2Ray, chacha20-poly1305 is an alias of chacha20-ietf-poly1305. In fact, they are different ciphers due to historical reason, and chacha20-poly1305 is not supported by V2Ray.

Stream ciphers

Some standard and non-standard but de facto popular stream ciphers are supported. One-time authentication (OTA) is not supported.

• An active detection vulnerability was discovered in stream ciphers and developers attempted to mitigate this issue with OTA, but introduced a new active detection vulnerability. Eventually, due to the lack of integrity protection, stream ciphers were deprecated and superseded by AEAD ciphers. Stream ciphers were even later discovered that attackers can decrypt communications without knowing the password.

Cipher "none"

"No encryption" cipher. It is usually called none, plain or dummy.

• There is no password, so the password can in fact be any string. Data is transmitted in clear text, thus it is for LAN use or testing purpose only, or it needs to be used together with SIP003 plugins with a secure channel or inside another secure channel.

Plugin

SIP003 Plugin.

• v2ray-plugin (a.k.a. v2ray) and simple-obfs (a.k.a. Simple obfuscation, its client is called "obfs-local" and its server is called "obfs-server") can be used without installing standalone plugins. You can install and use plugins designed for Shadowsocks Android. simple-obfs has been deprecated and superseded by v2ray-plugin. simple-obfs can be distinguished from normal HTTP/TLS services.
• Proxying UDP is not supported. Plugins are not applied to UDP.
• Being consistent with the official implementation, v2ray-plugin uses cloudfront.com as host if not specified (indeed), but other software may not have this behavior and you may need to explicitly set host to the server address to connect to some servers.
• Being consistent with the official implementation, obfs-local uses cloudfront.net as obfs-host if not specified (indeed), but other software may not have this behavior and you may need to explicitly set host to the server address to connect to some servers.
• Although obfs-uri and http-method parameters exist in the source code of obfs-local, it has never been released. Almost no software supports these parameters, and this software is no exception.
• mode=grpc and serviceName of v2ray-plugin does not exist in the official implementation, but they do exist in a popular v2ray-plugin fork by teddysun.
• To mitigate the issue of Go programs unable to query DNS on Android when compiled without CGO enabled, V2Ray hard-coded DNS to 8.8.8.8 on Android (even when compiled with CGO enabled; this behavior has been removed in this software). Using teddysun's v2ray-plugin fork may be affected by this hard-coded DNS. Shadowsocks' official v2ray-plugin is not currently affected because it has not been updated for a long time.
• Shadowsocks Android introduced a significant change in January 2026. For the method of excluding the traffic sent by a plugin from VPN, Shadowsocks Android removed the support for protect in favor of excluding the Shadowsocks Android app itself from VPN. However, system stack technically can not excluding the Shadowsocks Android app itself from VPN. Since then, newly-developed plugins without protect support and updated plugins that have removed protect support may stop working under the system stack of this software.

ReducedIvHeadEntropy

Remap the first 6 bytes of the IV to printable characters. Around 2022 to 2023, this mechanism was reported exempted by the firewall in certain regions but it also creates extremely obvious characteristics. Do NOT abuse exemption mechanism if NOT backed into a corner. This is not part of the Shadowsocks protocol.

Shadowsocks 2022

Cipher 2022-blake3-aes-128-gcm, 2022-blake3-aes-256-gcm and 2022-blake3-chacha20-poly1305.

• Despite nominally recognized as SIP022 and SIP023 by Shadowsocks later, Shadowsocks 2022 is a de facto independently-designed new protocol, rather than an improved or modified version of Shadowsocks, nor is it even the new ciphers for Shadowsocks.
• If Extensible Identity Headers (EIH) is used, "password" is in the form of iPSK0:iPSK1:... :iPSKn:uPSK.

Trojan

Trojan Protocol. Use with TLS.

• The use of Trojan mixed with other various private protocols without changing the original protocol name invented by V2Ray and Xray is not part of Trojan.
• Known issue: Due to V2Ray's infrastructure, if ALPN is unspecified or is an empty array, ALPN h2 and http/1.1 (rather than no ALPN) will be used. This may not be consistent with non-V2Ray/Xray implementations of Trojan. When uTLS is used, the ALPN of uTLS fingerprint will be used.

VMess

Use alone with encryption, or use with TLS and/or "transport".

Alter ID

VMess AEAD header authentication is used when alter ID is 0. Legacy VMess MD5 header authentication is used when alter ID is not 0. In legacy VMess MD5 header authentication, the author claimed that the purpose of alter ID is "to further prevent detection, a user can generate multiple IDs based on the main ID" (it was later pointed out counterproductive).

• Not compatible with VMess MD5 header authentication with an alter ID of 0. Deprecated cipher aes-128-cfb is not supported.
• AEAD header authentication is for addressing some identified security issues of MD5 header authentication. The name or the version code of VMess does not differentiate between them, which creates semantic confusion.

AuthenticatedLength/NoTerminatedSignal

These "experimental" options are intended to address some of the shortcomings of the current VMess AEAD header authentication, but has never really been advanced since their invention.

• AuthenticatedLength is a breaking change incompatible with the current protocol.

User ID

A UUID of version 4.

• If a string of "UUID v5 mapping" invented by Xray is filled, this software will convert it to a UUID of version 5. This is only treated as being compatible with non-standard behavior. sing-box and mihomo are also compatible with this non-standard behavior and allow input of strings of arbitrary length.

VLESS

VLESS Protocol. Use with TLS/REALITY and/or VLESS Encryption and/or "transport".

Flow

XTLS and Vision. It is claimed that it can "populate TLS handshakes and avoid nested encryption".

• Traffic to UDP port 443 is blocked when flow is xtls-rprx-vision, and not blocked when flow is xtls-rprx-vision-udp443. xtls-rprx-vision in sing-box and mihomo is corresponded to xtls-rprx-vision-udp443 in Xray.
• Xray servers refuse to provide services for clients without XUDP enabled when flow is enabled, therefore XUDP is enforced enabled when flow is enabled.
• If encryption is not enabled, although Xray's XTLS (Vision) can't be used together with "transport". However, sing-box accidentally and mihomo intentially support XTLS (Vision) with WS or HTTPUpgrade.
• This XTLS and the "XTLS" as in xtls-rprx-origin/direct/splice are two different protocols, but the protocol name was not changed, causing semantic confusion. The "XTLS" as in xtls-rprx-origin/direct/splice has long been removed by Xray and is not supported by this software.

User ID

A UUID of version 4.

• If a string of "UUID v5 mapping" invented by Xray is filled, this software will convert it to a UUID of version 5. This is only treated as being compatible with non-standard behavior. sing-box and mihomo are also compatible with this non-standard behavior and allow input of strings of arbitrary length.
• New versions of Xray server do not require the seventh and eighth bytes of UUID to match, and use them for "routing purpose". Modifying the seventh and eighth bytes of UUID may result in different treatment.

Encryption

VLESS Encryption. If the value is none, no encryption is used. If the value starts with x25519mlkem768plus, post-quantum X25519MLKEM768 is used for key agreement and traffic is encrypted with AEAD ciphers. This field also contains information such as appearance, RTT, paddings, X25519 public key, and MLKEM768 public keys.

Hysteria 2

Hysteria 2 Protocol. It is more like a QUIC-based network acceleration tool rather than a proxy protocol. It uses HTTP/3 for authentication, and it uses QUIC stream to relay TCP and QUIC Datagram to relay UDP.

• It attempts to use Brutal "congestion control" to rob bandwidth in a way that does not comply with QUIC congestion control if upload speed or download speed is set. Do not set upload speed and download speed to use BBR congestion control rather than the bandwidth-robbing Brutal "congestion control".
• It should be noted that BBR congestion control (specifically v1) completely ignores packet loss mechanisms after a specific bandwidth is detected, which can lead to serious fairness issues in some cases. This has been effectively resolved in BBR v3, but Hysteria 2 only implements BBR v1 currently.
• If you use "userpass" authentication in the official Hysteria2 server, the "password" format is username:password. Username containing a colon does not work. Because of historical reason, old versions of official Hysteria2 server does not support username with Unicode uppercase letters, and new versions of official Hysteria2 server convert username to Unicode lowercase, and non-official Hysteria implementation may not have this behavior.
• If ignore_client_bandwidth is enabled and upload speed and download speed are configured, sing-box server only allows clients using Brutal "congestion control" and rejects clients using BBR congestion control. You need to configure upload speed and download speed yourself.

Salamander Obfuscation

If "Obfuscation password" is provided, Salamander Obfuscation is enabled and traffic is obfuscated as "UDP packets with no pattern". Not compatible with the original Hysteria 2 protocol.

Port hopping

Change source port and destination port regularly. It does not cause any data loss or disconnection thanks to QUIC connection ID.

• Port hopping might help mitigate ISP QoS for UDP, if you must use it that way. Would create more patterns for censors.
• The format of server port:
  • Multiple individual ports: 1234,5678,9012
  • A range of ports: 20000-50000
  • A combination of both: 1234,5000-6000,7044,8000-9000

AnyTLS

AnyTLS Protocol v2. A proxy protocol that "attempts to mitigating the nested TLS handshake fingerprint (TLS in TLS) issue". It has "flexible packet-splitting and filling strategy" and "connection reuse to reduce proxy latency".

• AnyTLS is designed to be used with TLS. Although the method of using with REALITY promoted by some network celebrities is accidentally supported by sing-box, it is not part of AnyTLS.
• Known issue: Due to V2Ray's infrastructure, if ALPN is unspecified or is an empty array, ALPN h2 and http/1.1 (rather than no ALPN) will be used. This may not be consistent with other implementations of AnyTLS. When uTLS is used, the ALPN of uTLS fingerprint will be used.

NaïveProxy

NaïveProxy. An HTTP/2 CONNECT tunnel or HTTP/3 CONNECT tunnel that reuses Chromium's network stack, multiplexes traffic by HTTP/2 or HTTP/3, and enables length padding through negotiation.

• Installing a standalone plugin is required. Please direct to NaïveProxy project and download the NaïveProxy Plugin for SagerNet derivatives distributed by NaïveProxy project.
• The format of extra headers:

  Key1: value1
  Key2: value2
  

  The app will replace LF (\n) by CRLF (\r\n) automatically.
• Proxying UDP is not supported.

Why not use cronet-go to eliminate the need for plugin?

• F-Droid requires that non-asset binaries be compiled from source, and the toolchains (except for some specific ones) for compilation must also be compiled from source. Therefore, statically linking the cronet-go binaries is not feasible, and compiling from source is also practically impossible (it requires using the Chromium Clang toolchain, which is distributed in binary form).
• Unusual characteristics caused by older versions of Chromium should be avoided. Chromium releases a new major version every month, then NaïveProxy follows Chromium, and cronet-go then follows NaïveProxy. cronet-go's update progress is almost certainly always behind the upstream. Even if cronet-go kept up with the upstream progress, this software would still need frequent new releases to update the built-in cronet-go.

mieru

mieru version 3. A proxy protocol with the characteristic of random traffic, and with multiplexing, random padding and replay protection. "mieru" is the name of its client. Its server is called "mita".

• "Server port" will be ignored if "server port range" is not empty. A port within the port range is selected randomly.
• The format of port range:

  1037-1137
  1237-1337
  

• Protocol "TCP" uses TCP to transmit both TCP and UDP. Protocol "UDP" uses a custom reliable UDP protocol to transmit both TCP and UDP.

TUIC

TUIC Protocol, version 5. It uses QUIC Stream to relay TCP, and QUIC Stream (UDP relay mode quic, but a separate stream for each UDP packet) or QUIC Datagram (UDP relay mode native) to relay UDP.

• If not specified, the client and server of the original official implementation of TUIC and its derivatives do not use ALPN, but the client and server of mihomo use ALPN h3. You need to explicitly set ALPN to h3 to connect to a mihomo server.
• It is "highly recommended" to disable "zero-RTT handshake" as it is vulnerable to replay attacks. This does impact much on the performance.
• Due to the flawed authentication mechanism, this protocol has several active detection issues, which can be accurately distinguished from normal QUIC on server side.

Juicity

Juicity Protocol. It uses QUIC Stream to relay both TCP and UDP.

• This protocol has active detection issues consistent with TUIC, which can be accurately distinguished from normal QUIC on server side.

SOCKS

SOCKS4 proxy (CONNECT), SOCKS4A proxy (CONNECT) and SOCKS5 proxy (CONNECT and UDP ASSOCIATE).

• SOCKS5 supports no authentication and username/password authentication only. So-called GSSAPI authtication is not supported (although it is nominally a "MUST"). SOCKS4 and SOCKS4A support no authentication and username authentication. BIND is not supported.
• The length of username and the length password for SOCKS5 username/password authentication needs to be 1 to 255, but many username/password authentication implementations allow empty username and/or empty password. If you need to connect to a SOCKS5 server that uses username/password authentication with empty username and empty password, please use a custom outbound configuration.

HTTP

HTTP/1.1 CONNECT tunnel, and HTTP/1.1 CONNECT tunnel with TLS. HTTP/2 CONNECT tunnel will be used if TLS is enabled and ALPN negotiates h2.

• 'Basic' authentication is supported. Proxying UDP is not supported.
• A typical HTTP/2 CONNECT tunnel server is Caddy with forwardproxy plugin.
• V2Ray (as a HTTP CONNECT tunnel server) does not support HTTP/2, but includes ALPN h2 in negotiation, causing clients fail to connect when ALPN h2 is negotiated. Set the ALPN of client to http/1.1 to avoid this.
• Known issue: There is no distinction between "basic authentication not enabled" and "basic authentication enabled with empty username and empty password". If you need to connect to an HTTP server that uses basic authentication with empty username and empty password being, please use a custom outbound configuration.

HTTP/3

HTTP/3 CONNECT tunnel.

• 'Basic' authentication is supported. Proxying UDP is not supported.
• A typical HTTP/3 CONNECT tunnel server is Caddy with forwardproxy plugin.
• Known issue: There is no distinction between "basic authentication not enabled" and "basic authentication enabled with empty username and empty password". If you need to connect to an HTTP/3 server that uses basic authentication with empty username and empty password being, please use a custom outbound configuration.

TrustTunnel

TrustTunnel Protocol. This is in fact a proxy protocol, rather than a so-called "VPN protocol" as its developer claims.

• For TCP, it is a standard HTTP/2 CONNECT tunnel or HTTP/3 CONNECT tunnel. For UDP, it uses a private UDP over TCP magic address protocol.
• Its private ICMP echo over TCP magic address protocol and private health-check over TCP magic address protocol are not implemented by this software.

SSH

SSH-2 dynamic port forwarding. password authentication and public key authentication are supported.

• This protocol does not support proxying UDP traffic. Those SSH forks with private UDP protocol support and without changing the name are not part of SSH.
• The private key for the authentication type "public key" is in PEM format or OpenSSH format.
• The format of public key: one per line. Example:

  ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl
  ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCj7ndNxQowgcQnjshcLrqPEiiphnt+VTTvDP6mHBL9j1aNUkY4Ue1gvwnGLVlOhGeYrnZaMgRK6+PKCUXaDbC7qtbW8gIkhL7aGCsOr/C56SJMy/BCZfxd1nWzAOxSDPgVsmerOBYfNqltV9/hWCqBywINIR+5dIg6JTJ72pcEpEjcYgXkE2YEFXV1JHnsKgbLWNlhScqb2UmyRkQyytRLtL+38TGxkxCflmO+5Z8CSSNY7GidjMIZ7Q4zMjA2n1nGrlTDkzwDCsw+wqFPGQA179cnfGWOWRVruj16z6XyvxvjJwbz0wQZ75XK5tKSb7FNyeIEs4TT4jk+S4dhPeAUC5y+bDYirYgM4GC7uEnztnZyaVWQ7B381AK4Qdrwt51ZqExKbQpTUNn+EjqoTwvqNj4kqx5QUCI0ThS/YkOxJCXmPUWZbhjpCg56i+2aB6CmK2JGhn57K5mj0MNdBXA4/WnwH6XoPWJzK5Nyu2zB3nAZp+S5hpQs+p1vN1/wsjk=
  ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg=
  

• Known issues: There is no distinction between "no authentication" and "password authentication with empty password", and there is no distinction between "no private key passphrase" and "empty private key passphrase". If you need to connect to such SSH servers, please use a custom outbound configuration.

WireGuard

User-space WireGuard used as a proxy (TCP and UDP) rather than a VPN.

• This protocol is a VPN protocol rather than a proxy protocol, and is not designed for bypassing firewalls. It is not the main function of this software. Since it requires userspace conversion from the network layer to the transport layer and then to the network layer, it is only barely working in this software, please do not complain about its poor performance.
• The format of "Local address": one per line.
• The format of "Reserve" field : 0,0,0 (or Base64 format: AAAA). "Reserve field" is used for Cloudflare WARP (usually obtained through abusive methods).
• Xray supports leaving local address blank and using non-standard WireGuard key pairs that are not supported by other software. These are not supported by this software, and you need to resolve this compatibility issue yourself.

ShadowTLS

ShadowTLS v2 and v3. Yet another protocol that bahaves as if it performs a TLS handshake with a legit website. Some target websites will treat this behavior as harassment.

• This protocol does not support proxying UDP traffic.
• It is not a complete protocol that can be used independently. The usual usage to construct a proxy chain with protocols like Shadowsocks.
• This protocol can be distinguished from normal TLS on server side.
• ShadowTLS v2 does not support X25519MLKEM768 TLS key agreement.

ShadowsocksR

A fork of Shadowsocks with various obfuscation header added in early years.

• The "protocol" and "obfuscation"^{[1] [2]} supported by this software is the same as those in Clash. It is supported by this software only because it is supported by SagerNet.
• This protocol is obsolete and not censorship-resistant at all.
• tls1.2_ticket_auth is an alias of tls1.2_ticket_fastauth in Clash.

Mux

TCP "multiplexing". It is actually a private protocol named Mux.Cool invented by V2Ray that carries other proxy protocols, and is not part of Shadowsocks, Trojan, etc.

• It is incompatible with and not related to other popular "multiplex" protocols (e.g. sing-mux, Smux).
• Mux.Cool operates on UDP in the form of "UDP over TCP".
• This protocol uses the domain name v1.mux.cool as the magic address. mux.cool is an existing real domain name rather than a reserved one. While it appears to be controlled by V2Fly members and not used, this will not always be true and could cause issues if it is actually used in the future.
• What's worse, this protocol was forked by Xray and became part of XUDP and became mandatory in XTLS, while the magic address remains unchanged.

PacketEncoding

• Due to protocol design flaw, for VMess, VLESS and Mux.Cool, only the first packet of a UDP socket can carry the destination address because of design flaw. Some sub-protocols (i.e. "XUDP" and "Packet") that use magic address and are not forward-compatible are needed to carry the destination address in each and every packets correctly. These sub-protocols are not part of the original protocols.
  • Other correctly-designed protocols (e.g. Shadowsocks, Trojan, SOCKS, etc.) do not have this protocol design flaw and do not need "packetEncoding".
• Due to infrastructure design flaw, even correctly-designed protocols are also affected by the above issue in V2Ray and Xray.
  • V2Ray internally optionally applies "packetEncoding" to these protocols to "solve" this infrastructure design flaw, and makes domain-based or IP-based or port-based routing rules ineffective for traffic with "packetEncoding" enabled.
  • This software “solves” this infrastructure design flaw by using an approach similar to of Xray rather than use the approach of V2Ray, thus "packetEncoding" setting does not exist in such protocols.
• XUDP: Seen in Xray.
  • "Global ID" and "UoT Migration" is not supported.
  • Xray enforces XUDP in many ways, so some software uses XUDP for VLESS-related protocols, even if not explicitly set.
• Packet (PacketAddr): Seen in V2Ray.
  • Due to design flaw in this sub-protocol, its destination address only supports IPv4 and IPv6. It is not possible to use domain name as the destination address without extending the current sub-protocol. This software does not apply this sub-protocol when the destination address of UDP is a domain name.

Transport

"Transport" (a.k.a. "network", "transport protocol", "transport layer", "transport layer protocol", "underlying transport", "underlying transport protocol" and "V2Ray transport", etc.) is in fact a bunch of additional private protocols invented by V2Ray and Xray to carry other proxy protocols. They are not part of the original protocols (e.g. Trojan and Shadowsocks) and has contaminated the name and specification of other protocols.

• These "transports" only support proxying TCP and are not applied to UDP.
• Not all permutations of protocols and "transports" are valid.
• Do NOT use CDN-abusing protocols if NOT backed into a corner.

TCP (No transport)

The confusing name "TCP" actually means no additional "transport" is attached. Also known as "RAW" in Xray.

HTTP obfuscation

"TCP transport" has an additional "header obfuscation" setting, which allows you to append some HTTP headers and camouflage it as HTTP, but it is not compatible with the original "TCP transport".

• The format of Host and path: one per line.
• If Host is not specified, www.baidu.com and www.bing.com are used (indeed), but non-V2Ray/Xray may not have this behavior and you may need to explicitly set Host to the server address in order to connect to some servers.
• This is called "HTTP transport" in Clash/mihomo. In sing-box, this is "HTTP transport" without TLS.
• HTTP obfuscation can be easily distinguished from normal HTTP(S) services.

KCP

Also known as "mKCP". It is actually a private protocol hackily modified from KCP and incompatible with KCP. Rob bandwidth by sending packets violently.

• If seed is specified, traffic will be obfuscated using XOR, which has been proven to be accurately identifiable. If seed is specified, traffic will be obfuscated using the AES-128-GCM algorithm. Seed cannot be used to ensure the security of communication content.
• "Obfuscation header type" is basically some poor quality obfuscations that are not censorship-resistant.
• Xray made breaking changes, split XOR obfuscation and AES-128-GCM obfuscation out of KCP, leading to the emergence of a KCP transport that neither uses XOR obfuscation nor uses AES-128-GCM obfuscation and a KCP transport that uses AES-128-GCM obfuscation with empty password. They are incompatible with the original KCP transport and they are not supported by this software.

WS

Also known as "WebSocket". It is actually a private protocol based on WebSocket. It is usually used for abusing Cloudflare CDN.

• It has additional "early data" settings for "RTT reduction".
• If "early data header name" is empty, early data is appended to path (invented by V2Ray, not supported by Xray).
• If "early data header name" is not empty, early data is appended to header (invented by Xray, which uses an early data header name of Sec-WebSocket-Protocol; V2Ray supports customize early data header name).
• Xray uses max early data as part of path (?ed=[number]) rather than use a new field. This is not supported by this software and you need to remove the ?ed=[number] part of the path and correctly fill in "max early data" and "early data header name".
• If Host is not specified but SNI is specified, Xray uses SNI rather than server address as Host. You need to resolve this compatibility issue yourself.
• Browser forwarding: Use Android System WebView to forward WebSocket to achieve the goal of "using browser fingerprint".
  • If you use a custom config, you need to connect with a browser yourself and exclude the browser from per-app VPN.
  • Please download v2ray-extra.zip from v2ray-core and put index.html and index.js into Android/data/[package name]/files, or import them as route assets.

HTTP

Also known as "H2". This confusing name actually means HTTP/2.

• The format of host: one per line. www.example.com will be used if not specified.
• This is called "H2 transport" in Clash/mihomo. In sing-box, this is "HTTP transport" with TLS.

QUIC

It is actually a private protocol based on QUIC.

• If ALPN is not specified, h2, http/1.1 are used as the ALPN (indeed). You need to explicitly set ALPN h3 to connect to a sing-box server. Changing this behavior will cause failed ALPN negotiation with origin V2Ray.
• If TLS is not enabled, a self-signed certificate will be issued and TLS will be enabled with quic.internal.v2fly.org as the SNI, rather than exit with errors. Other implementations likely do not have such a weird behavior.
• "QUIC encryption" is basically pointless duplicate encryption.
• "Obfuscation header type" is basically some poor quality obfuscations that are not censorship-resistant.

GRPC

Also known as "GUN". Derived from a PoC with the same name to abuse CDN with gRPC. It is actually a private protocol based on gRPC. It is usually used for abusing Cloudflare CDN.

• It is not recommended to use characters other than A-Z, a-z, 0-9, _ and . in "service name".
• Xray made breaking changes, uses URL-escaped service name, and uses service name starting with "/") to indicate custom path. Enabling "gRPC service name compatibility" will make such a service name compatible with Xray and break the compatibility with non-Xray.
• Xray made breaking changes and invented "multi mode" which is incompatible with the original protocol. Enable "multi mode" to connect to such a Xray server. Server name is always compatible with Xray if "multi mode" is enabled.
• Other breaking changes made by Xray are not supported.

HTTPUpgrade

Derived from Tor pluggable transport "WebTunnel" (or the opposite). It is designed to mislead Cloudflare into thinking it is WebSocket and abuse Cloudflare CDN.

• Xray uses ?ed=[number] as part of path (rather than use a new field) to indicate that "0-RTT" should be used. You need to remove the ?ed=[number] part of the path.
• V2Ray additionally supports setting "early data" to achieve the goal of "RTT reduction". Early data is used as a header.
• If Host is not specified but SNI is specified, Xray uses SNI rather than server address as Host. You need to resolve this compatibility issue yourself.

Meek

Derived from Tor pluggable transport "meek" and can be used for domain fronting. Its speed is limited. It is designed to encapsulate traffic into HTTP/1.1 GET/POST communications to abuse almost any CDN.

XHTTP

Previously known as "SplitHTTP". It is designed to encapsulate uplink traffic into HTTP POST requests and encapsulate downlink traffic into stream-style HTTP GET requests. It uses packet-style uplink (packet-up) to abuse almost any CDN, and stream-style uplink (stream-up and stream-one) to abuse Cloudflare CDN.

• stream-up and stream-one will add gRPC header to mislead Cloudflare into thinking it is gRPC in order to facilitate abusing Cloudflare CDN. stream-one is an incompatible fork of "HTTP transport".
• Because Xray often makes breaking changes to this protocol, if this software is not updated (or you are using an older version of this software), you may not be able to connect to a newer version of Xray server.
• A client with Mux enabled is not accepted by an Xray XHTTP server. So do not enable Mux on client side when using this protocol.
• To prevent Xray servers from providing differentiated treatment or even refusing to provide services for non-Xray clients, this software partially supports the extra parameter that is used by the server to restrict the behavior of the client. Features like upstream/downstream separation, etc. that do not affect the ability to connect to the server are not supported by this software. (Upstream/downstream seperation besides sockopt is supported in custom config, but you can not simply copying Xray's extra without modification.)
• Browser forwarding (browser dialer): Use Android System WebView to forward HTTP to achieve the goal of "using browser fingerprint".
  • If you use a custom config, you need to connect to a browser yourself and exclude the browser from per-app VPN.
  • Most of the TLS parameters are ignored (see Xray documentation for details).

Mekya

May be a typo of Mekya or the opposite. A blend of meek and KCP. Designed to abuse almost all CDNs and rob bandwidth by sending packets violently.

Hysteria2

Also known as "hy2". Use part of Hysteria 2 and its QUIC library as a "transport".

• It uses Brutal "congestion control" to rob bandwidth in a way that does not comply with QUIC congestion control if upload speed or download speed is set. Do NOT set upload speed and download speed to use BBR congestion control rather than the bandwidth-robbing Brutal "congestion control".
• It should be noted that BBR congestion control (specifically v1) completely ignores packet loss mechanisms after a specific bandwidth is detected, which can lead to serious fairness issues in some cases. This has been effectively resolved in BBR v3, but Hysteria 2 only implements BBR v1 currently.

TLS

• SNI: Server Name Indication. If empty, server address will be used.
  • This field in fact means ServerName (used for both verification and name indication) in Go standard TLS library (or the uTLS library), not SNI.
• ALPN: Application Layer Protocol Negotiation. Format: one per line.
  • V2Ray's default ALPN behavior (if ALPN is not specified or is an empty array) is chaotic, you may need to set the appropriate ALPN.
• Skip certificate verification: Known as "allow insecure" in V2Ray. Enabling this option without deploying other security measures leads to the success of man-in-the-middle attacks. Do NOT enable unless you know what you are doing.
• Certificate: Fill in the fullchain certificate text in PEM format. Do not use system root certificate list and only trust the specified certificate.
• Pinned certificate/certificate public key/certificate chain SHA256:
  • If used without "skip certificate verification", the certificate hash value will be verified in addition to the normal certificate verification process. This can be used to prevent man-in-the-middle attacks by certificate authorities when the certificate authorities' reputation is questionable.
  • If used with "skip certificate verification", the normal certificate verification process will be skipped and the certificate hash values will be verified directly. This can be used to prevent man-in-the-middle attacks when one has to use an invalid certificate. You should configure trust instead of using these fields for untrusted certificates.
  • Pinned certificate SHA-256: The more common "certificate SHA-256 fingerprint" format (hex encoding). The value of this field can be obtained by openssl x509 -in fullchain.cer -noout -fingerprint -sha256 (with all colons removed).
  • Pinned certificate public key SHA-256: The more common "certificate public key SHA-256 fingerprint" format (Base64 encoding). The value of this field can be obtained by openssl x509 -in <cert.pem> -pubkey -noout | openssl dgst -sha256 -binary | openssl enc -base64.
  • Pinned certificate chain SHA-256: A private format (Base64 encoding) of certificate chain fingerprint invented by V2Ray. The value of this field can be obtained by v2ray tls certChainHash --cert <cert.pem>.
  • They needs to be used together with "skip certificate verification" if the certificate itself is untrusted or invalid. When using "pinned certificate/certificate public key/certificate chain SHA-256", even if a user does not disable certificate verification, some proxy software in fact disables certificate verification for them, causing some users mistakenly think they can use invalid certificates without disable certificate verification.
  • "Pinned certificate SHA-256" and "pinned certificate public key SHA-256" usually means pinning the leaf certificate. However, some popular proxy software changed its meaning and allows it to be used as pinning intermediate certificate or pinning root certificate. This software is not compatible with such behavior.
  • Supporting these custom authentication logic with similar purpose is bad. It is only because they are not convertable, some servers are unwilling to configure them well, and one can only connect to the server insecurely without them.
• mTLS: Mutual TLS. Fill in the certificate text in PEM format and the certificate private key text in PEM format. Some popular proxy software can configure the server into requiring the client to provide a certificate for mutual verification, but this in fact leads to incompatibility with the original protocol and breaks interoperability among various implementations.
• uTLS fingerprint: Use uTLS library to imitate the TLS Client Hello of some popular browsers.
  • This helps circumvent censorship of TLS Client Hello fingerprinting, but also exposes some additional patterns because of parroting (as The Parrot is Dead). Do not use if the fingerprint of Go is not blocked, and do not rely on it as a long-term solution if you have to use it.
  • Unavailable for QUIC-based protocols.
• ECH Config: Fill it with ECH Config in Base64 format to enable Encrypted Client Hello. If ECH is enabled but ECH Config is not filled, direct DNS will be used to query HTTPS record to obtain ECH Config. If obtaining ECH Config fails, connection will be terminated.

REALITY

Yet another TLS-like protocol that bahaves as if it performs a TLS handshake with a legit website. Some target websites will treat this behavior as harassment.

• Similar ideas and actual code like this protocol had appeared (e.g. Cloak, circa 2019) before the appearance of this protocol (circa 2023).
• Because Xray hardcodes its version code into the protocol field and its servers can be configured to refuse providing services to clients that do not meet their version code requirements, this software hardcodes an Xray version code in the protocol field and the hardcoded Xray version code may cause some Xray servers refuse to provide services for you.
• This protocol relies on specific TLS key agreements. It has made and will have to continuously make breaking changes to adapt for new TLS key agreements. Enable "disable REALITY X25519MLKEM768" if the target website supports X25519MLKEM768 and you are using a uTLS fingerprint that supports X25519MLKEM768 and the server does not support the breaking change of REALITY X25519MLKEM768.
• Short ID: Usually used by servers to provide differentiated treatment or even refuse to provide services for various clients.
• uTLS fingerprint: Use uTLS library to imitate the TLS Client Hello of some popular browsers. Xray enforces uTLS for this protocol.
• Xray explicitly disallows using REALITY with WS or HTTPUpgrade, but sing-box does not have this restriction. No matter how, such usage is not recommended.

Proxy chain

Order: front proxy (entry node) is at the top and landing proxy (exit node) is at the bottom. Incompatible with load balancing.

• Shadowsocks with SIP003 plugin can be the front proxy only.
• A proxy with WebSocket browser forwarding or XHTTP browser forwarding enabled can be the front proxy only.
• WireGuard can be the landing proxy only (not sure this is the expected behavior or a bug).

Load balancing

Strategy: Random, leastPing, and leastLoad. Incompatible with proxy chain.

Custom config

Configs exported by this software can be a reference. You may need to read the source code for this. Document contributions welcome.

Custom config (full)

V2Ray (the modified version by this software) JSONv4 configuration. Half-baked V2Ray JSONv5 configuration is not supported.

• Some parameters in a full configuration are enforced to be modified to make them work on Android. See SagerNet document * Custom config (V2Ray).

Custom config (outbound)

V2Ray (the modified version by this software) JSONv4 OutboundObject.

• Unsupported fields are ignored. Global settings in software are applied.

Protocols that exist in this software but are not supported

These protocols do exist in this software but are not shown to the users by default, and may get changed or removed at any time (bug reports are still accepted). You need to enable them through "experimantal flags" yourself if you must use them.

sing-uot (v2)

This is a magic address private protocol for UDP over TCP (also known as "UoT") invented by sing-box. It is NOT part of the original protocol (i.e. Shadowsocks, Shadowsocks 2022, TUIC, SOCKS5, SOCKS4A and NaïveProxy).

UDP over stream: This is the variant on QUIC of the private UDP over TCP protocol v2 from sing-box. It uses QUIC Stream to relay UDP.

sing-mux

This is a magic address private protocol for multiplexing from sing-box. It is NOT part of the original protocol (i.e. Shadowsocks, Shadowsocks 2022, Trojan, VMess and VLESS).

sing-mux operates on UDP in the form of "UDP over TCP", so it conflicts with sing-uot. If you must enable both of them, TCP will use sing-mux and UDP will use sing-uot.

• h2mux: The mutiplexing mechanism from Go HTTP/2 library is used.
• smux: Smux is used.
• yamux: Yamux is used.
• Padding: Pad TLS handshake to mitigate so-called "TLS in TLS" issue. You should only enable "padding" for protocols based on TLS (or REALITY). This "padding" is largely inspired by the padding mechanism from NaïveProxy.
• Brutal: The port of Hysteria's bandwidth-robbing Brutal "congestion control" on TCP. This functionality is intentionally not supported by this software.

ShadowQUIC

A QUIC-like protocol. The variant of "stealing" the TLS certificates of other websites on QUIC.

JLS is used to bahave as if it performs a QUIC handshake with a legit website. Some target websites will treat this behavior as harassment.

Installing a standalone plugin is required.

SunnyQUIC

It is the "twin protocol" of ShadowQUIC. It provides an authentication mechanism at the QUIC layer instead of using JLS to authenticate.

This protocol has active detection issues consistent with TUIC, which can be accurately distinguished from normal QUIC on server side.