Unlisted page
This page is unlisted. Search engines will not index it, and only users having a direct link can access it.
Skip to main content

网络代理使用总结

sing-box
28 min read

TLDR​

TLDR

目前方案的设计是基于以下场景（需求&约束）：

  • 个人使用，不需要多人使用的附加功能
  • 多端使用，不只是单机
  • 既有 macOS / NixOS 差异
  • 想减少 GUI 客户端依赖（也就是直接裸核使用）
  • 需要可维护、可迁移、可自动更新
  • 未来可能同时覆盖 client / server

本文的核心逻辑

先介绍我目前的 singbox 方案，进而通过为什么选择这些方案，而简要写点相关的基础知识和基本认知。

简要介绍我的singbox方案​

tip

这部分介绍我当前singbox相关的整套方案，以及说明为什么这么设计

  • 【技术选型】为啥选择singbox而非clash
  • server
    • 为啥用 nix 配置 singbox server（而非直接用别人的shell）
    • 为啥用 vless? 具体查看 代理协议
  • client

server​

danger

简单来说，目前最简单实用的方案就是直接选择DMIT之类的靠谱服务商的美西节点（LA或者）进行自建

为啥自建（而非机场）？​

【技术选型】为啥选择singbox而非clash​

为啥用 nix 配置 server（而非直接用第三方shell）​

目前大部分人自建都直接使用以 233boy/sing-box 为代表的shell进行安装（与其对标的repo还有【qljsyph/sbshell】、【eooce/Sing-box】、【mack-a/v2ray-agent】、【yonggekkk/sing-box-yg（支持一些拓展功能（Argo/WARP/Psiphon、多内核混合））】。【alireza0/s-ui】、【beck-8/subs-check（订阅转换、测速、测活、流媒体检测、重命名、导出为任意格式的工具）】）

之前考虑过“直接用脚本安装，没必要nix化（这种机器都是买最便宜的，性能也就很差，玩不起来）直接使用 233boy/sing-box 或者 sbshell 即可”，但是为啥最终又决定nix化了呢？

其实这个仍然是一分为二

为什么不考虑打野？​

全自动获取免费机场节点/订阅方法分享【立即实现代理节点自由】 - 开发调优 / 开发调优- LINUX DO

让自动获取免费机场订阅更自动

与其自建节点，不如直接打野抓别人的节点。在自建之前先搞下这个。我感觉打野搭配 sub-store会很有用。 【翻墙的终极解决方案】 简单来说，就是 打野/机场 和 自建 互为灾备、互为冗余，具体来说，打野+自动扔进sub-store做测速（测速、筛选节点、删除无效节点等），自动按照latency排序，给我下发订阅URL（之后多端的singbox直接拉URL，本地不需要任何操作，默认使用）。 打野（做中转, GroupPool）和自建（做落地鸡, GroupSelf）互为failover，两个其中任一挂了，直接另一个走直连。 自建组两台机器，一台LA机器，DMIT大妈的的T1（我的主力落地鸡，美西节点，服务全开，¥37/年（折合来说¥12/月，比机场便宜），1C1G20GB1TB流量千兆带宽，网络好配置差，只做落地鸡（BWG 类似配置但是2C的机器$50/年）），另一台HK机器（备用落地鸡，我的主力VPS兼作落地，sub-store就在这台机器上跑，跑完把订阅URL分发到我所有workstation和homelab机器上） 我的所有机器都直接走VLAN，不走公网，所以不需要担心被人打野

# 想法很好很天真，云端测速，多端的singbox直接吃现成的（默认latency排序，singbox默认读取第一个node）
#但是之前忽略了一点，目前sub-store是跑在HK节点的。而我所有需要跑singbox进程的端的网络环境就比较复杂了。
#所以这里这个问题的最优解是什么？是直接本地singbox测速转换节点？但是singbox cli 本身不支持这个操作，所以怎么实现呢？还是说有更好的方案？

