Thank you for your contribution, but the existing code has the following issues:

First, in the outbound, connections should be created in DialContext and ListenPacketContext, just like in gun transport, instead of closing an already created connection in StreamConnContext.

Second, you should check the commit content and avoid modifying anything unrelated to this PR (including but not limited to formatting other files).

Finally, as mentioned in the previous PR, we need a working listener implementation; the current code still shows "xhttp listener is not implemented yet".

If these three issues are resolved, we will consider merging it.

Thanks for the review

I’ve pushed an update addressing the points you mentioned:

• moved xhttp connection creation to DialContext / ListenPacketContext (no longer closing connections inside StreamConnContext, now follows gun transport pattern)
• cleaned up commits and removed unrelated changes
• implemented a working xhttp listener (including Reality + HTTP/2 path)

Inbound tests are now passing:

• TestInboundVless_XHTTP
• TestInboundVless_Reality_XHTTP

Let me know if anything still looks off or needs to be adjusted.

It looks good, but there are a few minor modifications needed:

Since the XHTTP configuration items are only related to vless, they don't need to be placed in vmess.go.

Also, in transport/xhttp, please do not import net/http; please use github.com/metacubex/http directly. The same applies to golang.org/x/net/http2, all of which is provided in github.com/metacubex/http (exported starting with http.Http2).

Thanks for the detailed review - pushed an update.

• moved XHTTP config to VLESS-only
• removed all net/http usage from transport/xhttp
• switched HTTP/2 to github.com/metacubex/http
• removed the extra std handler path

Re-tested locally with:

• go build ./...
• go test ./listener/inbound -run XHTTP -v

Everything is passing now.

@Nemu-x I tested XHTTP and found that if I don’t specify x-padding-bytes: 100-1000, I get the following error:

connect error: xhttp stream-one bad status: 400 Bad Request

According to the documentation:
XTLS/Xray-core#4113

服务端发的 response header 均默认包含 X-Padding: XXX...，默认长度为 100-1000，每次响应随机
这便是我多次提及的 header padding，对应设置项为 xPaddingBytes

When using the Xray core directly without adding extra param to the URI, everything works fine.

My understanding is that this should be the default behavior and does not need to be explicitly configured.

Thanks.

ScMinPostsIntervalMs 和 ScMaxEachPostBytes 似乎并没有使用 只是声明了变量 实际没有任何调用 因为它们依赖xray内部的pipe机制 所以好像被一并删除了
虽然在这个只有h2简化实现并不构成使用问题 但是避免误导最好把它们删掉

Good catch, @xream
thanks.

Added a small follow-up fix so that x-padding-bytes defaults to 100-1000 when not set, to match Xray behavior.
#2647

@Fangliding

Thanks,

You're right - those two options are currently only declared/plumbed through, but not really implemented with the same behavior as Xray.

I'll remove scMinPostsIntervalMs and scMaxEachPostBytes to avoid misleading config support.

thanks @Fangliding

Those options were indeed only partially wired and could be misleading, so I removed them in a follow-up PR: #2648
Re-tested configs after removal, everything still works as expected.

Appreciate the review 👍

@Nemu-x
It seems there is a memory leak issue when using the XHTTP transport. I’ve been testing it since the release of the latest alpha version with support for it, and I noticed that memory usage grows significantly over several hours of operation. When Mihomo starts, RAM usage is around 140 MB with 70 active connections, but after 8 hours the memory consumption increases to about 400 MB with the same 70 active connections. I tested it on an OpenWRT x86_64 operating system.

@Nemu-x It seems there is a memory leak issue when using the XHTTP transport. I’ve been testing it since the release of the latest alpha version with support for it, and I noticed that memory usage grows significantly over several hours of operation. When Mihomo starts, RAM usage is around 140 MB with 70 active connections, but after 8 hours the memory consumption increases to about 400 MB with the same 70 active connections. I tested it on an OpenWRT x86_64 operating system.

Could you try using the implementation from #2649 ? So far it looks normal on my side. I've been running it on my Android phone, OpenWrt router, and a Linux PC, and I haven't observed abnormal memory growth yet. If the issue still persists after trying that version, let me know and I can try to look into it.

I’m ready to try it if you can provide me with a prebuilt Mihomo binary for Linux x86_64.

@Nemu-x It seems there is a memory leak issue when using the XHTTP transport. I’ve been testing it since the release of the latest alpha version with support for it, and I noticed that memory usage grows significantly over several hours of operation. When Mihomo starts, RAM usage is around 140 MB with 70 active connections, but after 8 hours the memory consumption increases to about 400 MB with the same 70 active connections. I tested it on an OpenWRT x86_64 operating system.

