Has anyone encountered that xhttp doesn't live longer than 30 minutes on ios?

A proper english translated version of this article would be much appreciated.

所以在线路质量（来去程）都很好的情况下， xhttp+Reality 方案 和 xtls-rprx-vision+Reality 方案的区别是什么

1，便利角度？都可以做到不需要自己的域名
2，性能角度？自己测下来速度差不多，xhttp的延迟略高~
3，安全稳定可靠性角度？前者可套CDN，后者不行

是这样理解么？

When using xhttp+Reality does it have tls-in-tls characteristics which have been solved previously with "flow": "xtls-rprx-vision"?

有配置例子么

中文 | Русский | English

XHTTP: Beyond REALITY

Development Brief: In mid-2024, @mmmray, @ll11l1lIllIl1lll, and others, based on the "packetized uplink, streaming downlink" principle and implementation details described by @RPRX, developed SplitHTTP. This marked the first time penetration of most HTTP-supporting middleboxes was achieved without sacrificing downlink efficiency, and the first large-scale implementation of QUIC H3 over CDN, ushering in a new era. Browser Dialer support, header padding for feature reduction, XMUX for multiplexing control, and REALITY unlocking were subsequently implemented. Later, @RPRX took over development, implementing true uplink/downlink separation and renaming it XHTTP. For example, uplink could be IPv6 CDN H3, while downlink could be IPv4 REALITY H2 (even with different source IPs). Now this marks another new era. Following this, the stream-up mode (streaming uplink without sacrificing efficiency) and the extra scheme for sharing full configuration details were developed. Default gRPC header spoofing was added to stream-up mode, achieving H2 streaming uplink through CDNs, replacing the traditional gRPC transport layer. If we had known this worked back then, gRPC transport might not have existed. Finally, the HTTP transport layer was integrated into XHTTP as the stream-one mode, granting it features like header padding, XMUX, and gRPC header spoofing. Thus, we have the complete XHTTP: various methods for penetrating middleboxes, uplink/downlink separation, smooth XMUX, and more are all included. The era of XHTTP for all scenarios has officially arrived.

Originally intended as a director's cut document, it accidentally turned into an article. This article aims to help you thoroughly understand the principles and design of XHTTP for better usage.

If you wish to donate to the Xray project or collect NFTs, relevant information is at the end of the article. Thank you for your support!

Quick Start Guide

Don't be intimidated by XHTTP's many parameters; they mostly have well-tuned default values. If you just want to use XHTTP, follow these six steps:

1. Whether using TLS or REALITY, generally, you only need to fill in the path for XHTTP configuration; leave others blank.
2. If the server supports QUIC H3, simply select "h3" for the client's alpn to use QUIC.
3. For CDN IP optimization, fill the client's address with the IP and serverName (SNI) with the domain name.
4. If you can't connect to Cloudflare (CF), enable gRPC support in the CF dashboard.
5. If you can't penetrate Nginx, change Nginx's proxy_pass to grpc_pass.
6. If you can't penetrate other CDNs or reverse proxy software, it's recommended to choose mode as "packet-up" for maximum compatibility.

XHTTP uses multiplexing by default. Its latency is lower than Vision, but multi-threaded speed tests might perform worse unless \"maxConcurrency\": 1 is set beforehand. Refer to the XMUX section.

CF will terminate HTTP connections with no actual downlink data for 100 seconds. Long-lived proxy connections require application-level keep-alives, e.g., setting ClientAliveInterval in sshd for SSH.

This article can serve as an enhanced documentation, covering almost everything you might want to know about XHTTP, with explanations for each parameter. A configuration example covering all parameters, annotated with use cases, is provided at the end. If you're unsure about a parameter, search for its name within the text to find its detailed explanation.

Two Underlying Logics

Just as REALITY can disguise itself as another website, the fundamental logic of anti-censorship is to increase the "collateral damage" for the censor when enforcing blocks, making them hesitant to block rashly. My past optimism about TLS and obfuscating traffic timing/length features on top of TLS followed the same principle. Years of experience tell us that the GFW won't permanently block entire IP ranges of large CDNs, as it would affect too many legitimate websites. Therefore, for XHTTP, our initial goal was to hide it behind a multitude of diverse CDNs. However, to protect origin servers from attacks, CDNs (except those with special support for WS, gRPC) typically buffer the entire HTTP request before sending it to the origin. Many HTTP middleboxes also default to this behavior. Based on this, Tor's Meek protocol wrapped round-trip traffic into individual HTTP requests to penetrate these middleboxes, but the speed was abysmal because it didn't adopt XHTTP's "streaming downlink". What is "streaming downlink"? Imagine downloading a large file from a website. If the CDN misses the cache and has to fetch it from the origin, it clearly can't buffer the entire file like it might for uploads, making you wait. Instead, as data arrives from the origin, the CDN forwards it to you immediately. This is the foundation of XHTTP's "streaming downlink", ensuring that the crucial downlink speed can be maximized. As for the uplink, for compatibility reasons, XHTTP first implemented "packetized uplink," wrapping uplink traffic into individual POST requests. Its efficiency is obviously compromised, but fortunately, uplink traffic is minimal for typical proxy usage. Later, I added "streaming uplink," and we discovered that adding gRPC header spoofing allowed H2 streaming uplink to penetrate CF. After several rounds of optimizing "packetized uplink," its speed even approached that of "streaming uplink."

Incidentally, let's touch upon the recurring question of whether using CDNs constitutes "abuse": Clearly, CDNs that don't support streaming uplink weren't intended for building proxy services. However, in our fight against the GFW, continuously exploring, developing, and utilizing as many new avenues as possible is reasonable, necessary, and done out of necessity. Furthermore, increasing the censor's "collateral damage" requires us to blend in with "normal" services, which is also unavoidable. Take the simplest example: if IP whitelisting happens someday and CDN IPs are included, would you use them or not? Some rules of the physical world don't apply in the field of anti-censorship, yet some people consistently fail to grasp this simple truth. If you still don't get it, consider transport layers like WebSocket, which now exist primarily for CDN tunneling. As a developer, you could remove it; as a user, you could suggest developers remove it, proving through your actions that "abusing CDNs" isn't just another excuse born from envy to attack Xray, driven by some pathological need for daily pointless drama, while their actions betray their words while revealing their hypocritical nature without difficulty.

PACKET-UP

This subsection contains many technical details. Non-developers can focus on the bold text.

For XHTTP's most compatible mode, "packetized uplink, streaming downlink" (packet-up mode), we designed it as follows:

1. Client sends POST /yourpath/sameUUID/seq to transmit uplink data:

   • The UUID is randomly generated and identical to the UUID used when initiating the downlink, allowing the server to associate them. If the server fails to associate within 30 seconds, the session is terminated.
   • seq starts from 0. The next POST's body can only be sent after the previous POST's body has been fully sent (no need to wait for the response).
   • Multiple POSTs might arrive at the server out of order (small probability). The server reassembles them based on seq, buffering up to 30 by default. Exceeding the limit results in disconnection.
   • Note that UUID and seq are designed into the path, not the query string, to avoid strange issues.