client​

为啥用 nix 配置 singbox client（而非使用第三方）​

why not use wireguard-based VPN?​

看到一个说法

“突然想到，如果买了好多台线路vps，买了一台落地，是不是可以用 wireguard 或者 tailscale 连起来，落地vps 作为 exit node； 这样只要连上线路约等于自动到落地了”

有很多人认同。其实这个说法是有问题的。且不提tss跟sinbox来翻墙，在latency和抗封锁上做比较（可以比较（但是没必要比）。简单来说，tss这类方案都是UDP包，所以可以理解为类似singbox用hy2或者TUIC。但是tss不是还有个relay吗？这个情况下就不如直接vless+reality了，latency和抗封锁两方面都不如。也就是说“Tailscale 兼顾 hy2（UDP）和 vless（TCP）这两类传输思路”）。之所以说，二者没必要比，因为singbox的核心在于route和rule-set，而tss做不了这个。结论：有人说可以应急使用，在我看来，应急时随便找个节点就行了，何必用这个？

[2026-01-22] 上面说法有问题，这里写个更清晰的说法。singbox支持使用wireguard作为outbounds type，而tailscale使用exit-nodes同样可以实现fq。所以很多人误以为可以用tailscale替代singbox。实际上很简单，singbox的核心在于rule-set，而wireguard的核心则在于

代理协议​

tip

这部分用来解释究竟是怎么翻墙的

GFW运行机制​

【安全上网】防火长城GFW史上最大规模的内部文件泄露事件，揭示GFW的运作细节，DPI深度包检测｜流量限速｜篡改网页数据｜注入恶意代码｜DDos攻击｜流量定位到个人｜重点关注对象｜普通用户应该怎么办？ - YouTube

DomainTools Investigations | Inside the Great Firewall Part 1: The Dump

DomainTools Investigations | Inside the Great Firewall Part 2: Technical Infrastructure



- "***【GFW工作机制】GFW technical arch***"
  # 1、DPI（去查SNI）
  # 2、QoS (流量限速) 对于可疑但是拿不准的（对特定协议或者无法识别的加密数据降权），保证可用但是很难用
  # 3、（对于明文流量）实时注入和修改（感觉类似MMIT? 比如说访问网站时弹出反诈提醒，就是被识别到了，并且被篡改网页内容来屏蔽网站。既然如此，也可以实现对网页部分内容做实时修改，比如说把里面的代码替换为恶意代码，或者替换里面的 DMG, ZIP 之类的资源） # 从这点来说，所以一定要在浏览器开启严格模式（非HTTPS不使用）
  # 4、（根据网络流量）归因到真实身份 # 这点倒是没必要担心，不要“被标记”即可。

  #  DNS污染：抢在正确DNS服务器前返回一个错误的IP地址，导致域名无法访问。
  #  SNI阻断：在HTTPS连接建立初期，通过明文传输的服务器名称指示（SNI）来识别并阻断对特定网站的访问。
  #  IP封锁：直接将目标服务器的IP地址拉入黑名单，丢弃所有发往该IP的数据包。
  #  深度包检测 (DPI)：分析流量的数据特征，识别并干扰如 Shadowsocks、VMess 等代理协议。
  #  关键字过滤：检测流量中的敏感词，并切断TCP连接。
  #  主动探测：模仿正常用户访问可疑IP和端口，如果服务器未能返回合法的网站响应，则判定为代理并进行封锁。

“被针对的不是sk泄漏，而是入口特征固定：同端口、同指纹、同参数，封锁探测方做“批量规则”会更轻松（比如直接按端口或者行为模式打）”

代理内核（协议实现引擎）​

代理工具bottom-up来说就是 代理协议 -> 代理内核 -> client。可以理解为上游、中游和下游。

代理协议       （上游）
    ↓
代理内核（裸核）（中游）
    ↓
Client        （下游）


简单来说，