Thanks for the report

I’m currently testing this on my side with sustained traffic load. Will update here once I have more concrete results.

@Nemu-x It seems there is a memory leak issue when using the XHTTP transport. I’ve been testing it since the release of the latest alpha version with support for it, and I noticed that memory usage grows significantly over several hours of operation. When Mihomo starts, RAM usage is around 140 MB with 70 active connections, but after 8 hours the memory consumption increases to about 400 MB with the same 70 active connections. I tested it on an OpenWRT x86_64 operating system.

Thanks for the report

I’m currently testing this on my side with sustained traffic load. Will update here once I have more concrete results.

After about 12 hours of uptime, all XHTTP connections dropped, and the logs show HTTP errors.
At the moment the connections dropped, memory usage had exceeded 600 megabytes.

After about 12 hours of uptime, all XHTTP connections dropped, and the logs show HTTP errors. At the moment the connections dropped, memory usage had exceeded 600 megabytes.

Could you try this prebuilt binary: mihomo-linux-amd64-v3.zip On my side it has been running for more than a day without abnormal memory usage or connection drops. If the issue still happens on your side, could you dump some diagnostic information (logs, pprof, etc.) when it occurs and share it ? That might help us investigate the problem.

I’ve just installed your binary and will be testing it now.

@Nemu-x It seems there is a memory leak issue when using the XHTTP transport. I’ve been testing it since the release of the latest alpha version with support for it, and I noticed that memory usage grows significantly over several hours of operation. When Mihomo starts, RAM usage is around 140 MB with 70 active connections, but after 8 hours the memory consumption increases to about 400 MB with the same 70 active connections. I tested it on an OpenWRT x86_64 operating system.

Thanks for the report

I’m currently testing this on my side with sustained traffic load. Will update here once I have more concrete results.

@Nemu-x It seems there is a memory leak issue when using the XHTTP transport. I’ve been testing it since the release of the latest alpha version with support for it, and I noticed that memory usage grows significantly over several hours of operation. When Mihomo starts, RAM usage is around 140 MB with 70 active connections, but after 8 hours the memory consumption increases to about 400 MB with the same 70 active connections. I tested it on an OpenWRT x86_64 operating system.

Thanks for the report
I’m currently testing this on my side with sustained traffic load. Will update here once I have more concrete results.

After about 12 hours of uptime, all XHTTP connections dropped, and the logs show HTTP errors. At the moment the connections dropped, memory usage had exceeded 600 megabytes.

Thanks for the report, I’ve been testing this with sustained load and pprof.

I couldn’t reproduce a persistent memory leak so far:

• memory grows under load but drops after it stops
• heap diff shows negative growth in main HTTP2/TLS paths
• goroutine count also decreases after load

This was based on a ~1 hour soak test. I’ll now run a longer test (several hours) to check long-term behavior

Peak heap ~140MB → dropped to ~63MB after load

This looks more like connection churn than unreleased memory.

However, the too many open files error you reported is important - this may indicate FD / connection accumulation over long uptime.

I’ve attached pprof snapshots and memory stats from my test.
I’ll continue longer soak testing to see if it reproduces over time.

If you can reproduce again, pprof + FD count at failure point would help a lot.

heap-after.txt
heap-diff.txt
heap-start.txt
mem-all.txt

After about 12 hours of uptime, all XHTTP connections dropped, and the logs show HTTP errors. At the moment the connections dropped, memory usage had exceeded 600 megabytes.

If you don't mind, could you try this experimental build? mihomo-linux-amd64-v3.zip It has been running on my side for over a day without abnormal memory growth.If the problem still occurs with this build, it would be very helpful if you could dump some diagnostic information (logs, pprof, etc.) when it happens so we can further investigate.

After 2 hours of running your executable, everything looks good — memory usage is stable and not increasing. The maximum consumption is around 179 MB with 100+ active connections, and the average is about 174 MB.
Compared to the alpha-branch executable available in the repository, the difference is obvious: with that one, memory usage exceeded 250 MB after a similar amount of runtime.

maybe you can test: dd3a149
@ma3uk

maybe you can test: dd3a149

Thanks, I’ll check the latest alpha version with dd3a149. I’ll report back with the results.

maybe you can test: dd3a149 @ma3uk

3 hours of uptime on 719d3eb — everything looks good. The average memory usage is 183 MB, with a maximum of 191 MB recorded at 200+ connections. I’ll continue testing to check for any “too many open files” errors

@Nemu-x It seems there is a memory leak issue when using the XHTTP transport. I’ve been testing it since the release of the latest alpha version with support for it, and I noticed that memory usage grows significantly over several hours of operation. When Mihomo starts, RAM usage is around 140 MB with 70 active connections, but after 8 hours the memory consumption increases to about 400 MB with the same 70 active connections. I tested it on an OpenWRT x86_64 operating system.

Thanks for the report
I’m currently testing this on my side with sustained traffic load. Will update here once I have more concrete results.

@Nemu-x It seems there is a memory leak issue when using the XHTTP transport. I’ve been testing it since the release of the latest alpha version with support for it, and I noticed that memory usage grows significantly over several hours of operation. When Mihomo starts, RAM usage is around 140 MB with 70 active connections, but after 8 hours the memory consumption increases to about 400 MB with the same 70 active connections. I tested it on an OpenWRT x86_64 operating system.

Thanks for the report
I’m currently testing this on my side with sustained traffic load. Will update here once I have more concrete results.

After about 12 hours of uptime, all XHTTP connections dropped, and the logs show HTTP errors. At the moment the connections dropped, memory usage had exceeded 600 megabytes.

Thanks for the report, I’ve been testing this with sustained load and pprof.

I couldn’t reproduce a persistent memory leak so far:

* memory grows under load but drops after it stops

* heap diff shows negative growth in main HTTP2/TLS paths

* goroutine count also decreases after load

This was based on a ~1 hour soak test. I’ll now run a longer test (several hours) to check long-term behavior

Peak heap ~140MB → dropped to ~63MB after load

This looks more like connection churn than unreleased memory.

However, the too many open files error you reported is important - this may indicate FD / connection accumulation over long uptime.

I’ve attached pprof snapshots and memory stats from my test. I’ll continue longer soak testing to see if it reproduces over time.

If you can reproduce again, pprof + FD count at failure point would help a lot.

heap-after.txt heap-diff.txt heap-start.txt mem-all.txt

Quick update from my side.

I couldn’t reproduce a persistent heap memory leak. However, during a ~3.5 hour soak test on Windows, I observed connection accumulation after stopping the load.

A noticeable number of sockets remained in CLOSE_WAIT, BOUND, and ESTABLISHED states.
The presence of CLOSE_WAIT suggests that some connections are not being properly closed on the client side.

This may be related to the reported too many open files issue and looks more like a connection/FD lifecycle problem rather than a heap leak.

Attached logs and pprof snapshots from the test.

xhttp-soak-debug-windows-3h.zip

@Nemu-x It seems there is a memory leak issue when using the XHTTP transport. I’ve been testing it since the release of the latest alpha version with support for it, and I noticed that memory usage grows significantly over several hours of operation. When Mihomo starts, RAM usage is around 140 MB with 70 active connections, but after 8 hours the memory consumption increases to about 400 MB with the same 70 active connections. I tested it on an OpenWRT x86_64 operating system.

Thanks for the report
I’m currently testing this on my side with sustained traffic load. Will update here once I have more concrete results.

@Nemu-x It seems there is a memory leak issue when using the XHTTP transport. I’ve been testing it since the release of the latest alpha version with support for it, and I noticed that memory usage grows significantly over several hours of operation. When Mihomo starts, RAM usage is around 140 MB with 70 active connections, but after 8 hours the memory consumption increases to about 400 MB with the same 70 active connections. I tested it on an OpenWRT x86_64 operating system.

Thanks for the report
I’m currently testing this on my side with sustained traffic load. Will update here once I have more concrete results.

After about 12 hours of uptime, all XHTTP connections dropped, and the logs show HTTP errors. At the moment the connections dropped, memory usage had exceeded 600 megabytes.

Thanks for the report, I’ve been testing this with sustained load and pprof.

I couldn’t reproduce a persistent memory leak so far:

* memory grows under load but drops after it stops

* heap diff shows negative growth in main HTTP2/TLS paths

* goroutine count also decreases after load

This was based on a ~1 hour soak test. I’ll now run a longer test (several hours) to check long-term behavior

Peak heap ~140MB → dropped to ~63MB after load

This looks more like connection churn than unreleased memory.

However, the too many open files error you reported is important - this may indicate FD / connection accumulation over long uptime.

I’ve attached pprof snapshots and memory stats from my test. I’ll continue longer soak testing to see if it reproduces over time.

If you can reproduce again, pprof + FD count at failure point would help a lot.

heap-after.txt heap-diff.txt heap-start.txt mem-all.txt

Quick update from my side.

I couldn’t reproduce a persistent heap memory leak. However, during a ~3.5 hour soak test on Windows, I observed connection accumulation after stopping the load.