2. Client sends GET /yourpath/sameUUID to initiate downlink. The server response headers include:

   • X-Accel-Buffering: no to instruct middleboxes to disable buffering.
   • Cache-Control: no-store to instruct middleboxes not to cache.
   • Content-Type: text/event-stream to spoof as server-sent events (for better compatibility; can be disabled with noSSEHeader).
   • If using HTTP/1.1, it also includes Transfer-Encoding: chunked. H2/H3 do not require this.

3. To avoid cross-origin restrictions with Browser Dialer, the server includes the following in response headers for all GET and POST requests:

   • Access-Control-Allow-Origin: *
   • Access-Control-Allow-Methods: GET, POST

4. To address the fixed-length characteristics of HTTP request and response headers:

   • Client request headers default to including Referer: ...?x_padding=XXX... (placed in Referer to prevent unnecessary OPTIONS requests from Browser Dialer). The default length is 100-1000 bytes, randomized per request. The server defaults to checking if it falls within the server's allowed range.
   • Server response headers default to including X-Padding: XXX.... The default length is 100-1000 bytes, randomized per response.
   • This is the header padding I've mentioned multiple times, corresponding to the xPaddingBytes setting.
   • Moving request padding to Referer was suggested by @rPDmYQ, as was using XXX. X is 8 bits in Huffman encoding.

Packetized uplink and Referer: ...?x_padding=XXX... generate numerous, lengthy log entries. You can configure your reverse proxy software not to log them.