singbox, clash 这些就是内核，是结合上下游的方案，在整个体系中最为重要

而上游的 vless,

https://grok.com/c/d53cb047-28f7-4c90-b77d-9c233d4c3e9e?rid=548b16df-bced-4571-8021-9f6d49528a72

这里想表达两个观点：

  • 1、直接用内核而非client。
  • 2、内核应该用singbox，而非其他方案。

对我来说，我现在NixOS上打算直接使用代理内核，所以client的纷纷扰扰也就不考虑了（确实是纷纷扰扰，基本上都是套个Electron（mihomo-party）、Tauri（clash-verge）或者 fluter（FLClash），各种feats多一点少一点，还经常有bug，还有跟上游内核有骂战的（mihomo-party），有的还被公司收购了，后面肯定要做商业化运营，QTMD吧，我还不如直接用内核呢）。client不谈了，但其实内核可选空间也不大，总的来说就3家（clash系、v2ray系、singbox）。

X-ray是对v2ray的分叉，解决了前者新协议支持弱的问题。clash系的核心是clash-meta（Clash则是基于前者的lite版本，资源开销更低，也移除了TUN模式和高级规则集这两个功能。目前已经EOL了（因为这两个feats算是核心功能了，并且大部分clash的client都是基于clash-meta，所以继续维护clash内核意义不大了））。我不考虑用singbox，除了老生常谈的“配置频繁变更，兼容性极差”、“配置复杂”以外，singbox只支持JSON配置，我不喜欢，遂不用。【】研究了一下，使用singbox基于两点原因：

1、必须通过API调用mihomo（singbox支持command）。

2、singbox的JSON配置并不需要手动维护（通常都是机场提供URL，除非需要自己改规则、改策略组、添加自建节点）。但是这个“除非”本身就被考虑在内了，可以被 substore、sing-box-subscribe 之类的工具完美替代了。

代理协议横评​

tip

可以先看 2025年度代理协议"拉到夯"综合排名 来建立基础印象，这个视频偏使用，但是对代理协议的收录应该是目前最全面的。

下面我们从

【基本认知】代理协议看3层​

日常说“代理协议”，很多时候其实说的不是单个协议，而是一整套 stack。

为了避免后面把不同层次的东西混在一起，可以先粗暴拆成 3 层：

- 主协议：负责认证、封装、会话组织，比如 VLESS、Trojan、Hysteria2
- 传输层：负责数据怎么跑，比如 TCP、WS、gRPC、QUIC
- 安全层：负责握手外观、加密方式和抗探测能力，比如 TLS、REALITY

所以实战里真正拿来比较的，通常不是一个词，而是一整套组合，比如：

  • VLESS + TCP + REALITY
  • VLESS + WS + TLS
  • Hysteria2 + TLS

如果硬要往 OSI 上套，可以这样记：

  • 主协议相当于应用层（L7）
  • 传输层相当于传输层（L4）
  • 安全层相当于夹在两者之间的一层，近似看作 L5-L6

这里说“相当于”就够了，不必太教条。重点不是分层理论，而是后面做比较时别串层。

【代理主协议】​

先比主协议，因为它决定整套方案的底色。

还是那句话，

“不同的传输层协议，本身就决定了不同的EC(拥塞控制)”

而 EC 不是孤立变量。它往外会继续决定几件事：

  • 流量在网络里的行为长什么样
  • 差线路、高延迟、高丢包下怎么退化
  • 外层伪装应该往哪条路做
  • 最后整体的抗封锁能力和性能上限分别落在哪

所以看主协议，不能只看“它支持什么”，而要看：

它天然更适合站在哪种传输语义上。

- 抗封锁能力：它最终会长成“像什么流量”，以及能不能扛主动探测
- 拥塞控制：它天然继承的是哪套传输世界，TCP 还是 QUIC/UDP
- 性能特点：它在高延迟、高丢包、QoS 场景下的行为会不会变形
VLESS​

