/jump to repo

Repos Recent Bookmarks Watched Notes Tags Discover Compare Stats GitHub

Repository brief

XTLS/Xray-core

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-30T16:03:47.667Z

1mo ago

XTLS/Xray-core

XTLS/Xray-core is a large, active Go network tooling project with 36,385 stars and 5,112 forks. It describes itself as an open platform and the "best v2ray-core," with very recent activity on `main` and frequent releases/patches in late March 2026. Forks are likely interesting if you care about proxy/networking infrastructure, protocol work, or a fast-moving upstream with a broad ecosystem around it.

Loading tags...

Stars36,385

Forks5,112

Default branchmain

Last pushed2026-03-30T07:48:21Z

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

9 of 9 fork briefs

Maintenance:

Magnitude:

Sort:

Selected

Choose this fork if you need its MahsaNG-specific MVLESS, QUIC, DNS, and transport changes. Avoid it if you want a low-risk, upstream-aligned Xray-core, because the branch is actively maintained but substantially diverged.

Choose this fork if you are building on Amnezia’s VPN stack or need its custom VLESS/config integration. Choose upstream if you want the freshest Xray-core fixes, broader ecosystem compatibility, and lower maintenance overhead.

Prefer this fork only if you specifically need its older transport tweaks and are prepared to maintain a highly divergent codebase. For most adopters, upstream is the safer choice because this fork is stale, far behind, and likely missing many recent fixes and features.

Choose this fork only if you specifically need its older custom behavior and are prepared to live without upstream progress. For most adopters, upstream is the safer and more current choice.

Prefer this fork only if you need its local DNS/platform tweaks and are willing to absorb upstream lag. If you want the latest protocol fixes, transport work, and broad ecosystem compatibility, upstream is the safer choice.

Prefer this fork if you want a Hiddify-focused, operationally tuned Xray-core and do not need the latest upstream fixes. Prefer upstream if you care about current protocol/transport work, lower maintenance risk, or long-term compatibility.

Prefer this fork if you need its added protocol/API behavior and can tolerate substantial divergence from upstream. Prefer upstream if you want the latest fixes, broader transport completeness, and lower maintenance risk.

Choose this fork if GOST support is the main requirement and you can absorb maintenance risk. Avoid it if you need close upstream compatibility, current protocol fixes, or a low-risk production base.

Prefer this fork if you need ANYTLS/TUIC work or the Shadowsocks changes and can tolerate feature removal and protocol churn. Prefer upstream if you need the broadest compatibility, especially Hysteria2 support.

Fork comparison

GFW-knocker/Xray-core

70/100

active

significant_divergence

Choose this fork if you need its MahsaNG-specific MVLESS, QUIC, DNS, and transport changes. Avoid it if you want a low-risk, upstream-aligned Xray-core, because the branch is actively maintained but substantially diverged.

Likely purpose

To provide a tailored Xray-core build that changes core proxy behavior and transport handling for a specific downstream workflow, likely prioritizing compatibility and custom connectivity features over staying close to upstream defaults.

Best for

Operators using MahsaNG or a similar downstream stack who need this fork's specific behavior.; Teams that want a customized Xray-core with extra transport/protocol tuning.; Maintainers comfortable carrying a divergent proxy core and resolving upstream merge conflicts.; Users who value compatibility fixes and custom networking behavior more than upstream cleanliness.

Additional features

Expanded MVLESS inbound/outbound behavior with new config and account/protocol code paths.
Custom encryption and encoding logic under `proxy/mvless/encryption` and `proxy/mvless/encoding`.
Transport-level changes around QUIC, including inconsistency fixes and dialer/test updates.
Added dnstt-related transport work and DNS-side changes, suggesting support for a new tunneling/workflow area.
User-agent modification and ECH-related fixes, indicating compatibility or anti-detection tuning.
Expands API, schema, or SDK surface area for downstream integrations and generated clients.

Missing features

Materially lags upstream at the merge base, so it does not include newer upstream commits after `v26.3.27` and related late-March fixes.
Upstream-standard behavior may be harder to rely on because core proxy paths like `freedom`, MVLESS, and QUIC have been customized heavily.
The fork appears to prioritize downstream-specific behavior, which can make vanilla upstream configuration guides and ecosystem integrations less predictable.

Strengths

Very recent activity, so the fork is still being maintained.
Large investment in protocol and transport code suggests it is not a superficial theme fork.
Adds or adjusts real operational workflows rather than only packaging or branding changes.
Likely useful when upstream behavior needs to be adapted for a specific deployment or censorship-evasion stack.

Risks

Significant divergence from upstream increases merge and upgrade risk.
Heavy protocol modifications can create compatibility regressions with upstream config, panels, or clients.
The fork name and commit history suggest purpose-specific tuning, so it may not suit general-purpose deployments.
Testing burden is higher because many files and transport paths changed together.