luci-app-passwall2: add ordered priority failover - #1199
Draft
AliZamaniJ wants to merge 4 commits into
Draft
Conversation
AliZamaniJ
marked this pull request as ready for review
July 29, 2026 03:26
lwb1978
marked this pull request as draft
August 1, 2026 04:02
Contributor
Author
|
Hi @lwb1978, I noticed this PR was moved back to draft, but I couldn't find any feedback. Is there anything you’d like me to change or test before it’s ready for review? Also, I can move the dnsmasq change to a separate PR if you prefer. Thanks. |
Collaborator
|
Hello, this feature has a lot of code, currently set it as a draft. |
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
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.
Why I added this
I use PassWall2 on a low-memory Linksys MX4200 with a shunt setup: Iranian traffic is direct and the default route goes through Xray. I wanted the default route to stay on one node and move to a known backup only when that node was actually unavailable.
The existing balancing mode is useful for distributing or selecting traffic, but it is not ideal for this case. Depending on the strategy, different connections can leave through different public IPs. Some login, payment and anti-abuse systems are sensitive to that. SOCKS Auto Switch also solves a different problem: it manages a separate SOCKS service instead of providing an ordered, reusable Xray routing node for shunt and global traffic.
When my active node failed, both foreign traffic and remote DNS failed with it. Recovery also required more process and service work than I wanted on a small router. I therefore added an opt-in
_failovervirtual node that keeps the active outbound sticky and changes it only after a confirmed failure or a confirmed primary recovery.Memory issue I observed
While reproducing prolonged node and remote-DNS failures on a low-memory router, I saw the private DNSMasq instances create many TCP workers. I observed about 26 DNSMasq children, while the private PassWall2 configurations did not inherit the router's intended connection cap. This reduced the available memory headroom during exactly the kind of outage where the router was already doing additional recovery work.
I added
dnsmasq_tcp_max_connectionsfor the private Direct and Global instances.0keeps it automatic: 8 connections on devices with up to 512 MiB RAM and 20 on larger devices. Existing configurations do not need a migration.What I changed
_failovervirtual node with one primary and an explicitly ordered backup list.socks5hprobe so the check covers the selected outbound and its DNS path together./tmpand restored the selected override after an Xray restart.Difference from balancing
Balancing can intentionally spread connections between multiple outbounds. This failover node normally keeps every connection on one outbound, so the public IP stays stable. It changes the IP only after the active node has met the failure threshold, or after the primary has passed the configured recovery checks and dwell time.
Validation
I used a local router smoke harness to cover candidate ordering, the two-cycle failure threshold, all-down behavior, Direct fallback, missing nodes, IPv4/IPv6 and ECMP route detection, URL redaction, monotonic timers, Xray restart recovery and SOCKS lifecycle cleanup. The harness is specific to my test environment, so I did not include the
tests/directory in this PR.I also ran:
sh -nfor every changed shell script;git diff --check;I ran the feature on a Linksys MX4200 v1 with OpenWrt 25.12.5, Xray, three active radios and normal client traffic for more than 30 hours on the same router boot. The test included many real failover and recovery transitions. I observed no new OOM, killed process or router reboot, swap stayed unused, the private DNSMasq instances did not accumulate, and Xray was not killed by memory pressure.
This feature is opt-in and does not change existing balancing, shunt or SOCKS configurations.