VLESS 的核心不是“自己多强”，而是它不预设唯一答案。

它本身更像一个干净的上层封装，可以继续往下挂不同传输层和安全层。也正因为如此，VLESS 实际上是在吃“下层”的红利，也继承“下层”的限制。

这意味着：

  • 挂 TCP，它就进入 TCP 世界，性能、退化方式、EC，都跟 TCP 绑定
  • 挂 WS / gRPC，它就进一步进入 Web 语义，外观更像正常站点流量，但额外封装也更多
  • 挂 REALITY，它就把重点转到握手伪装和低维护成本
  • 挂 Vision，它优化的是这条栈的流量路径，而不是改主协议本身

所以 VLESS 最强的地方，不是某个固定形态，而是：

它允许把“主协议”这件事尽量做薄，把性能、外观、抗封锁能力分别下放给传输层和安全层去解决。

这也是为什么 VLESS 特别容易成为主力底座。不是因为它单体最猛，而是因为它最容易被调成你想要的样子。

Trojan​

Trojan 的路线要收得更死一些。

它从一开始就更强调：

尽量把自己塞进“正常 HTTPS”这套叙事里。

所以它的优点很直观：

  • 外观目标明确
  • 设计语言统一
  • 很容易理解它为什么“像正常流量”

但它的问题也同样直观：

  • 路线更窄
  • 对外观的依赖更强
  • 灵活性不如 VLESS 这种“底座型协议”

换句话说，Trojan 不是不能打，而是它天然更像一条收敛型路线：想法明确，外观统一，但可塑性没那么大。

如果已经有 VLESS + REALITY 这种更适合自建维护的路线，Trojan 的存在感就会下降。

hy2​

HY2 的价值在于：它根本不在同一个战场上。

VLESS / Trojan 这类协议，哪怕外层怎么变，骨子里大多数时候还是在 TCP 那个世界里做文章。HY2 则不是。它从根上就押在 QUIC / UDP 这条线上。

这带来的不是“速度更快”这么简单，而是一整套行为差异：

  • 它吃的是 UDP/QUIC 的传输语义
  • 也继承了这套语义对应的 EC 和退化方式
  • 所以在高延迟、高丢包、QoS 场景下，它经常会表现出完全不同的性格

这就是为什么 HY2 看起来总像“异类”：

  • 它不是在 TCP 世界里继续卷伪装
  • 而是直接换了一套传输地基

所以 HY2 的强项非常鲜明：

如果线路环境对 QUIC/UDP 友好，它能拿到 TCP 路线很难拿到的性能特征。

但代价也一样鲜明：

  • 更吃网络环境
  • 更难复用传统 Web/CDN 外壳
  • 不是那种“一条栈打天下”的保守型方案

所以 HY2 适合保留，但它更像另一条路线，不是 VLESS 的简单上位替代。

AnyTLS​

AnyTLS 值得看，但看法也应该放在这个框架里。

如果说 VLESS 的思路是“把主协议做薄，把差异下放给传输层和安全层”，那 AnyTLS 更像是在说：

既然最后都要落到 TLS 外观，那不如直接围绕 TLS 本身来做主协议。

所以 AnyTLS 常被强调“可变形能力”。

这句话真正的意思不是“它功能更多”，而是：

  • 它试图把 TLS 外观本身做成主战场
  • 一旦某种特征被识别，理论上还能继续沿着 TLS 这条线变形

这条路的优点很诱人：

  • 更贴近 TLS 本体
  • 外观塑形空间更大
  • 在“特征对抗”这个问题上更有想象力

但问题也很清楚：

  • 越靠近“可变形”，越吃实现和调参
  • 越靠近“可变形”，越不适合追求稳定省心的个人长期维护

所以 AnyTLS 的吸引力是真的，但它更像一条进攻型、研究型路线，不一定适合作为默认主力底座。

小结​