A noticeable number of sockets remained in CLOSE_WAIT, BOUND, and ESTABLISHED states.
The presence of CLOSE_WAIT suggests that some connections are not being properly closed on the client side.

This may be related to the reported too many open files issue and looks more like a connection/FD lifecycle problem rather than a heap leak.

Attached logs and pprof snapshots from the test.

xhttp-soak-debug-windows-3h.zip

Are any additional code changes required, besides the ones already made to fix the transport‑closing issue, to fully resolve the problem?

@Nemu-x It seems there is a memory leak issue when using the XHTTP transport. I’ve been testing it since the release of the latest alpha version with support for it, and I noticed that memory usage grows significantly over several hours of operation. When Mihomo starts, RAM usage is around 140 MB with 70 active connections, but after 8 hours the memory consumption increases to about 400 MB with the same 70 active connections. I tested it on an OpenWRT x86_64 operating system.

Thanks for the report
I’m currently testing this on my side with sustained traffic load. Will update here once I have more concrete results.

@Nemu-x It seems there is a memory leak issue when using the XHTTP transport. I’ve been testing it since the release of the latest alpha version with support for it, and I noticed that memory usage grows significantly over several hours of operation. When Mihomo starts, RAM usage is around 140 MB with 70 active connections, but after 8 hours the memory consumption increases to about 400 MB with the same 70 active connections. I tested it on an OpenWRT x86_64 operating system.

Thanks for the report
I’m currently testing this on my side with sustained traffic load. Will update here once I have more concrete results.

After about 12 hours of uptime, all XHTTP connections dropped, and the logs show HTTP errors. At the moment the connections dropped, memory usage had exceeded 600 megabytes.

Thanks for the report, I’ve been testing this with sustained load and pprof.
I couldn’t reproduce a persistent memory leak so far:

* memory grows under load but drops after it stops

* heap diff shows negative growth in main HTTP2/TLS paths

* goroutine count also decreases after load

This was based on a ~1 hour soak test. I’ll now run a longer test (several hours) to check long-term behavior

Peak heap ~140MB → dropped to ~63MB after load

This looks more like connection churn than unreleased memory.
However, the too many open files error you reported is important - this may indicate FD / connection accumulation over long uptime.
I’ve attached pprof snapshots and memory stats from my test. I’ll continue longer soak testing to see if it reproduces over time.
If you can reproduce again, pprof + FD count at failure point would help a lot.
heap-after.txt heap-diff.txt heap-start.txt mem-all.txt

Quick update from my side.
I couldn’t reproduce a persistent heap memory leak. However, during a ~3.5 hour soak test on Windows, I observed connection accumulation after stopping the load.
A noticeable number of sockets remained in CLOSE_WAIT, BOUND, and ESTABLISHED states.
The presence of CLOSE_WAIT suggests that some connections are not being properly closed on the client side.
This may be related to the reported too many open files issue and looks more like a connection/FD lifecycle problem rather than a heap leak.
Attached logs and pprof snapshots from the test.
xhttp-soak-debug-windows-3h.zip

Are any additional code changes required, besides the ones already made to fix the transport‑closing issue, to fully resolve the problem?

The dd3a149 change looks directly related to the connection lifecycle issue observed here.

Before suggesting any additional code changes, it makes sense to re-test with this commit included and verify whether the connection accumulation / CLOSE_WAIT behavior is still reproducible.

I’ll run a new soak test (~4 hours) on my side with this change and share logs and results.

@Nemu-x It seems there is a memory leak issue when using the XHTTP transport. I’ve been testing it since the release of the latest alpha version with support for it, and I noticed that memory usage grows significantly over several hours of operation. When Mihomo starts, RAM usage is around 140 MB with 70 active connections, but after 8 hours the memory consumption increases to about 400 MB with the same 70 active connections. I tested it on an OpenWRT x86_64 operating system.

Thanks for the report
I’m currently testing this on my side with sustained traffic load. Will update here once I have more concrete results.

@Nemu-x It seems there is a memory leak issue when using the XHTTP transport. I’ve been testing it since the release of the latest alpha version with support for it, and I noticed that memory usage grows significantly over several hours of operation. When Mihomo starts, RAM usage is around 140 MB with 70 active connections, but after 8 hours the memory consumption increases to about 400 MB with the same 70 active connections. I tested it on an OpenWRT x86_64 operating system.

Thanks for the report
I’m currently testing this on my side with sustained traffic load. Will update here once I have more concrete results.

After about 12 hours of uptime, all XHTTP connections dropped, and the logs show HTTP errors. At the moment the connections dropped, memory usage had exceeded 600 megabytes.

