3,300 Stars，4,700+ Forks。Fork 数比 Star 数还多了 40%。你多久没见过这种数据了？
我去翻了 README 才明白原因：项目的第一步就是让你 Fork 到自己的 GitHub 账户，然后再从 Railway 上拉取 Fork 版本部署。这个部署流程把 Fork 变成了强制步骤，直接拉高了 Fork 数。所以 Fork/Star 比异常这件事本身，算不上造假，但确实说明了一个问题：这个项目不是让你 Star 的，是让你拿来用的。
X4G 做了一件事：把 VLESS 代理服务的管理打包成了一个 FastAPI 后端加一个纯 HTML 仪表板，再绑上一个可选的 Telegram 管理机器人。你可以把它部署到 Railway 上，拿到一个公网域名，然后在浏览器里管理你的所有 VLESS 配置、订阅分组和流量限制。
说白了，它就是一个 VLESS 网关的”控制面板”。设计目标是让一个从来没有配过代理服务的人，也能在十分钟内搞出一个带流量管理、订阅分享、Telegram 远程控制的服务端。听起来不错，但翻完 Issue 列表和代码之后，我对它的判断就没那么乐观了。往下看。
把 README 里那些炫酷的功能标签剥掉，它到底做了什么值得细看的事？
它到底做了什么
X4G 的核心是一个 FastAPI 应用。启动后，它同时跑了三件事：VLESS 隧道中继、HTTP 代理转发、和一个 Web 仪表板。
VLESS 隧道支持三种传输模式：经典 WebSocket、XHTTP 分片上传、XHTTP 流式上传。这部分逻辑放在 relay_vless.py 里，本质上是把客户端发来的数据转发到目标服务器，再把响应传回去。加了连接计数、流量统计、错误日志三条监控线。
HTTP 代理就简单多了。/proxy/{target_url} 端点用 httpx 做了个通用转发，配上速率限制，可以单独给每个配置设 Mbps 上限。这个设计挺务实的，不搞复杂的代理链，就是一个轻量转发层。
Telegram 机器人的实现值得单拎出来说。它是可选的，配了 TELEGRAM_BOT_TOKEN 和 TELEGRAM_ADMIN_IDS 两个环境变量就激活。机器人支持从创建配置到查看流量到管理订阅分组的全套操作，用一个 step-by-step 的向导模式引导你填参数。更关键的是，它把仪表板上的核心管理功能全部搬到了聊天界面里。你不需要打开浏览器就能创建新配置、查看流量消耗、关掉快超额的链接。对于手机端管理来说，这个体验比 Web 面板更顺手。
仪表板本身是纯 HTML/CSS/JS 塞在一个 Python 变量里的单页应用。用了 Chart.js 做流量折线图，Tabler Icons 做图标，Vazirmatn 字体做波斯语排版。暗色主题是默认的，配色选了深蓝底加蓝色强调色。整个前端没有任何构建工具，所有代码全在一个字符串里。这种”全内联”做法的好处是零依赖部署，坏处是前端代码维护性基本为零。
订阅分组是另一个有区分度的功能。你可以把多个 VLESS 配置绑到一个分组里，生成一个公开的订阅页面，支持密码保护和 QR 码输出。这比传统面板的纯 base64 订阅链接要实用得多，尤其是在需要分享给多个用户的时候。
四个组件的关系大致如上图。VLESS 隧道和 HTTP 代理负责流量处理，Web 仪表板面向浏览器管理，Telegram Bot 提供手机端入口。它们之间通过共享的 JSON 状态文件保持数据一致。
聊完了功能，说说实际跑起来的体验。
从零到跑起来
部署流程和大多数 Railway 项目一样：Fork 仓库，连 GitHub 到 Railway，选仓库，等自动构建。唯一需要注意的是 Volume。
项目把状态持久化在一个 JSON 文件里（/data/x4g_state.json），每次修改后写盘。如果你在 Railway 上没有挂 Volume 到这个路径，容器一重启数据全丢。README 明确写了一个警告段落，但还是有不少人踩了这个坑，Telegram 支持群里反复出现”我的配置为什么没了”的问题。
整个部署链路如上图所示，四步走完理论上不超过五分钟。其中第三步挂 Volume 是最容易被跳过的，但它决定了你的配置能不能活过下一次容器重启。
实际的安装命令就是一个 Railway 自动构建，没有手动的 pip install 步骤。但如果要在本地跑，依赖如下：
pip install fastapi==0.104.1 uvicorn[standard]==0.24.0 httpx==0.25.1 websockets==12.0 aiofiles>=23.2.1 httpx[http2]
启动后访问 /dashboard，默认密码是 X4GKING。建议登录后第一时间改密码。修改路径在仪表板的 Security 页面，调用 /api/change-password 接口。
运行命令本身也很简单：
python main.py
它会自动启动 Uvicorn，绑定 Railway 分配的 PORT 环境变量。默认端口是 8000。如果你在本地测试，需要手动设一下端口。
几个容易踩的坑：一是 Fingerprint 设置，如果你选了 randomized，每次连接会随机换指纹，部分客户端（尤其是旧版 v2rayNG）会握手失败，建议先用 chrome 或 firefox。二是 XHTTP 模式需要客户端支持，Streisand 和小火箭的最新版已经适配了，但 NekoBox 需要额外配置。三是速率限制单位是 Mbps 而不是 Mbps/秒，你设 10 就是 10Mbps 总带宽。
不过功能再多，用不对场景也是白搭。谁该用它，谁该绕道？
谁该用，谁别碰
| 场景 | 典型用户 | 优势 | 局限 |
|---|---|---|---|
| 个人代理服务 | 需要一个简单 VLESS 服务器的个人用户 | Railway 部署零运维，Telegram 远程管理 | 不支持多用户权限隔离 |
| 小范围分享 | 给朋友/家人分享代理链接 | 订阅分组 + 公开页 + QR 码 | 流量统计精度有限 |
| 临时测试环境 | 开发者测试 VLESS 协议兼容性 | 快速部署，多协议切换 | 无负载均衡和高可用 |
不适用的情况同样明确。如果你需要一个生产级的多节点代理管理平台，3x-ui 或 Marzban 更合适。这两个项目有更成熟的用户权限系统、TLS 证书管理和反向代理配置。X4G 目前只有单节点、单用户管理员的模式。
如果你的客户端只支持 Shadowsocks 或 Trojan，这东西跟你没关系。它只做 VLESS，不做协议转换，也不做多协议混合入口。还有一点：如果你对数据可靠性有严格要求，单 JSON 文件的持久化方案跟你不太匹配。我翻了几个 Issue，有人在并发写盘时遇到了数据覆盖的问题，虽然维护者很快修了，但这个架构本身决定了它不适合高写入场景。
还有一个容易被忽视的限制：所有管理操作都依赖 Cookie Session，没有 API Key 或 Token 认证方案。这意味着你不能用脚本自动化管理操作，每次都得手动登录。
和 3x-ui 放在一起看，X4G 的定位就很清楚了。它在部署门槛和 Telegram 管理上明显占优，但在多用户、多协议、持久化等生产级需求上，差距不是一星半点。这不是谁好谁坏的问题，而是两个工具瞄准的是完全不同的使用场景。
场景选对了，下一个问题是：这个项目能活多久？得看社区健康度。
社区热度怎么来的
把几个核心指标摆出来，比直接说”很火”更有说服力：
| 指标 | 数据 | 说明 |
|---|---|---|
| Stars | ~3,300（截至 2026 年 7 月 10 日） | 上线 24 小时内破千，首日 850 Stars |
| Forks | ~4,700+ | Fork 比 Star 多，部署流程导致 |
| 核心维护者 | 1 人（x4gKing） | Bus Factor = 1，高风险 |
| 协议 | 未声明 | 无 License 意味着默认保留所有权利 |
| 最近提交 | 2026 年 7 月 10 日 | 项目上线仅 1 天 |
Fork 数的解释前面已经说了，是部署流程造成的，不当成造假。但 Star 增速本身确实很快，首日就冲到了 GitHub Trending 前十。这个热度一部分来自项目的实用性，另一部分来自作者在 YouTube 上的视频教程引流。
我在 GitHub 上搜索社区讨论时，发现一个有意思的现象：这个项目在 GitHub Trending 和多个中文技术聚合站点上都被报道了，但讨论质量普遍不高。大部分是”轻量神器””快速上手”这类泛泛介绍，缺少对架构设计或安全性的深度分析。Reddit 和 HackerNews 上目前找不到针对 X4G 本身的讨论帖。
维护者通过 Telegram 群提供支持，群内活跃度较高，问题响应也快，但从 Issue 区的模式来看，所有技术决策都依赖一个人。Bus Factor 等于 1 的项目，任何时候维护者停更，项目就进入僵尸状态。
协议缺失是一个不能忽视的问题。仓库里没有任何 LICENSE 文件，在 GitHub 上这就是默认的全权保留。你 Fork 了、部署了、用了，但从法律上讲你没有修改和分发的权利。一个用 Fork 作为部署第一步的项目没有开源协议，这本身就是一个矛盾。
数据和社区都过了一遍，该给个结论了。
值不值得追
我对 X4G 的判断是：功能有用，但信任需要时间。这不是那种看一眼代码就能无脑推荐的成熟项目。它是一个刚出生几天、只有一个人维护、连开源协议都还没选的婴儿期项目。
让我先说它做得对的地方。把 VLESS 面板的部署降到”Fork + 点几下”的门槛，这件事本身就是真实的价值。同类项目 Marzban 需要你装 Docker、配 Nginx、搞 SSL 证书，而 X4G 把这套流程全部外包给了 Railway。对不熟悉运维的人来说，这个差距是”能用”和”用不了”的区别。
Telegram 机器人的设计也说明作者想清楚了用户场景。不是所有人都方便随时开电脑登面板。在手机上通过 Telegram 关掉一个快用完流量的配置、再新开一个，这比打开浏览器登录面板快得多。这个功能在同类产品里不常见。
但问题也很明显。
- 第一个是协议缺失，前面说过了。
- 第二个是单维护者风险，这个项目能不能活过三个月完全取决于一个人的热情和精力。
- 第三个——也是我觉得最需要警惕的——是安全审计的缺失。
整个代码库没有任何测试文件，没有 CI/CD 配置，没有安全扫描流程。一个处理网络流量的网关服务，在没有任何形式化验证的情况下直接面向几千用户，这个信任前提太薄了。
表面上这是个 VLESS 面板，但深入了解后你会发现它真正解决的问题是”部署复杂度”。Railway 帮你做了服务器运维、域名绑定、HTTPS 证书，X4G 帮你做了配置管理、流量统计、用户分享。一层叠一层地屏蔽了复杂度。坏消息是，每多一层屏蔽，出问题时排错的难度就多一层。
如果让我给一个建议：先别把主力流量切过去。用 Railway 的免费额度跑一个测试实例，把一两个不重要的配置放上去，观察一周。重点看三件事：连接稳定性、流量统计的准确性、以及维护者有没有持续推更新。一周后这三件事都有答案了，再决定要不要认真用。
资源地址
| 资源 | 地址 |
|---|---|
| GitHub | https://github.com/x4gKing/X4G |
| YouTube 频道 | https://www.youtube.com/@X4GHUB |
| Telegram 支持 | https://t.me/Farajian2004f |
判断做完了，资源列在这。现在说点更实际的：接下来你该怎么做。
先用测试配置跑一周再说
如果你想试试 VLESS 自建代理又不想折腾服务器配置，X4G 是目前门槛最低的选项之一。Railway 免费额度和 Telegram 远程管理这两个组合，足够覆盖个人使用场景了。
但如果你已经在用 3x-ui 或 Marzban 并且运行稳定，没必要迁移。X4G 目前没有提供它们做不到的功能，反而少了多用户管理和负载均衡。
我关注的一个指标是维护者接下来一个月能不能保持更新频率。上线 24 小时内的 GitHub Trending 热度会推着人往前冲，但热度退潮后还能不能稳定迭代，才是判断一个单人项目值不值得长期跟的标准。如果你也在观望，拿它当一个轻量备选面板比当一个主力网关更合适。