如果只用一句话概括这几个主协议的差异，可以这么记：

  • VLESS：底座型协议，强在可塑性，真正的能力来自“怎么挂”
  • Trojan：收敛型协议，强在 HTTPS 叙事统一
  • HY2：异路线协议，强在直接换到 QUIC/UDP 世界
  • AnyTLS：进攻型协议，强在把 TLS 外观本身当主战场

所以主协议横评，核心从来不是“谁功能更多”，而是：

它天然站在哪个传输世界里，又因此继承了哪套 EC、外观和对抗路径。

【传输层】​

传输层决定的，不是“高级不高级”，而是这条流量在现实网络里到底怎么表现。

可以粗暴理解成：

  • TCP：最稳，兼容性最好，但高丢包时容易被拖慢
  • WS / gRPC：本质是借 Web 壳，适合已有站点和反代体系
  • QUIC / UDP：更激进，在线路合适时表现很好，但更吃环境

所以传输层不是单纯比谁快，而是看你到底想要什么。

如果目标是长期主力、自建维护、少折腾，VLESS 这边更自然会往稳定路线靠。 如果目标是保留一条风格完全不同的补充栈，那 QUIC / UDP 这条路就值得单独留着。

【安全层】​

安全层决定的，是这条流量在外面看起来像什么。

TLS 这条路很传统：成熟、通用、生态完整，但代价也明确，需要正常域名、证书，很多时候还要搭 Web 壳。 REALITY 则是另一种思路：尽量保留正常 TLS 外观，但不想真的维护一整套站点和证书体系。

所以安全层不是“都加密了就行”，而是要看它服务于哪条栈。

如果硬压成一句话，可以这样记：TLS 解决“有证书的正常外观”，REALITY 解决“低维护成本下的握手伪装”，uTLS 解决“client hello 指纹”，Vision 解决“flow/流量路径优化”。

放到这篇文章的场景里，结论其实很直接：

  • VLESS + REALITY + Vision：重点是降低维护负担，同时保留足够强的抗封锁能力
  • Hysteria2 + TLS：重点是顺着它本来的路子走，老老实实用正常域名和证书
REALITY​
tip

主流思路是伪装成 TLS协议，但也有可能被阻断（握手阶段，握手的header里有SNI标明目标网站），怎么解决？

最直接想到的当然是加密了，加密握手阶段（ECH）。但是这么一来，特征也很明显，我GFW直接识别你header是否加密了不就行了？一抓一个准，那怎么解决呢？

REALITY 的巧思就在于此，对SNI做伪装，伪装成代理节点，这就是“借用TLS证书”

REALITY 最核心的价值，不是“又一种 TLS”，而是把“伪装成正常 TLS 流量”这件事做出来，同时不需要自己真的维护域名、证书和整站。

简单说，就是可以“偷域名”：借一个正常网站来伪装握手，让外面看起来像是在和那个站点建立 TLS 连接。这样就不用像 WS + TLS 或 Trojan + TLS 那样，先准备好自己的域名、证书和 Web 外壳。

所以 REALITY 解决的首先不是“加密有没有”，而是“外观像不像”以及“维护成本高不高”。

Vision 和 uTLS 也经常和它一起出现，但三者不是一回事：

  • REALITY：处理的是握手伪装和整体外观
  • uTLS：处理的是 client 端 TLS 指纹，尽量让 ClientHello 更像主流浏览器
  • Vision：不是 TLS 指纹工具，更接近 XTLS flow 的优化项，重点不在伪装，而在传输路径和流量表现

所以社区里经常把 REALITY + Vision + uTLS 一起讲，是因为它们常一起出现；但职责并不相同，不能简单看成同一个东西。

如果非要压成一句话，可以这样记：

  • REALITY 处理“像不像正常站”
  • uTLS 处理“client hello 像不像浏览器”
  • Vision 处理“这条流怎么跑得更顺”
