/jump to repo

Repos Recent Bookmarks Watched Notes Tags Discover Compare Stats GitHub

Repository brief

SagerNet/sing-box

Read the upstream summary on the left, browse the cached forks below it, and load each fork comparison into the right-hand panel.

Cached analysis

cached 2026-03-30T19:51:55.502Z

1mo ago

SagerNet/sing-box

SagerNet/sing-box is an active Go-based universal proxy platform with a large user base and fork ecosystem, so it looks like a mature, high-activity upstream worth watching for forks. It is not archived, is on the `testing` default branch, and has very recent commits, including version bumps and protocol/platform work.

Loading tags...

Stars31,933

Forks3,733

Default branchtesting

Last pushed2026-03-30T17:06:57Z

Recommended shortcuts

Jump straight into Discofork's strongest cached fork picks, or open a compare view in one click.

Forks

Choose a fork to inspect

10 of 10 fork briefs

Maintenance:

Magnitude:

Sort:

Selected

Choose this fork if you need its mobile/release tooling and platform-specific packaging changes. Choose upstream if you want the safest path for full feature parity, certificate-management workflows, and easier long-term upgrades.

Choose this fork if your deployment benefits from the added certificate-provider/origin-CA work and MAC/hostname-based routing support. Stick with upstream if you want the latest sing-box fixes and the least configuration drift.

Prefer this fork if you need its added transport/protocol work and are comfortable managing divergence. Prefer upstream if you want the newest mainline fixes, broader platform support, and lower maintenance risk.

Prefer this fork if you want the added scanning, masking, fragmentation, and distribution features and can tolerate divergence. Prefer upstream if you need the newest sing-box fixes, simpler support, and maximum compatibility.

Prefer this fork if your priority is advanced load balancing, provider deduplication, and selection control for real-world proxy fleets. Prefer upstream if you want the newest protocol/platform fixes and the lowest maintenance risk.

Prefer this fork if your priority is provider management and Clash-oriented operations. Prefer upstream if you want the newest protocol/platform work and lower divergence risk.

Prefer this fork if its rule-set and routing workflow additions are the point of adoption. Prefer upstream if you want active maintenance, lower integration risk, and the latest protocol/platform work.

Prefer this fork if provider import, outbound provider management, and Clash API control matter more than staying current with upstream. Prefer upstream if you want the latest protocol/platform fixes and the broadest maintenance surface.

Choose this fork if you want Hiddify-oriented capabilities and can tolerate divergence from upstream; stay with upstream if you want the cleanest path for frequent sing-box updates and broad compatibility.

Prefer this fork if you are shipping sing-box inside mobile or Apple-centric products and need the fork's platform fixes. Prefer upstream if you want the newest protocol work and the broadest feature parity.

Fork comparison

PuerNya/sing-box

70/100

active

significant_divergence

Choose this fork if you need its mobile/release tooling and platform-specific packaging changes. Choose upstream if you want the safest path for full feature parity, certificate-management workflows, and easier long-term upgrades.

Likely purpose

A fork for users who want sing-box with custom release pipelines, mobile/libbox workflows, and platform-specific packaging or deployment tweaks, rather than a pure upstream tracking branch.

Best for

Teams shipping sing-box inside mobile apps or packaged distributions.; Maintainers who need custom release, signing, or store-publishing workflows.; Users who value downstream platform tweaks over strict upstream parity.; Adopters willing to trade some upstream completeness for a more opinionated distribution fork.

Additional features

Improved release and publishing workflow, including TestFlight publishing changes.
New app-store/build automation helpers under `cmd/internal/app_store_connect`, `cmd/internal/build_libbox`, and `cmd/internal/update_apple_version`.
Libbox and mobile-facing command/client changes, suggesting a stronger embedded or app-distribution workflow.
Platform behavior tweaks such as `bind_address_no_port`, unique network interfaces, and Tailscale endpoint/interface support.
Packaging and distribution adjustments across Docker, systemd, OpenWrt, Pacman, and Apple-oriented build commands.
Adds or extends platform-specific client support, such as mobile, Android, iOS, or desktop packaging.

Missing features

Upstream ACME and origin CA service code appears to have been removed or heavily reduced, which may make certificate-management workflows less turnkey.
F-Droid-related libbox support was removed, so Android distribution channels appear narrower than upstream.
Large amounts of test and compatibility coverage were deleted, which may make future upgrades riskier for adopters.
The fork is materially behind upstream by 200 commits, so it likely lacks a chunk of recent upstream protocol/platform fixes and feature work.
It trails upstream by 200 commits, so some recent upstream features and fixes are likely not present yet.

Strengths

Strong focus on release engineering and platform distribution.
Likely better fit for mobile or app-store style deployment pipelines.
Keeps moving actively, so it is not a dead-end fork.
Retains broad sing-box networking scope while specializing distribution paths.

Risks

Materially behind upstream and also heavily diverged, so rebasing or backporting upstream fixes will likely be non-trivial.
Deletion-heavy changes raise the chance of missing capabilities or hidden regressions.
Reduced test coverage increases maintenance and upgrade risk.
Users needing upstream certificate-management workflows may find the fork less complete.