Additionally, like other Xray transport layers, the server accepts the X-Forwarded-For header to obtain the client's real IP. It also checks the host sent by the client against the server's configured host (my personal advice is not to set it unless necessary, as it's already hidden behind the path).

The above outlines the simplified, essential process for packet-up mode. However, a small question remains: how to specifically implement and limit POST requests? There are three dedicated parameters:

• scMaxEachPostBytes: Maximum data payload per POST from the client, default 1,000,000 (1MB). This value should be less than the maximum allowed by CDNs and other HTTP middleboxes. The server will also reject POSTs larger than this value.
• scMinPostsIntervalMs: Client-side only, per proxy request. Minimum interval between client POST requests, default 30 milliseconds.
• scMaxBufferedPosts: Server-side only, per proxy request. Maximum number of POST requests the server will buffer, default 30. Exceeding the limit results in disconnection.

"Per proxy request" means each proxy request has its own counters and limits, independent of others, even if they share the same H2 / H3 connection. This is the meaning of sc (sub-connection). To reduce fingerprinting, the first two values can be set as ranges (e.g., strings "500000-1000000" and "10-50", respectively), randomized each time. These parameters can be distributed to the client via extra (explained at the end). Furthermore, it's worth mentioning that the latest Xray version optimizes packet-up, with speeds even approaching stream-up, primarily benefiting QUIC H3 over CDN.

H1 / H2 / H3

Now that we have the packet-up mode, capable of penetrating almost all HTTP middleboxes, let's discuss something interesting: QUIC H3 over CDN, the "new era" ushered in by SplitHTTP. Understanding this section is crucial for flexible XHTTP usage.

A characteristic of many HTTP middleboxes is HTTP version conversion. For instance, CDNs and Nginx might convert incoming H3 traffic to H1 or H2 before forwarding it to the origin. This means our XHTTP server can listen only for H1 and H2 (no need to listen for H3), yet the XHTTP client can still use H3.

This is also the default behavior of the XHTTP server: listen only on TCP ports and handle H1 and H2 traffic. When TLS is enabled and alpn is set to only contain "h3", the server will exclusively use quic-go to listen on UDP ports and handle H3 traffic. However, doing this directly is currently not recommended. Instead, you should hide XHTTP behind a real Nginx or Caddy to reduce fingerprint characteristics. This is one of XHTTP's significant advantages over other QUIC-based proxies, the other, of course, being the ability to traverse CDNs. Additionally, H3's congestion control is implemented at the application layer, meaning you could theoretically modify the QUIC congestion control algorithms in these reverse proxy software and recompile them, to achieve the aggressive packet sending some desire.

For the XHTTP client:

1. When TLS/REALITY is enabled, H2 is used by default, otherwise HTTP/1.1 is used.
2. When TLS is enabled, if alpn only contains "http/1.1", HTTP/1.1 is used (but Xray won't allow this to modify the uTLS browser fingerprint spoofing).
3. When TLS is enabled, if alpn only contains "h3", quic-go H3 is used.
4. However, when using Browser Dialer, the specific HTTP version is determined by the browser (the entire tlsSettings becomes ineffective).

If you need to confirm the actual HTTP version, host, XHTTP mode, uplink/downlink separation status, etc., used by the Xray client, set the log level to "info".

Proxied QUIC H3 over CDN, at least on a large scale, was first achieved by XHTTP, opening a new path. After all, some regions and carriers have lax inspection for H3, though others might quickly kill it (QoS). Even after we developed the stream-up mode and discovered that adding gRPC header spoofing could penetrate CF, this only applied to H2, so it seems the significance of that "new era" continues to grow.

XMUX

Since we've mentioned H2 and H3, we must discuss their multiplexing: both are 0-RTT. The difference is H3 doesn't suffer from H2's TCP head-of-line blocking and supports connection migration (clients don't disconnect when changing networks). Now, friends who frequently peruse RFCs might ask: How do we specifically control their multiplexing? We've designed a concise yet powerful interface, XMUX:

• maxConcurrency: Maximum number of concurrent proxy requests within a single TCP/QUIC connection. Once the number of proxy requests in a connection reaches this value, the core establishes a new connection to accommodate more requests. When all XMUX settings are 0, this defaults to a random value between "16-32".

• maxConnections: Maximum number of concurrent connections. Before reaching this value, each new proxy request opens a new connection. Afterward, the core starts reusing existing connections. This conflicts with maxConcurrency; only one can be chosen. Default is 0 (unlimited). Supports ranges for randomization.

• cMaxReuseTimes: Maximum number of times a connection can be reused. After being reused this many times, it won't be assigned new proxy requests and will disconnect after its last internal proxy request closes. Default is 0 (unlimited). Supports ranges for randomization.

• hMaxRequestTimes: @xqzr discovered that Nginx defaults to allowing a maximum of 1000 cumulative HTTP requests per TCP/QUIC connection. When all XMUX settings are 0, this defaults to a random value between "600-900", otherwise it defaults to 0 (unlimited). This limit is based on HTTP request counts. Generally, stream-one generates one HTTP request, stream-up generates two, and packet-up generates N. This counting isn't strictly precise, and Golang's GET requests have automatic retries, so setting it to the absolute maximum isn't recommended. Limits for CDNs etc., need testing. For packet-up, if the uplink POST loop exceeds this value, it automatically switches to another TCP/QUIC connection, consuming one reuseTimes count but not affecting concurrency. Given the default XMUX values, stream-* modes won't hit the limit, but packet-up might. Since packet-up is the default mode for H3, this addition primarily benefits H3.

• hMaxReusableSecs: @xqzr discovered that Nginx defaults to allowing a TCP/QUIC connection to be reused for a maximum of one hour. When all XMUX settings are 0, this defaults to a random value between "1800-3000" seconds, otherwise it defaults to 0 (unlimited). After a TCP/QUIC connection has been active for this duration, it won't be assigned new HTTP requests and will disconnect after its last internal HTTP request closes. For packet-up, if the uplink POST loop exceeds this duration, it automatically switches to another TCP/QUIC connection, consuming one reuseTimes count but not affecting concurrency.

• hKeepAlivePeriod: Interval (in seconds) at which the client sends keep-alive packets on an idle H2 / H3 connection. Default is 0, which means Chrome H2's 45 seconds or quic-go H3's 10 seconds. This is the only XMUX parameter that doesn't allow ranges (randomizing this is a fingerprint) and allows negative values (e.g., -1 disables idle keep-alives). It's recommended to leave it at 0.

These XMUX parameters can be combined for various uses, like setting \"maxConcurrency\": 1 before multi-threaded speed tests, or \"maxConnections\": 1 for "infinite" reuse. Even if you don't bother studying them, when all these values are 0, the three default values mentioned above are used, effectively cycling through new H2/H3 primary connections periodically, resulting in a very smooth experience, unlike the "stalling" sometimes experienced with gRPC or HTTP transports that reuse the same connection indefinitely. Similarly, these parameters can be distributed to the client via extra.

Note: Leaving all fields blank is equivalent to setting them all to zero, triggering the three defaults. However, if you set any one XMUX parameter, the others will not have default values; you must specify all desired non-zero parameters. Except for the first two (maxConcurrency and maxConnections), the other parameters can be set simultaneously.

Additionally, do not enable mux.cool when using XHTTP. Newer Xray server versions already check for and accept only pure XUDP.

Regarding XMUX defaults, some excerpts:

• I specifically chose two options that are less visible outside of TLS: maxConcurrency and cMaxReuseTimes (instead of maxConnections and cMaxLifetimeMs). Both default to random ranges, minimizing potential fingerprints.
• I chose maxConcurrency over maxConnections precisely to prevent the connection count from becoming a fixed pattern. Of course, you can manually set the latter if you prefer.

• XMUX and Nginx count different things. maxConcurrency and cMaxReuseTimes are based on "proxied connections". Only stream-one generates one HTTP request, stream-up (one uplink, one downlink) generates two, and packet-up generates N.
• However, I'm unsure if stream-one might automatically generate extra HTTP requests under certain conditions. Also, I don't think pursuing indefinite reuse on a single connection is very meaningful. If you were an ISP, you'd also rate-limit or clear out old connections; otherwise, resources would be slowly consumed by them. That's why XMUX's default parameters limit reuse and periodically switch connections.

Some Nginx parameters were discussed elsewhere (implied, not explicitly linked in the original text).

STREAM-UP/ONE

Finally, we arrive at XHTTP's other important mode: stream-up ("streaming uplink, streaming downlink"). As the name suggests, the uplink in this mode is also streaming, thus not sacrificing uplink efficiency. It was originally developed for REALITY until we discovered that adding a gRPC header spoofing to H2 could penetrate CF (requires enabling gRPC support in the CF dashboard), and support from reverse proxies like Nginx was also good (Nginx recommends grpc_pass for simplicity). Therefore, the default behavior for mode: "auto" is:

• Client: stream-up for TLS H2, stream-one for REALITY (stream-up if downloadSettings is present), otherwise packet-up.
• Server: Defaults to accepting all three modes. If set to a specific mode, it accepts only that mode. "stream-up" is an exception; it also accepts stream-one.

stream-up has slightly better compatibility than stream-one. Some users reported that enabling streaming uplink on CFT allows stream-up, but another option needs to be enabled for stream-one (perhaps due to the SSE spoofing?). Another CDN (name forgotten) was observed to severely throttle stream-one but not stream-up.

Their implementation methods are (non-developers can skip):

• For stream-up, the packetized uplink of packet-up is replaced with a streaming POST /yourpath/sameUUID. It also includes Referer: ...?x_padding=XXX....
• For stream-one, a POST /yourpath/ is sufficient. The response body carries the downlink data (bidirectional streaming). Both request and response headers have padding.
• Note: For stream-one, if /yourpath is specified, the actual request is to /yourpath/. A trailing / is automatically added if missing.
• Uplink requests default to including Content-Type: application/grpc to spoof as gRPC (can be disabled with noGRPCHeader).
• The server response headers for the downlink are identical to packet-up's step 2. For stream-one, this results in the curiosity of an SSE response to a gRPC request. If issues arise, try noSSEHeader.

Testing related to this comment found that CF terminates HTTP connections with no actual downlink data for 100 seconds, causing stream-up's uplink direction to be cut off. Therefore, this PR added scStreamUpServerSecs to the server, defaulting to a random value between "20-80" seconds. The server sends xPaddingBytes of padding data at this interval to keep the connection alive.

Setting \"scStreamUpServerSecs\": -1 disables this mechanism. In this case, the server won't even send response headers promptly, matching the behavior of older versions.

Now, friends who frequently use gRPC might ask: what advantages does stream-up have over the gRPC transport layer?

• The former requires no gRPC library, resulting in better performance.
• The former's downlink traffic uses a separate GET request, avoiding CDN restrictions specific to gRPC traffic.
• The former also benefits from enhancements like header padding, XMUX, uplink/downlink separation, etc., and has adopted the extra mechanism for sharing all parameters, making it more mature.

Of course, the advantages of XHTTP compared to WebSocket or HTTPUpgrade, besides "lacking the conspicuous ALPN 'http/1.1' feature", should be clear by now, so I won't list them all, mainly because there are too many to list easily.

Uplink/Downlink Separation

Taking the final spotlight is another new era: Uplink/Downlink Separation. We roughly know that current GFW detection for features like TLS-in-TLS is based on single connections. Therefore, if we split the uplink and downlink across different inspection systems, for example, uplink via IPv4 TCP and downlink via IPv6 UDP, the GFW might be temporarily confused. Since the XHTTP server associates uplink and downlink based solely on the random UUID in the path, packet-up and stream-up inherently possess true uplink/downlink separation capabilities. Coupled with XHTTP's ability to penetrate various CDNs and work with REALITY, the possible configurations are limitless. For the client, this requires setting downloadSettings:

"xhttpSettings": {
    "host": "example.com",
    "path": "/yourpath", // must be the same
    "mode": "auto",
    "extra": {
        "headers": {
            // "key": "value"
        },
        "xPaddingBytes": "100-1000",
        "noGRPCHeader": false, // stream-up/one, client only
        "noSSEHeader": false, // server only
        "scMaxEachPostBytes": 1000000, // packet-up only
        "scMinPostsIntervalMs": 30, // packet-up, client only
        "scMaxBufferedPosts": 30, // packet-up, server only
        "scStreamUpServerSecs": "20-80", // stream-up, server only
        "xmux": { // h2/h3 mainly, client only
            "maxConcurrency": "16-32",
            "maxConnections": 0,
            "cMaxReuseTimes": 0,
            "hMaxRequestTimes": "600-900",
            "hMaxReusableSecs": "1800-3000",
            "hKeepAlivePeriod": 0
        },
        "downloadSettings": { // client only
            "address": "", // another domain/IP
            "port": 443,
            "network": "xhttp", // must be "xhttp"
            "security": "tls", // or "reality"
            "tlsSettings": {
                // ...
            },
            "xhttpSettings": {
                "path": "/yourpath", // must be the same
                // ... other XHTTP params specific to download if needed
            },
            "sockopt": {} // will be replaced by upload's "sockopt" if the latter's "penetrate" is true
        }
    }
}

As you can see, downloadSettings is essentially a completely new streamSettings block, but with added address and port fields (similar to VLESS outbound) to point to another entry point. Clearly, network must be "xhttp" (cannot be omitted), and security can be "tls" or "reality". The sockopt settings can also be shared, but the receiving client can set penetrate: true in the uplink's sockopt to override the downlink's sockopt, suitable for scenarios involving mark. Apart from this exception, when using uplink/downlink separation, the downlink configuration is completely independent and does not inherit any settings from the uplink. Furthermore, for instance, even if both uplink and downlink use default XMUX values (by leaving them unset), the specific values rolled within their respective ranges are independent and unrelated. This way, over time, the multiplexing patterns of uplink and downlink become completely asymmetrical, and their primary connection switching times differ, enhancing anti-analysis effects. If the GFW were to target uplink/downlink separation, "identical primary connection initiation times" would surely be the most critical entry point, so future XHTTP versions will also allow initiating uplink and downlink connections at different times from the start.

In fact, if you are using a CDN, you might not even need to modify the server configuration to play with uplink/downlink separation. For example, you could optimize for an IPv4 address for TLS H2 uplink and optimize for an IPv6 address for QUIC H3 downlink. Moreover, most CDNs support "same-domain domain fronting". For example, set uplink serverName to "a.example.com", downlink serverName to "b.example.com", and both uplink and downlink host to "c.example.com". This makes the external SNIs appear different as well. Of course, if you already have two domains, that's even better. If you don't have any domains, you could set up two VPSs, run two REALITY instances, and achieve uplink/downlink separation: whether through CDN plus reverse proxy, or REALITY plus fallback, as long as the traffic ultimately reaches the same XHTTP inbound on the same VPS via the same path, it works. In short, because XHTTP can be used everywhere, the number of possible combinations is infinite; the only limit is your imagination.

For example, since the advent of uplink/downlink separation, many users employ it to direct uplink traffic through routes with better outbound performance and downlink traffic through routes with better inbound performance, which is quite practical.

For instance, you could further set \"maxConnections\": 1 for the uplink and \"maxConcurrency\": 1 for the downlink. This achieves sending the small amount of uplink data over a single underlying connection, while distributing the large amount of downlink data across different underlying connections, simultaneously offering anti-censorship, low latency, and high speed, somewhat like a Switch. Pairing it with Vision Seed yields even better results.

The configuration example shown above, covering all parameters, is primarily to demonstrate where each setting should be placed and to explain parameters not extensively covered earlier:

• extra is the raw JSON sharing scheme for all parameters except host, path, and mode. When extra is present, only these four top-level parameters take effect. Share links typically only contain these four, and GUIs usually only expose these four, because parameters within extra are relatively low-frequency and should be directly provided ("distributed") by the service publisher to the client, not arbitrarily changed by the client.
  Clarification: "Distributed" means the service publisher prepares the extra JSON and includes it entirely within the share link. The client uses this directly as their own extra.

• The behavior of host is consistent with other HTTP-based transport layers in Xray. The client sends the host with the following priority: host > serverName > address. If the server has host configured, it will check if the client-sent value matches; otherwise, no check is performed. It's recommended not to set it unless necessary. host cannot be placed inside headers.

If you need to confirm the actual HTTP version, host, XHTTP mode, uplink/downlink separation status, etc., used by the Xray client, set the log level to "info".

Beyond REALITY

Early last year, I returned and wrote the all-conquering REALITY, solving multiple pain points at once, and then spent my days partying and didn't manage it much, even the introductory article is still unfinished, XUDP UoT Migration is even more regrettable, the article was nearly done last year but never published. Unbeknownst to many, REALITY has quietly become the mainstay for direct connections. It's common to see recommendations to switch to REALITY in comments below posts about XX getting blocked. Its reputation speaks for itself, it's even become less lively around here because it's too stable. Although Xray has made numerous optimizations and improvements for other transports, XHTTP is the first native Xray transport layer, and the first one made quite a splash. Having read this article, you now understand that XHTTP can be used together with REALITY:

Beyond REALITY doesn't mean replacing REALITY, but surpassing it in popularity. It's no exaggeration to say that, in typical Xray fashion, the emergence of XHTTP has made all other HTTP-based transport layers pale in comparison. This is the era of XHTTP for all scenarios. It will become more popular than the previous successful protocol, REALITY, because XHTTP's features inherently dictate a broader reach.

Finally, I hope the arrival of XHTTP brings a little shock and awe, just as Xray has done multiple times in its history: Revolution, innovation, pushing the envelope – these remain Xray's creed.

If this article was helpful, consider supporting with a REALITY NFT:

• Total supply of one thousand, the first hundred sold at 0.01 ETH. Later prices will increase. Grabbing one from the initial batch is a steal.
• An article introducing REALITY will be published in the next few days Became an introduction to XHTTP.
• Holding a REALITY NFT grants early beta access to a new Xray client and an airdrop for the next NFT, just like
• Holding a Project X NFT on 2025.1.1 will grant two REALITY NFTs.

Thanks to everyone's support, the Project X NFT has increased five to six times in value. For those who hesitated during the Project X NFT launch, this is a good opportunity to make up for it.

Of course, if you have the means, supporting with a Project X NFT would be even more appreciated:

• ETH/USDT/USDC: 0xDc3Fe44F0f25D13CACb1C4896CD0D321df3146Ee
• Project X NFT: Announcement of NFTs by Project X #3633
• REALITY NFT: https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2
• Sometimes ETH gas fees are absurdly high. You can favorite it first and buy when gas fees are relatively normal.

If anything is still unclear, please leave a comment below, and I will update the article. Suggest not releasing translations too early.

How about implementing a packet-up mode that utilizes a single stream for uploading large chunks (512KB–1MB) sequentially, with the option to reuse the stream for subsequent uploads? This would eliminate the need for the server to buffer chunks while maintaining efficiency. I suggest this because my upload performance has significantly improved after setting scMaxBufferedPosts to 1. Stream reuse should be optional and configurable for better flexibility.

上下行分离。 我们大概知道，现在 GFW 针对 TLS in TLS 等流量特征的检测是基于单条连接，那么如果我们把上下行拆分到不同的审查系统，比如上行跑 IPv4 的 TCP，下行跑 IPv6 的 UDP，GFW 就会一时反应不过来

Am I right that the stream‑one mode of XHTTP is more vulnerable than xtls-rprx-vision, particularly when combined with Reality and domain stealing? I am especially referring to the TLS-in-TLS problem, against which XHTTP opposes the uplink/downlink separation, which is not present in the stream‑one mode. At first glance, it seems that xtls-rprx-vision is still superior when it comes to Reality without the uplink/downlink separation applied.

XHTTP: Beyond REALITY

Development Overview:
In mid-2024, developers like @mmmray and @ll11l1lIllIl1lll, building on the "packetized upstream, streaming downstream" principles outlined by @RPRX, introduced SplitHTTP. This innovation allowed for efficient penetration of most HTTP-supporting middleboxes without sacrificing downstream performance. It also marked the first large-scale implementation of QUIC H3 over CDN, opening a new chapter in proxy technology. Features like Browser Dialer support, header padding to reduce traffic fingerprints, XMUX for multiplexing control, and REALITY integration were added soon after.

Later, @RPRX took over development, achieving true upstream and downstream separation and renaming the protocol to XHTTP. This allowed upstream and downstream traffic to use entirely different configurations, such as IPv6 CDN H3 for upstream and IPv4 REALITY H2 for downstream, even with different source IPs. This innovation marked another leap forward.

Subsequent developments included the stream-up mode, which improved upstream efficiency, and the extra configuration scheme, enabling users to share detailed settings. The stream-up mode was further enhanced with gRPC header camouflage, enabling H2 streaming upstream through CDNs, effectively replacing traditional gRPC transport layers. Finally, the HTTP transport layer was integrated into XHTTP as stream-one mode, inheriting features like header padding, XMUX, and gRPC header camouflage.

With these advancements, XHTTP became a complete solution: capable of bypassing middleboxes in various ways, supporting upstream and downstream separation, and offering smooth multiplexing. The era of XHTTP as a universal, all-scenario proxy solution had officially begun.

Quick Start Guide

Although XHTTP offers many configuration options, its default settings are optimized for most use cases. To get started, follow these six steps:

1. For both TLS and REALITY, you generally only need to configure the path. Leave other fields blank.
2. If the server supports QUIC H3, set the client’s alpn to "h3" to enable QUIC.
3. For optimized CDN IPs, set the client’s address to the IP and serverName (SNI) to the domain name.
4. If you cannot connect to Cloudflare (CF), enable gRPC support in the CF panel.
5. If Nginx blocks the connection, change proxy_pass to grpc_pass in the Nginx configuration.
6. If other CDNs or reverse proxies block the connection, set the mode to "packet-up" for maximum compatibility.

By default, XHTTP supports multiplexing (XMUX), which reduces latency compared to Vision. However, multi-threaded speed tests may show lower performance unless you set "maxConcurrency": 1 before testing. Refer to the XMUX section for details.

Additionally, if you are using the v2rayN&G client, disable the global mux.cool setting before using XHTTP. Otherwise, it may fail to connect to the latest Xray server.

This article serves as an enhanced guide, covering everything you need to know about XHTTP. It explains each parameter in detail and includes a comprehensive configuration example at the end, with usage scenarios for each parameter. If you are unsure about a parameter, search for its name in this document to find a detailed explanation.

Core Principles

The fundamental logic of anti-censorship technologies like XHTTP is to increase the "collateral damage" for censors when implementing blocks. This makes them hesitant to block traffic indiscriminately. For example, REALITY disguises proxy traffic as legitimate website connections, forcing censors to risk blocking real websites if they attempt to block the proxy.

Similarly, XHTTP leverages the fact that the Great Firewall (GFW) is unlikely to permanently block the entire IP range of a major CDN, as doing so would disrupt too many legitimate websites. The goal of XHTTP is to blend proxy traffic into the vast pool of normal CDN traffic.

However, CDNs are designed to protect origin servers from attacks. Unless specifically configured (e.g., for WebSocket or gRPC), most CDNs cache the entire HTTP request before forwarding it to the origin server. Many HTTP middleboxes behave similarly.

Protocols like Tor’s Meek wrap traffic into discrete HTTP requests to bypass these middleboxes, but this approach sacrifices speed. Meek lacks XHTTP’s "streaming downstream" capability, which ensures high downstream performance.

What is "Streaming Downstream"?

Imagine downloading a large file from a website. If the CDN doesn’t have the file cached, it fetches it from the origin server. Instead of waiting to cache the entire file, the CDN forwards the data to you as it receives it. This real-time forwarding is the foundation of XHTTP’s streaming downstream, ensuring maximum downstream speed.

What about Upstream?

For compatibility, XHTTP initially implemented "packetized upstream", which splits upstream traffic into discrete POST requests. While this approach is less efficient, upstream traffic is typically minimal for most proxy use cases.

Later, streaming upstream was introduced, allowing real-time upstream data transfer. By adding gRPC header camouflage, XHTTP enabled H2 streaming upstream through Cloudflare (CF). After several optimizations, the speed of packetized upstream now rivals that of streaming upstream.

PACKET-UP Mode

Packet-up mode is XHTTP’s most compatible configuration, combining packetized upstream with streaming downstream. Here’s how it works:

Upstream (Client to Server):

1. The client sends upstream data via POST /yourpath/sameUUID/seq:
   • UUID is randomly generated and reused for downstream traffic to associate the session. If the server cannot associate the session within 30 seconds, it terminates the connection.
   • seq starts at 0. The client must finish sending the body of one POST before starting the next (though it doesn’t need to wait for a response).
   • Multiple POSTs may arrive out of order. The server reassembles them based on seq, caching up to 30 requests by default. If the limit is exceeded, the connection is terminated.
   • Both UUID and seq are included in the path (not the query string) to avoid compatibility issues.

Downstream (Server to Client):

2. The client starts downstream by sending GET /yourpath/sameUUID. The server responds with:
   • X-Accel-Buffering: no to disable buffering by middleboxes.
   • Cache-Control: no-store to prevent caching by middleboxes.
   • Content-Type: text/event-stream to disguise the response as server-sent events (SSE). This improves compatibility but can be disabled with the noSSEHeader setting.
   • For HTTP/1.1, the response includes Transfer-Encoding: chunked. This is unnecessary for H2/H3.

Cross-Origin Compatibility:

To avoid cross-origin restrictions when using Browser Dialer, the server includes the following headers in all GET and POST responses:

• Access-Control-Allow-Origin: *
• Access-Control-Allow-Methods: GET, POST

Header Padding:

To address the fixed-length characteristics of HTTP headers:

• The client appends ?x_padding=000... to the path. The padding length is randomized (100–1000 characters by default) for each request.
• The server includes a X-Padding: 000... header in its responses, with randomized padding of similar length.

Key Parameters for Packet-Up Mode

1. scMaxEachPostBytes:

   • Maximum data per POST request (default: 1MB). This should be less than the maximum allowed by the CDN or middlebox.

2. scMinPostsIntervalMs:

   • Minimum interval between POST requests (default: 30ms).

3. scMaxBufferedPosts:

   • Maximum number of POST requests the server can buffer (default: 30).

These parameters can be randomized to reduce traffic fingerprints. For example, scMaxEachPostBytes can be set as "500000-1000000", and scMinPostsIntervalMs as "10-50".

H1 / H2 / H3

Now that we have the packet-up mode, which can penetrate almost all HTTP middleboxes, let's discuss something interesting: QUIC H3 over CDN, the new era that SplitHTTP initially ushered in. Understanding this section is crucial for using XHTTP effectively.

A characteristic of many HTTP middleboxes is that they perform HTTP version conversion. For example, CDNs and Nginx may convert incoming H3 traffic to H1 or H2 traffic when forwarding to the origin. This means our XHTTP server can listen only for H1 and H2, without needing to listen for H3, but the XHTTP client can still use H3.

This is also the default behavior of the XHTTP server: it listens only on TCP ports and handles H1 and H2 traffic. When TLS is enabled and only one element, "h3", is set in alpn, the server will only use quic-go to listen on UDP ports and handle H3 traffic. However, it is currently not recommended to do this. Instead, you should hide XHTTP behind a real Nginx or Caddy to reduce fingerprint characteristics. This is one of the important advantages of XHTTP compared to other QUIC-based proxies. Another advantage, of course, is the ability to go through CDNs. In addition, H3's congestion control is implemented at the application layer. In theory, you can modify the QUIC congestion control algorithm of these reverse proxy software and compile them to achieve the aggressive packet sending that some people want.

For the XHTTP client:

• When TLS/REALITY is enabled, H2 is used by default; otherwise, HTTP/1.1 is used.
• When TLS is enabled, if alpn only has "http/1.1", then HTTP/1.1 is used (but Xray will not allow it to modify the uTLS browser fingerprint camouflage).
• When TLS is enabled, if alpn only has "h3", then quic-go H3 is used.
• However, when you use Browser Dialer, the specific HTTP version is determined by the browser (the entire tlsSettings will be invalid).

If you want to confirm the HTTP version, host, XHTTP mode, upstream and downstream separation, and other information actually used by the Xray client, set the log level to "info".

At least for large-scale implementation of proxying QUIC H3 over CDN, XHTTP is the first. It opened a new path, as some regions and operators do not strictly censor H3, although some may block it. Even though we later developed the stream-up mode and found that adding gRPC header camouflage can penetrate Cloudflare (CF), it only works for H2. It seems that the value of this new era is still rising.

XMUX

Since we mentioned H2 and H3, we have to talk about their multiplexing: both are 0-RTT. The difference is that H3 does not have the TCP head-of-line blocking problem of H2, and it supports connection migration, so the client will not disconnect when switching networks. Those who often read RFCs may ask: how to specifically control their multiplexing? We designed a concise and powerful interface, XMUX:

• maxConcurrency: The maximum number of proxy requests that can exist simultaneously in each TCP/QUIC connection. When the number of proxy requests in a connection reaches this value, the core will establish a new connection to accommodate more proxy requests. When all XMUX values are 0, this item defaults to "16-32", randomized each time.
• maxConnections: The maximum number of connections that can exist simultaneously. Before the number of connections reaches this value, each new proxy request will open a new connection. After that, the core will start to reuse existing connections. This value conflicts with maxConcurrency and only one can be chosen. The default value is 0, which means no limit. It supports filling in a range, randomized each time.
• cMaxReuseTimes: The maximum number of times a connection can be reused. After being reused this many times, it will not be assigned new proxy requests and will be disconnected after the last internal proxy request is closed. When all XMUX values are 0, this item defaults to "64-128", randomized each time.
• cMaxLifetimeMs: The maximum "lifespan" of a connection. After this time, it will not be assigned new proxy requests and will be disconnected after the last internal proxy request is closed. The default value is 0, which means no limit. It supports filling in a range, randomized each time.
• hMaxRequestTimes: @xqzr found that Nginx by default allows each TCP/QUIC connection to carry a total of 1000 HTTP requests. When all XMUX values are 0, this item defaults to a random value between "800-900"; otherwise, it defaults to 0, which means no limit. This item is based on HTTP request counting. Generally, stream-one generates only one HTTP request, stream-up generates two, and packet-up generates N. This item's counting is not strict, and Golang's GET requests have automatic retries, so it is not recommended to fill it to the maximum. You need to test those CDNs. When packet-up's upstream loop POST exceeds this value, it will automatically switch to another TCP/QUIC connection, occupying one of its reuseTimes but not concurrency. Actually, according to the three default values of XMUX, stream-* will not exceed the limit, only packet-up will, and it is the default mode of H3, so adding this item mainly benefits H3.
• hKeepAlivePeriod: When the H2/H3 connection is idle, the client sends a keep-alive packet every few seconds. The default is 0, which is Chrome H2's 45 seconds or quic-go H3's 10 seconds. It is the only item in XMUX that does not allow filling in a range (randomizing this item is a characteristic) and allows filling in a negative number (for example, filling in -1 turns off idle keep-alive packets). It is recommended to leave it at 0.

The parameters provided by XMUX can be combined in various ways. For example, set "maxConcurrency": 1 before a multi-threaded speed test, and set "maxConnections": 1 for "infinite" reuse. Even if you are too lazy to study, it's okay. When these values are all 0, the three default values mentioned above will be taken, which is equivalent to changing to a new H2/H3 main connection after a period of time. It's very smooth, and there will be no "stuttering" experience caused by gRPC and HTTP transport layers always reusing the same connection. Similarly, these parameters can be distributed to the client through extra.

Note: If you don't fill in anything, it is equivalent to all zeros, and the three default values will be taken. But if you fill in any item, the other items will not have default values, and you need to fill them all yourself, except for the first two items, which can be filled in simultaneously.

In addition, do not enable mux.cool when using XHTTP, and the new version of the Xray server has a check to accept only pure XUDP.

Regarding the default values of XMUX, some excerpts:

• I specifically chose two options that are not easily detectable outside of TLS, namely maxConcurrency plus cMaxReuseTimes (instead of maxConnections plus cMaxLifetimeMs), and the default values of these two options are both ranges taken randomly, eliminating potential characteristics to the greatest extent.
• I chose maxConcurrency instead of maxConnections to prevent the number of connections from becoming a fixed pattern. Of course, if you like the latter, you can also set it manually.
• XMUX and Nginx count different objects. maxConcurrency and cMaxReuseTimes are both based on the "proxied connection" count. Only stream-one will generate one HTTP request, while stream-up has two, one upstream and one downstream, and packet-up has N.
• However, I am not sure if stream-one will automatically generate an additional HTTP request under certain circumstances. Also, I think there is not much point in pursuing the reuse of a connection to the end because if you are an operator, you will also limit the speed and clean up old connections, otherwise, resources will be slowly occupied by old connections. Therefore, the default parameters of XMUX are to limit reuse + periodically change connections.

There is also a discussion of some Nginx parameters below the article.

STREAM-UP/ONE

Finally, we come to another important mode of XHTTP: stream-up, which is "streaming upstream, streaming downstream". As the name suggests, the upstream of this mode is also streaming, so it will not sacrifice upstream efficiency. It was originally developed for REALITY until we found that adding a gRPC header to disguise H2 can penetrate Cloudflare (CF) (gRPC support needs to be enabled in the panel), and the support of reverse proxy software such as Nginx is also good (Nginx recommends grpc_pass, which is simple and convenient). So the behavior of the default value "auto" of mode is:

• Client: stream-up for TLS H2, stream-one for REALITY (stream-up when there is downloadSettings), otherwise packet-up.
• Server: By default, it accepts all three modes. If set to a specific mode, it only accepts that mode. "stream-up" is an exception, it also accepts stream-one.
• stream-up has better compatibility than stream-one. Some users said that they can use stream-up when CFT enables streaming upstream, but they need to enable another option to use stream-one (maybe it's the fault of SSE camouflage?). I also saw a CDN (forgot the name) that severely limits the speed of stream-one but not stream-up.

Their implementation methods are (non-developers can skip):

• For stream-up, change the packetized upstream of packet-up to streaming POST /yourpath/sameUUID, also with ?x_padding=000....
• For stream-one, POST /yourpath/ is enough, the response is downstream, bidirectional streaming, both request headers and response headers have header padding.
• Note that if stream-one fills in /yourpath, it actually requests /yourpath/. If there is no / at the end, it will be automatically added.
• Upstream defaults to Content-Type: application/grpc to disguise as gRPC (can be turned off by setting noGRPCHeader).
• The server response header for downstream is exactly the same as 1 of packet-up. stream-one will have the spectacle of responding to gRPC with SSE. If you encounter problems, you can try noSSEHeader.

Those who often use gRPC may ask: what are the advantages of stream-up over the gRPC transport layer?

• The former does not require any gRPC library and has better performance.
• The downstream traffic of the former is an independent GET request and is not subject to the traffic restrictions of CDN on gRPC.
• The former also has enhancements such as header padding, XMUX, and upstream and downstream separation, and has introduced the extra mechanism. All parameters can be shared and are more mature.

Of course, the advantages of XHTTP over WebSocket and HTTPUpgrade, in addition to "no significant characteristics of ALPN being http/1.1", I believe you have read this far, and you already have the answer in your heart. I will not list them one by one, mainly because there are too many to list.

Upstream and Downstream Separation

A groundbreaking advancement in XHTTP is upstream and downstream separation. The Great Firewall (GFW) typically analyzes traffic characteristics based on single connections. By splitting upstream and downstream traffic across different inspection systems, such as using IPv4 TCP for upstream and IPv6 UDP for downstream, the GFW's detection capabilities can be hindered.

XHTTP natively supports true upstream and downstream separation because it associates upstream and downstream traffic based on a randomly generated UUID in the path. This capability, combined with XHTTP's ability to penetrate CDNs and integrate with REALITY, offers a wide range of configuration possibilities.

To enable upstream and downstream separation on the client-side, configure downloadSettings:

"xhttpSettings": {
    "host": "example.com",
    "path": "/yourpath", // must be the same
    "mode": "auto",
    "extra": {
        "headers": {
            // "key": "value"
        },
        "xPaddingBytes": "100-1000",
        "noGRPCHeader": false, // stream-up/one, client only
        "noSSEHeader": false, // server only
        "scMaxEachPostBytes": 1000000, // packet-up only
        "scMinPostsIntervalMs": 30, // packet-up, client only
        "scMaxBufferedPosts": 30, // packet-up, server only
        "xmux": { // h2/h3 mainly, client only
            "maxConcurrency": "16-32",
            "maxConnections": 0,
            "cMaxReuseTimes": "64-128",
            "cMaxLifetimeMs": 0,
            "hMaxRequestTimes": "800-900",
            "hKeepAlivePeriod": 0
        },
        "downloadSettings": { // client only
            "address": "", // another domain/IP
            "port": 443,
            "network": "xhttp",
            "security": "tls",
            "tlsSettings": {
                ...
            },
            "xhttpSettings": {
                "path": "/yourpath", // must be the same
                ...
            },
            "sockopt": {} // will be replaced by upload's when in "extra"
        }
    }
}

downloadSettings is essentially a new set of streamSettings, but it includes address and port to specify a different entry point, similar to VLESS outbound.

• network must be set to "xhttp" (required).
• security can be "tls" or "reality".
• If sockopt is not specified, it inherits the upstream settings. Some sockopt parameters are specific to the local environment and may cause issues when shared. Therefore, if sockopt is in extra, it will be forced to inherit the upstream settings.

Except for this sockopt behavior, the downstream configuration is entirely independent and does not inherit any upstream settings. For example, even if both upstream and downstream use default XMUX values, the randomized values within the specified ranges will be independent. This results in asymmetrical multiplexing and different timings for switching main connections, further enhancing anti-analysis capabilities.

To counter upstream and downstream separation, the GFW would likely focus on the timing of main connection initiations. Future versions of XHTTP may allow initiating upstream and downstream connections at different times to address this.

Leveraging CDNs for Upstream and Downstream Separation

You can implement upstream and downstream separation even without modifying the server configuration if you are using a CDN. For example, you can use one optimized IPv4 for TLS H2 upstream and another optimized IPv6 for QUIC H3 downstream.

CDNs generally support "same-domain domain fronting". For instance:

• Upstream serverName: "a.example.com"
• Downstream serverName: "b.example.com"
• Both upstream and downstream host: "c.example.com"

This makes the external SNI appear different while still using the same domain. If you have two domains, it's even better.

If you don't have any domains, you can use two VPSs and two REALITY configurations for upstream and downstream separation. Whether using a CDN with a reverse proxy or REALITY with fallback, the key is to ensure that both upstream and downstream traffic reach the same XHTTP inbound on the same VPS using the same path.

XHTTP's versatility allows for countless combinations. The only limitation is your imagination.

A common use case for upstream and downstream separation is to route upstream traffic through a path with optimized outbound routing and downstream traffic through a path with optimized inbound routing.

Configuration Example and Explanation

The provided configuration example demonstrates the placement of each parameter:

• extra: A raw JSON sharing scheme for all parameters except host, path, and mode. When extra is present, only these four parameters are effective. Sharing links and GUI configurations typically only include these four parameters because extra parameters are less frequently used and should be provided directly by the service provider.
• "Distribution" means that the service provider configures the extra and includes it in the sharing link. Clients can then use the entire extra as their own.
• host: The client sends the host header in the following priority: host > serverName > address. If the server sets host, it checks if the client's value matches. Otherwise, no check is performed. It is generally recommended not to set host on the server. host cannot be placed in headers.

Beyond REALITY

REALITY, introduced last year, addressed several pain points and quickly became the primary choice for direct connections. Its stability and effectiveness have been widely recognized. While Xray has made numerous optimizations and improvements to other transports, XHTTP is the first native transport layer for Xray, and it's making a significant impact.

"Beyond REALITY" does not mean replacing REALITY but rather surpassing its popularity. XHTTP's versatility and comprehensive features make it a superior choice compared to other HTTP-based transport layers. It is poised to become even more popular than REALITY due to its broader applicability.

XHTTP continues Xray's tradition of innovation and transformation, bringing a powerful new tool to the anti-censorship arsenal.

Support the Project

If you find this information helpful, consider supporting the project by purchasing a REALITY NFT:

• There are 1,000 NFTs in total, with the first 100 priced at 0.01 ETH. Subsequent prices will increase.
• An article introducing REALITY will be released in the coming days.
• Holding a REALITY NFT grants early access to a new Xray client and an airdrop of the next NFT.
• Project X NFT holders as of January 1, 2025, will receive two REALITY NFTs.

Project X NFTs have already increased five to six times in value. This is an excellent opportunity for those who missed the initial Project X NFT offering.

If you have the means, supporting the project with a Project X NFT is also greatly appreciated:

• ETH/USDT/USDC: 0xDc3Fe44F0f25D13CACb1C4896CD0D321df3146Ee
• Project X NFT: Announcement of NFTs by Project X #3633
• REALITY NFT: https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2

If ETH gas fees are high, you can favorite the NFT and purchase it when gas fees are lower.

If you have any further questions, please leave a comment below, and I will update the article accordingly. It is recommended not to translate this article prematurely.

User Comments on This Discussion

fodhelper on Dec 5, 2024
It's rumored that some CDNs are acting against using their services for proxy (not on a large scale yet), maybe they had some agreements with governments.

As someone who doesn't want to get banned by CDNs, I prefer WebSocket or gRPC without /Tun, but not XHTTP with static URL patterns and xPaddingBytes query string with many 0s.
And I had hoped you would add XMUX to gRPC, but instead, you flagged it as deprecated.

RPRX on Dec 5, 2024
Your statement has some inaccuracies. First, the Cloudflare team responded that their new firewall automatically blocked Iranian IPs, which was done manually, and they did not target the proxy.
Second, WebSocket and gRPC do not prevent you from getting banned.

What else is their problem except the static Early-Data header key of WebSocket and the static /Tun path of gRPC? I am all ears.

Countermeasures should be studied when the CDN starts to target agents, and there is no point in fighting in advance or preparing for SHTF, not to wait until things go wrong and then start thinking about it and finding solutions. When it’s impossible to not have clear characteristics for CDN (or for GFW if the user wanted to not use TLS), there is no reason not to.

RPRX on Dec 6, 2024
I think the situation is not that simple, because the management of the proxy is very complex, and it requires you to prepare for many factors. These characteristics are inherently specific, such as the randomness of the number of connections, the overall flow characteristics, etc.

fodhelper on Dec 6, 2024
@RPRX, have you heard the news? Isn’t it time to act?
To hide proxy protocol headers, VMESS exists, and for abnormal overall traffic characteristics, split upload and download of XHTTP is there (Although I think removing obvious characteristics of transports is enough).
These options are needed to hide obvious characteristics of transports:

1. Option to set custom Early-Data header key for WebSocket.
2. Option to change XHTTP SessionID, Sequence Number, and xPaddingBytes position to URL, Query-String, or Headers (or even not to proxy protocol headers?).
3. Option to set a custom key name for each of them.
4. Option to change xPaddingBytes value from static numbers to full random data.

RPRX on Dec 18, 2024
@fodhelper, now that it’s early, if it’s proven that these factors have led to targeting, we will certainly attract measures.

fodhelper on Dec 18, 2024
It's something like "server: nginx" response header of nginx.
But alright, let’s see if CDNs can detect proxies using these obvious characteristics or not.

MossAndMaurice on Dec 6, 2024

Trying to understand the focus and logic behind the XTLS series of protocols. If there are any inaccuracies, please @RPRX for corrections.

XTLS (Initial Versions: splice/direct/origin, etc.) – Solving Performance Issues:

Traditional TLS over TLS introduces the overhead of double encryption. XTLS embeds or splices the inner TLS data directly and losslessly into the outer TLS stream, making it appear as a single-layer TLS on the surface while hiding proxy traffic. This reduces redundant encryption and decryption processes. Without compromising security, it significantly lowers CPU load and encryption/decryption costs, thereby improving performance.

VISION – Addressing TLS-in-TLS Characteristics:

In multi-layered TLS (TLS-in-TLS), the inner and outer TLS handshakes involve two separate interactions, creating a timing pattern that can be precisely identified by the GFW. VISION works by simulating delays and adjusting the message exchange sequence to smooth out these unnatural timing characteristics. This makes the multi-layered TLS handshake process appear more like genuine internet traffic, reducing the risk of detection.

REALITY – Solving the SNI Blocking Problem:

In mainland China, SNI (Server Name Indication) cannot be encrypted, allowing the GFW to identify and block traffic based on SNI. REALITY disguises the TLS handshake and certificate exchange process by returning certificates and initial data that appear to belong to legitimate websites during the handshake. This makes the entire TLS connection indistinguishable from a connection to a major HTTPS website. For the GFW to block such traffic, it risks mistakenly blocking real websites.

XHTTP – Addressing the "Single Tunnel" Characteristics of Proxy Protocols:

Traditional protocols (e.g., Shadowsocks, Vmess, Trojan) typically encrypt data and transmit it continuously through specific ports, creating a "stable, long-duration encrypted stream" characteristic. Censors can use statistical analysis, long connection patterns, and data transmission modes to suspect proxy traffic. XHTTP focuses on the application layer, further wrapping encrypted transmissions into what appear to be legitimate HTTP requests and responses. It splits upstream data into multiple seemingly normal POST requests with randomized parameters in the URLs, while downstream data is disguised as large file downloads or continuous SSE (Server-Sent Events) outputs. This makes traffic behavior closely resemble ordinary user browsing or downloading patterns. Unlike traditional "encrypted tunnels," XHTTP no longer appears as a stable, continuous data pipeline but as a series of independent, scattered, and natural HTTP interactions, mimicking common web access actions.

tomxiang1 on Dec 6, 2024

REALITY also solves the problem of server handshake negotiation, making it easy to disguise as a major server, so the GFW is hesitant to block it.

Ahmad-2213 on Dec 8, 2024

A specific question!
For those who are using Vless on workers/pages via WebSocket, is it possible to implement this protocol similarly on workers? Or does CF just support WebSocket?

RPRX on Dec 9, 2024

It seems that stream-one might work.

TheLordOfTheKings on Dec 8, 2024

Hi @RPRX, is it possible to have Vision Seed with XHTTP+REALITY in the future?

RPRX on Dec 9, 2024

That's the purpose of Seed.

RPRX on Dec 5, 2024

When discussing upstream and downstream separation, many people's approach is to prioritize upstream routes for upstream traffic and downstream routes for downstream traffic. This is quite practical.

zzlinwq on Dec 9, 2024

I think this is more understandable if you think of upstream as the process of going and downstream as the process of returning. Prioritize routes for going and returning separately. This is also practical. If it's IPv6 going, then return via IPv6; if it's IPv4 going, then return via IPv4.

zzlinwq on Dec 9, 2024

Does XHTTP require a domain certificate? If so, which one is better to apply for?

xqzr on Dec 9, 2024

IP certificates are also acceptable.

zzlinwq on Dec 10, 2024

Really? Which one should I apply for?

xqzr on Dec 10, 2024

ZeroSSL.

RPRX on Dec 10, 2024

I think this analogy of upstream as going and downstream as returning is more understandable. Prioritize routes for going and returning separately. This is also practical. If it's IPv6 going, then return via IPv6; if it's IPv4 going, then return via IPv4.

The next version will change to "prioritize upstream routes for upstream traffic."

iopq on Dec 10, 2024

Is it possible to split UDP and TCP connections? For example, I want UDP connections to go to a certain port, and TCP connections to go to 443.

RPRX on Dec 10, 2024

Routing.

iopq 3 weeks ago

Wait, does reality even support QUIC?
Also, if I set the client alpn to "h3," will it use QUIC? Does QUIC have any advantage for proxying UDP traffic (since it is based on UDP)?

GreatMichaelLee on Dec 10, 2024

I'm a bit confused, but I think this is a good feature for reality—users with complex needs. Can you organize a few user cases (like with CDN, without CDN, different configurations, etc.) for different scenarios and provide configuration examples? Then users can adjust based on their server and IP. Some users may not be able to configure it themselves, so having examples would be helpful. Is there a public group for users? I'm currently struggling with the biggest confusion about upgrading XHTTP. I don't know which to change or keep, and if two configurations conflict, I don't know how to arrange them.

RPRX on Dec 10, 2024

For small users, the "Quick Start Guide" in the article is enough. Basically, you only need to adjust path, alpn, and upstream and downstream separation is too complex for small users.

I'm still confused about stream-up and stream-one

what are the differences? Which one should I use with TLS XHTTP3?

Some time after configuring xHTTP, stream-one/stream-up modes stopped working. I use CF with gRPC enabled, grpc_pass is also enabled on nginx. Packet-up works fine, but the logs on the client periodically show an error:

protocol error: received DATA after END_STREAM

I have Xray 25.3.6 installed on the server. If anyone can help me figure this out, I would be extremely grateful.