【伪装域名】怎么选择？
- 【伪装域名】怎么选择？
# 要求：
#目标网站最低标准：国外网站，支持 TLSv1.3 与 H2，域名非跳转用（主域名可能被用于跳转到 www）
#加分项：IP 相近（更像，且延迟低），Server Hello 后的握手消息一起加密（如 dl.google.com），有 OCSP Stapling
#配置加分项：禁回国流量，TCP/80、UDP/443 也转发（REALITY 对外表现即为端口转发，目标 IP 冷门或许更好）
#
#没有屏蔽的大厂域名也可以，比如 www.apple.com, www.microsoft.com , www.cloudflare.com , www.samsung.com
#
#OCSP Stapling支持检查：
#http://web.chacuo.net/netocspstapling
#
#进入这个域名选择网站
#https://bgp.tools/

【CDN/套壳】​

套 CDN 不是协议层本身，更像部署形态。

它主要影响的是两件事：

  • 传输层：什么流量能不能接进 CDN
  • 安全层：外面看到的流量外观会不会更像正常站点

这也是为什么 WS + TLS + CDN 这套思路一直很常见：它天然更容易借 Web 基础设施和 CDN 外壳。

反过来看，Hysteria2 这条路就没法这么玩。原因不复杂：HY2 走的是 QUIC/UDP，而 Cloudflare 默认并不代理这类 UDP 代理流量。也就是说，不是 HY2 不能伪装，而是常见 CDN 套壳方案本来就不接这条路。

所以“能不能套 CDN”不是主协议本身强不强，而是这条 stack 的传输层和外部基础设施能不能对上。

而且能套 CDN 也不等于更强，很多时候只是换了一种入口形态，同时也引入了额外约束。

tip

套CDN的正反两面在于

原站IP隐藏，抗DDos，但是链路更长，latency不如直连

选择了稳定性，牺牲了latency

【总结/主流方案】为啥目前只用了vless和hy2?​

最后保留的不是“最强协议”，而是两条分工不同的 stack：

  • 主力栈：VLESS + REALITY + Vision
  • 补充栈：Hysteria2 + TLS

前者负责长期主力、综合均衡、低维护成本。

后者负责另一种性能特征，作为补充路线存在。

如果压成一句更像选型结论的话，那就是：主力选 VLESS + REALITY + Vision，因为它是最均衡的长期底座；保留 HY2，是为了拿另一套 QUIC/UDP 世界的性能特征。

所以这部分真正想说明的是：

代理协议不能只看名字，要看整套 stack。 真正该选的，也不是单个协议，而是适合自己线路、维护方式和使用场景的那套组合。

线路​

线路是整个fq流程里最重要的一环

为什么这么说？

可以把线路类比成不同道路等级，县道（40）、省道（60）、国道（80）、高速（120），本身就有速度上限

而我们所说的 线路机、建站机、大盘机 之类机器配置各异的机器，则可以类比为 跑车、家用车 等或好或坏的车子。

你车子再好，在县道上跑，速度也起不来。fq也是同样的，你哪怕是96C256GB的机器，如果跑在普通线路上，做网络代理也没法用。这个道理是相通的。

当然，除了线路本身，还要看机器本身的 带宽（可以类比为车道数）和流量（机器本身能带多少油），否则你线路再好，也无法更快到达目的地。

tip

这里就需要引出一个概念：三网优化

三网优化，就是走各自精品线路，电信 CN2GIA, 联通9929, 移动CMIN2

这里需要注意的是，选择三网优化机器，通常是个性价比略低但不会出错的选择。这点怎么说呢？具体来说，有些人看家里是电信网络，所以就只买了CN2GIA优化的机器，但是公司呢？出差呢？手机热点呢？会有层出不穷的场景，所以选择三网优化是最不会出错的选择，否则跨运营商场景下会被 QoS。并且通常来说，三网优化机器相较于单网优化机器，也并不会贵太多。

线路机 VPS 选择​

DMIT(大妈) 详细测评与产品介绍


再次研究了一下自建节点相关的问题。结论在前，最终决定购买DMIT的【LAX.AN5.Pro.TINY】。任何对于VPS的购买决策都可以分为三步：１、买哪的机器？２、买哪个云服务商？３、买什么配置？

这三个问题环环相扣。简单如下，***因为决定了LA的机器，所以决定买DMIT。因为需求是“只需要翻墙使用”，所以买网络最好、配置最低的高性价比机器。***

那么这个决策可以拆分为两部分：1、为啥不考虑？2、为啥不考虑BWG?

- 1、之前专门贴过别人的经验，“说一下我用过的吧，雨云，yunyoo，zgo，腾讯云，阿里云，火山引擎，如果想用香港的那最推荐的就是yunyoo，三网优化，大陆的推荐雨云，还有就是火山引擎，有首购折扣，4c8g一年才200，就是cpu性能有点低，带宽有点低”。也查了 zgo, yunyoo, lisahost, bytevirt 之类在【digvps】上评分还不错（8分）的机器。但是实际体验基本上都是一坨，风评一般。
- 2、为啥不用BWG? BWG主打性价比，但是
  - 1、IP较差。
  - 2、CPU不可长期占用（否则会限制单核性能）。
  - 3、超开超售严重（推广太多，因为AFF返利高）。


相反，DMIT就没有这三个问题，并且DMIT本身就是BWG的上游。

- 1、线路更稳，IP更好，且支持免费换IP（如果IP被墙，仅一次，之后每次$5）。
- 2、不超售。当然，同样是 $88/年，BWG能买到 2C2G40GB 1T流量 2.5GB带宽的机器，而DMIT只能买到 1C2G20GB 的机器。有得有失吧算是。

***总的来说就是，直接用最好的，最省心、省力。***

---

那么更进一步的，为啥最终决定买【LAX.AN5.Pro.TINY】这个套餐？


这里需要解释这个套餐的4个参数分别是啥意思，开头（美西LA）和结尾（机器参数）不多说，对于我们的翻墙需求来说，核心是中间的【AN5.Pro】，这两个参数是绑定的，核心在于后面这个参数，有【Pro】、【Eyeball】、【Tier1】三种可选，“PRO线路保证三网最优线路，一般是CN2GIA；eyeball的话尽力保证好的线路，但是有时候可能切线（即在 Tier1 的基础上，尝试优化中国大陆回程／去程（“reasonable effort”）但不保证。）；tier1不保证任何线路，一般是国际线路，直连延迟很高。” 所以我们毫无疑问直接选择【PRO】

再解释下最后这个参数，DMIT的机器分为4档，【TINY/STARTER】【MINI/MICRO】【MEDIUM】【LARGE/GIANT】就是性能参数区别，４档的典型机器分别是 2C2G, 4C4G, 6C8G, 8C16G（某档内的区别更多是磁盘空间之类的其他区别）

那么我们这种专为翻墙需求的机器，性能并不重要，所以选择网络最好（Pro）的最便宜的机器就可以了。

1、正常来说，双向流量 1T/月 正好，再多就用不完了

---

另外，还有一个决策，之前考虑HK和LA各自一个落地鸡，所以看了zgo之类的机器，但是实际上这些机器的性价比也很低（远不如阿里云之类的）。但是用阿里云等大厂的机器又很难搞翻墙节点。这就“一根筋两头堵”了。但是在我不打算在HK搞翻墙节点之后，就很简单了，在HK买个4C8G以上配置的机器，用来作为主VPS就可以了。LA的机器用来作为唯一落地鸡使用。另外，LA的机器直接跑shell刷节点，挂个指针就完事了。HK的机器需要刷成nixos。

以上是我之前写的

(1) 小墨同学 on X: "DMIT涨价之后，我把搬瓦工所有优化套餐翻了一遍" / X

主流相关工具​

