Why use a name like xhttp? It confuses users. A more meaningful name should be used.

Well, I referred to some of the xhttp/pht code because my original HTTP obfuscation was quite rudimentary, so I casually added the Sudoku version of xhttp and pht. This was based on the original implementation but has some differences from the original version. In short, to some extent, Sudoku can now ride on the coattails of these two, behaving more like HTTP requests in ASCII mode, and inadvertently able to bypass CDN as well. This is also the source of its name. In fact, I personally recommend using 'auto' and 'legacy' as parameters, but I haven't abandoned xhttp and pht.

Please let me know how to delete or modify anything you think is inappropriate

Since it's different from the original, it shouldn't use a name like xhttp directly. Even a name like xhttp-like would make it easier for users to distinguish.

http.Transport should not include the Proxy parameter, as this is meaningless for mihomo and could potentially cause a loop (if the user sets a global environment variable pointing HTTPS_PROXY to mihomo's HTTP port).

Furthermore, I don't think automatically determining whether to enable TLS based on the port is a good design; users should know exactly what they are doing.

What you said makes a lot of sense. , I am making changes, may takes a few time since sudoku-seld needs change first

Looking at the code, there are three almost identical code snippets in obfs/httpmask/tunnel.go that create http.Client (the differences might be your own mistake?). Since they all call normalizeHTTPDialTarget, why not extract the steps for creating http.Client into a single function?

In our use case, fallback of net.Dialer{} should not be allowed. If dialFn == nil, it indicates a serious programming error and should trigger a panic.

For http.Transport's DialContext, regardless of what the passed-in addr is, you should directly use dialAddr.

I have made changes as you suggested while ensuring backward compatibility. Currently, after my own testing, all functions are working properly.

Should we provide an inbound_test for the new feature, specifically in listener/inbound/sudoku_test.go?

It is not needed for now, because I have already completed testing in the Sudoku repository itself. Furthermore, this new feature was tested in Mihomo in the previous version of Httpmask. There are essentially no changes in this new version; for the server side, it only needs to strip external HTTP obfuscation.

mihomo's own inbound_test helps uncover race issues in the code, as we perform high-concurrency transport tests, a fact well-demonstrated in mieru.

Moreover, it's not complicated; simply copy an existing function and add tests for the four parameters of http-mask-mode within a loop.

It can be observed that HTTPMaskMode almost always fails in Concurrent mode under Windows, indicating that there are still some problems with the existing code.

It seems that the current race condition only occurs on Windows, which is strange. I don't know how to fix it immediately.
I need some time to troubleshoot the issue. I will switch the development environment to Windows for testing. This is indeed perplexing

For now, we can temporarily use runtime.GOOS to call t.Skip() to merge the PR, which will give you more time to troubleshoot the problem.

Hold on, I think I've found the reason. Previously, you added Singmux's inbound to Sudoku, but I didn't handle the related logic afterward; I just stacked code on the original basis. The issue may lie within this part of the related logic. I'm working on it now.

It's probably related to the area near reapSessionLater. I tried serializing singmux, and the tests passed, so the issue might be with the Windows GC. Of course, I'm not certain yet because I replicated the test failure and made some changes locally, but it still fails. I need to set some breakpoints and gradually troubleshoot the issue.

Damn, it seems like it can't be resolved tonight. I'll skip for now as you suggested and then merge

I found a small problem in your code and fixed it for you. You can sync the correct code to the repository later when you have time: c456370

Of course, this doesn't solve the problem of the test failing on Windows.