Thanks for the report, I’ve been testing this with sustained load and pprof.
I couldn’t reproduce a persistent memory leak so far:

* memory grows under load but drops after it stops

* heap diff shows negative growth in main HTTP2/TLS paths

* goroutine count also decreases after load

This was based on a ~1 hour soak test. I’ll now run a longer test (several hours) to check long-term behavior

Peak heap ~140MB → dropped to ~63MB after load

This looks more like connection churn than unreleased memory.
However, the too many open files error you reported is important - this may indicate FD / connection accumulation over long uptime.
I’ve attached pprof snapshots and memory stats from my test. I’ll continue longer soak testing to see if it reproduces over time.
If you can reproduce again, pprof + FD count at failure point would help a lot.
heap-after.txt heap-diff.txt heap-start.txt mem-all.txt

Quick update from my side.
I couldn’t reproduce a persistent heap memory leak. However, during a ~3.5 hour soak test on Windows, I observed connection accumulation after stopping the load.
A noticeable number of sockets remained in CLOSE_WAIT, BOUND, and ESTABLISHED states.
The presence of CLOSE_WAIT suggests that some connections are not being properly closed on the client side.
This may be related to the reported too many open files issue and looks more like a connection/FD lifecycle problem rather than a heap leak.
Attached logs and pprof snapshots from the test.
xhttp-soak-debug-windows-3h.zip

Are any additional code changes required, besides the ones already made to fix the transport‑closing issue, to fully resolve the problem?

The dd3a149 change looks directly related to the connection lifecycle issue observed here.

Before suggesting any additional code changes, it makes sense to re-test with this commit included and verify whether the connection accumulation / CLOSE_WAIT behavior is still reproducible.

I’ll run a new soak test (~4 hours) on my side with this change and share logs and results.

Retested with dd3a149 included

I ran another retest and checked TCP state both during load and after fully stopping the client traffic. On my side, the previous connection accumulation behavior is no longer reproducible: after load stops, extra sockets are released correctly and the process returns to its normal listening state.

Attached a small retest bundle with TCP summaries and process snapshots.
dd3a149-short-retest-20260329-231937.zip

Thanks for bringing xhttp support. Does it support extra "downloadSettings" at the moment? i am looking for a template for these extra settings.

{
  "downloadSettings": {
    "address": "",
    "port": 443,
    "network": "xhttp",
    "security": "reality",
    "realitySettings": {
      "show": false,
      "serverName": "",
      "fingerprint": "chrome",
      "publicKey": "I",
      "shortId": "",
      "spiderX": "/"
    },
    "xhttpSettings": {
      "host": "",
      "path": "/",
      "mode": "auto"
    }
  }
}

@Nemu-x @wwqgtxx you have plan to add xmux for xhttp?

Thanks for bringing xhttp support. Does it support extra "downloadSettings" at the moment? i am looking for a template for these extra settings.

{
  "downloadSettings": {
    "address": "",
    "port": 443,
    "network": "xhttp",
    "security": "reality",
    "realitySettings": {
      "show": false,
      "serverName": "",
      "fingerprint": "chrome",
      "publicKey": "I",
      "shortId": "",
      "spiderX": "/"
    },
    "xhttpSettings": {
      "host": "",
      "path": "/",
      "mode": "auto"
    }
  }
}

@Nemu-x @wwqgtxx you have plan to add xmux for xhttp?

Thanks for the feedback.

At the moment, neither downloadSettings nor xmux support are implemented in the current xhttp path.

I’ll be working on both as follow-up improvements.

@wwqgtxx

Hi! Following up on the previous discussion about xhttp.

I added explicit test coverage for sing-mux over VLESS xhttp (both stream-up and download-settings modes).
All tests pass, including sequential and concurrent scenarios across yamux/smux/h2mux.

From current results, sing-mux already works correctly over xhttp without additional changes.

Before moving further with xmux-related work, I’d like to clarify:
👉 do you expect any additional behavior beyond existing sing-mux when used with xhttp, or is current integration sufficient?

The test branch:
https://github.com/Nemu-x/mihomo/tree/test/xhttp-singmux

I welcome support for xmux. As a sub-component of xhttp, combining the two can provide a better user experience compared to external components.

I welcome support for xmux. As a sub-component of xhttp, combining the two can provide a better user experience compared to external components.

I understand xmux should live inside xhttp rather than as an external SingMux wrapper. I’ll draft a minimal xhttp-native design first.

#2695
It appears there are some performance issues due to the behavior not being aligned with Xray-core.