DUN.IM 常见问答 – 2023/09/14

1、推荐的规则配置？
– 服务和配置分离，尽量最小化配置，除 CN 外全走代理，广告拦截配置自定义 DNS。(如 NextDNS)
– 参考配置。
– 客户端推荐，不推荐所有 Clash。

2、弹性流量？
– 系统统计的冗余流量，按特定规则分配。免费服务会判断使用者的状态，进行动态调整资源，正常使用不受限制，可通过加入会员获取更多资源。

3、开通时间？
– 24h 内开通，以实际为准。会为首次开通的用户增加 3 天不等的体验时间，以切换与熟悉配置和使用服务。

4、订阅配置？
– 一般只有 iOS App 不自带规则，需要订阅，其他客户端自带规则，你可以按这里教程进行配置。

你也可以通过 DUN.IM STORE 获取专属订阅。请注意避免泄露自己的配置信息，系统如果遇到不正常的流量，会根据使用条款进行处理。

5、退款？
– 使用条款

6、协议互换？
– 可。

1. ShadowSocks 是基于 TCP 和 UDP 的快速 VPN 方案，使用方便简单，分流自定义配置操作性强。
2. WireGuard，基于开源的 VPN 接入方案，优点是性能很强，已成为 Linux 系标准协议，可以非常安全的在任何网络环境下对等工作。
3. OpenVPN，可以用在一些旧系统及路由器上。

7、加密？
– 目前所有主流的浏览器均支持 AES 与 chacha20 进行 TLS 握手，在拥有硬件加速的设备上优先使用 AES，当不支持硬件加速时使用 chacha20，两者实际感知的差异可忽略。另根据Cloudflare 做的测试，chacha20-poly1305 比 AES-128-GCM 算法快 3 倍。更多参考。

8、对新协议的支持？
– 几乎每隔几个月，就会出现一种新兴的代理协议，支持各种新兴代理协议从来不是我们的目标，即使在资源允许的情况下，我们更倾向于实现被更为广泛接受和成为业界标准的协议（如 WireGuard），而非各种试验品。

部分用户执着于新兴的协议，主要是被一些花哨的宣传语所吸引，这些乱七八糟的特性没有任何好处，从各个角度来说：

1. 代理延迟：
   Shadowsocks 协议的延迟已经达到理论极限（0-RTT），不可能再更高。
2. CPU 占用 / 加密性能 / 带宽上限：
   对于大多数有硬件加速的设备，单次加解密操作开销在 0.1ms 级别，单次加解密操作开销在 0.1ms 级别，iOS 设备上带宽已可达 Wi-Fi 吞吐量物理极限。现在基本所有协议都使用 AES（CHACHA）加密。
3. 安全性：
   所有正确运用了现代加密算法的协议均不存在数据被强行破解的可能。TLS 类型协议提供有额外的（如前向安全）等更全面的保护。且投入使用时间越早的协议，则经受了更多的时间检验。而且由于上层承载流量通常也由 HTTPS/TLS 所保护，所以即使代理协议加密真的被突破（极其不可能），上层流量中也只有 SNI 会泄露。
4. multiplex 连接复用：
   由于大多数网站和程序均已使用 HTTP/2 协议，自带了 multiplex 支持，所以并不会产生很多的底层 TCP 连接，代理层再支持 multiplex 的优化意义不大。而且 multiplex 的支持会导致额外的问题，如单 TCP 连接被限速，更加复杂繁琐的连接错误检查和纠错等。
5. 混淆性：
   目前没有发现常用协议间有显著的混淆性优劣差异。采用了 TLS 作为传输层的协议理论上更难被甄别，但是实际运用中暂未观察到明显差异。
6. gRPC：
   gRPC 和其他一些类似的技术，只是方便开发者实现的一些技术框架和标准，对代理协议本身并没有提供什么改进和优化。
7. 抗封锁：
   不同协议由于其特征不同，目前被封锁主要是异常流量规则触发+协议特征的辅助判断，因此可能性各不相同，但是如果你现在用的协议稳定、高效，没有受到干扰，那就没有必要去追求其他协议。目前代理协议流量特征主要有以下几类：
   • 明确特征：
     如原始的 OpenVPN、SSH 等，这些协议并未为抗封锁所设计，所以存在明显的特征，容易被封锁。
   • 完全无特征：
     如原始的 shadowsocks、VMess 和其他衍生协议，此类加密后完全不具备任何特征的流量，可能容易被当成一个特征进行封锁。
   • 真实使用 TLS：
     如 Trojan，客户端不产生额外特征的情况下与标准 TLS 基本一致（如 Surge 的 Adaptive TLS Fingerprint 功能），但所使用的证书可能被用于判断。另外在使用该 TLS session 再去传输 TLS 流量时，可能产生一定的流量特征。但该特征不够准确，很难将特征用于封锁。
   • 模拟为 TLS：
     如 ShadowTLS，使得连服务器证书信息等特征都可以被伪装。但是任何伪装都有可能在实现中露出蛛丝马迹，需要时间和用户量方可检验是否可靠。另外封锁通常会纳入多种因素综合判断，如入口 IP 段等等，排除故障时应考虑各种原因而非仅协议问题。

     可阅读以下论文了解更多：
     The Parrot is Dead: Observing Unobservable Network Communications
     The use of TLS in Censorship Circumvention
     Detecting Probe-resistant Proxies
     How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic