Let the port shared on the network be chosen, not discovered - #74
Merged
Conversation
HTTP has worked all along — mihomo's mixed-port serves HTTP and SOCKS5 on the same listener, and the local-proxy description already said so. What did not exist was a way to fix the port when sharing the connection on the LAN outside proxy-only mode: the field was hidden everywhere else, on the reasoning that the number is an implementation detail nobody needs to see. That reasoning holds until another device is told to connect to it. A phone configured to point at this machine's address cannot follow a silent change to the port any more than a program in proxy-only mode could — and chooseProxyPort was treating them differently: proxy-only reported a taken port as an error, everywhere else it quietly picked a random free one instead. Sharing was already exposed to this, just without anyone knowing until they went looking for why the address had stopped working. Both sides of that are fixed. The setting is now shown whenever it is someone else's business — proxy-only, or LAN sharing turned on in any mode — and chooseProxyPort now reports a taken port there too rather than substituting one nobody asked for. The error blames the system proxy only when proxy-only mode is what makes the port matter; sharing gets its own wording, because the system proxy is not what is on trial there. Two tests cover the failure mode directly: a taken port is reported once sharing is on, in both system-proxy and tunnel mode, and the existing silent-fallback behaviour is confirmed unchanged when sharing is off.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Addresses the LAN-sharing part of the user's request: HTTP alongside SOCKS5, and a way to set the port.
HTTP already worked
mihomo's
mixed-portserves HTTP and SOCKS5 on the same listener — nothing to add there. The description already said so (settings.routing.port.description).The actual gap: no way to fix the port outside proxy-only mode
The port field was hidden everywhere except proxy-only mode, on the reasoning that the number is an implementation detail nobody needs to see (see the comment it replaces). That holds until another device is told to connect to it.
Worse, the backend was already inconsistent about this.
chooseProxyPort:Once LAN sharing is on in system-proxy or tunnel mode, the second behaviour is wrong for the same reason the first is right: a phone that was told to connect to
192.168.1.x:2080cannot follow a silent switch to a different port, and had no way to set one in the first place.What changed
Backend (
mihomo_connect.go):chooseProxyPortnow treats a taken port as an error wheneverAllowLANis on, not only in proxy-only mode. The error wording adapts — it blames the system proxy only when proxy-only mode is what makes the port matter; sharing gets its own message, because the system proxy isn't on trial there.Frontend: the port field is shown whenever
routingMode === "proxyOnly" || allowLan— so turning on sharing in any mode reveals the field to set it. No i18n changes needed; the existing description already covers "accepts both HTTP and SOCKS5" and the taken-port behaviour.Testing
Two new tests: a taken port is reported once sharing is on, in both system-proxy and tunnel mode; the existing silent-fallback behaviour is confirmed unchanged when sharing is off. Confirmed the new test fails against the prior behaviour before the fix.
Full suite green,
tsc --noEmitclean, frontend builds.🤖 Generated with Claude Code