zashboard​

如果使用裸核，无论是 singbox 还是 clash，都需要一个东西来 select node

几种形态的方案里，最好用的毫无疑问是 WebUI

而 WebUI 里最好用的，莫过于 zashboard

sub-store​

- url: https://github.com/sub-store-org/Sub-Store
# sub-store 的 why （也就是为啥需要配置 ss）
# 核心在于两点：大量节点、节点转换
# 前者指的是 “我觉得, 如果节点很多(比如到处搜集免费节点的人, 节点总数有可能成千上万), 那么这个测速+筛选的工作不应该由翻墙客户端来做, 应该由一个单独的实体来做。我找了一圈信息, 最终决定用 Sub-Store 完成这个任务.” 我之前想要做节点打野，所以也就需要 ss，需要把多个订阅URL做聚合，并支持 脚本操作/过滤、节点排序/去重、区域过滤、协议过滤、正则过滤/排序/删除/命名 之类的pipeline操作，最终转换成符合需求的脚本。
# 后者，如果节点不多的话，就不需要 ss 了吗？也并非如此，这里还有一种情况，就是有多个使用场景，比如说 “这就造成了一个问题，你很可能准备了多套配置模板，用于不同的终端（他们之间主要是inbounds字段不同），如Linux、windows、iOS，因此当你修改自定义规则的时候，需要同时修改多套json。依赖sub-store，可以很容易解决这个问题，你只需要在sub-store中存储一个名为“custom_rules.json”的文件，内容格式如下：”
# 即使只有一个节点，但是最终client不同，那就需要用ss去生成符合各client需求的配置（注意这点如果用nix也可以处理，也就是在nix里处理 inbounds，但是这个终究只能在nix里使用，如果是ios之类的，就无法使用了）

# 以上这个认知有问题吗？
# 没啥问题，但是这个顺序就说明，没抓到ss的核心能力。ss的核心在于“订阅转换”。
# **“大量节点”本身不是 Sub-Store 的核心能力**；它只是把需求放大后更痛的场景。真正的核心能力是把订阅处理抽象成一个**中间层流水线**：**parse → process → produce**，把“解析/过滤/改名/排序/生成目标格式”从客户端剥离出来，集中处理。
# 1. **把订阅处理从客户端剥离出来，集中成可编程流水线**（不看节点多少）。
# 2. **一个真源，多端多格式输出**（跨客户端/跨终端维护成本直接降维）。
# 3. **自动化分发/同步/可迁移**（订阅作为资产管理，而不是散落在各客户端里）。

机器​

总结​

- topic: 【技术选型】代理协议
  qs:

    - TUN模式 #增强模式创建了 TUN 虚拟网卡（需要 root 权限，macOS 下可以通过 HelperTools 的方式处理，比如 ClashX-Pro 的 Helper 文件位于 /Library/PrivilegedHelperTools/com.west2online.ClashXPro.ProxyConfigHelper），并配置路由表，目的是将数据转发到TUN设备上，但是由于TUN模式处于网络层，需要通过gVisor/System网络栈来获取传输层的数据，经过本地端处理后，将数据转发到服务节点。不过由于使用了 TUN 模式，一般需要设置本地的 DNS 服务器，目的是使用 FakeIP 地址......具体的细节可以看 clash 源码 :)

    - 【Trojan-killer】GFW 流量探测的具体原理？ # [XTLS/Trojan-killer: Detect TLS in TLS.](https://github.com/XTLS/Trojan-killer)
    - 【原生IP】啥是 原生IP? 怎么判断某个IP是否是原生IP? # [Hurricane Electric BGP Toolkit](https://bgp.he.net/) 原生 IP 就是指该 IP 的注册地址和服务器机房所在的国家一致的 IP，反之，非原生 IP 就是指 IP 的注册地址与服务器机房所在地不一致的 IP，也就是常说的这个 IP 是被广播过去的。


0% read