关于 DUN.IM 的常见问答 - 12/2025

关于 DUN.IM 匿名服务

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

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

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

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

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

5、退款？
– 使用条款

6、协议互换？
– 可。

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

7、加密？

服务器加密：

– DUN.IM 全部线路均保持高强度加密，以隐私和稳定为优势，通过 入口节点服务器 -> 加密匿名服务器 -> 出口落地服务器 路由组成，最少 ≥3 跳，这是我们与其他服务最大的不同。

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

– ChaCha20 与 AES 加密算法详细分析比较

DNS 加密：

DNS over TCP，其本质就是 DNS over TLS 的加密前明文，但是测试中发现大多数服务商的 DNS over TCP 都存在严重问题，不具备实用性，故不推荐配置。
根据国内用户反馈和实际测试发现，tls://223.5.5.5 服务端未实现并发查询，使用时可能会出现严重卡顿，不推荐国内服务使用。
国外服务已全面支持：tls://1.12.12.12、tls://8.8.8.8、tls://1.1.1.1 均完整支持并发查询。
具体对比目前支持的所有加密 DNS 协议：
- – DNS over HTTP3 和 DNS over QUIC 的表现几乎完全一致，但是由于协议较新，服务端支持经常出现各种问题。且由于基于 UDP 但并非 53 端口，有可能遭遇 QoS 问题。
- – DNS over HTTP3/QUIC 在理论上比 DoH 有一点点微弱的优势（丢包时仅影响对应的 stream），但实践中很难体现。
- – DNS over TLS 比 DNS over HTTPS 在请求构造和解析上存在微弱优势，但是对于现代计算设备来说完全可以忽略不计。
- – DNS over HTTPS 的使用目前最为广泛，服务端兼容性与稳定性高。
- 综上所述，DNS over HTTPS 是普通用户最优选择。

设备 DNS 缓存更新 (刷新) 指南
 更多 DNS 相关文章

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

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

代理延迟：
Shadowsocks 协议的延迟已经达到理论极限（0-RTT），不可能再更高。
CPU 占用 / 加密性能 / 带宽上限：
对于大多数有硬件加速的设备，单次加解密操作开销在 0.1ms 级别，单次加解密操作开销在 0.1ms 级别，iOS 设备上带宽已可达 Wi-Fi 吞吐量物理极限。现在基本所有协议都使用 AES（CHACHA）加密。
安全性：
所有正确运用了现代加密算法的协议均不存在数据被强行破解的可能。TLS 类型协议提供有额外的（如前向安全）等更全面的保护。且投入使用时间越早的协议，则经受了更多的时间检验。而且由于上层承载流量通常也由 HTTPS/TLS 所保护，所以即使代理协议加密真的被突破（极其不可能），上层流量中也只有 SNI 会泄露。
multiplex 连接复用：
由于大多数网站和程序均已使用 HTTP/2 协议，自带了 multiplex 支持，所以并不会产生很多的底层 TCP 连接，代理层再支持 multiplex 的优化意义不大。而且 multiplex 的支持会导致额外的问题，如单 TCP 连接被限速，更加复杂繁琐的连接错误检查和纠错等。
混淆性：
目前没有发现常用协议间有显著的混淆性优劣差异。采用了 TLS 作为传输层的协议理论上更难被甄别，但是实际运用中暂未观察到明显差异。
gRPC：
gRPC 和其他一些类似的技术，只是方便开发者实现的一些技术框架和标准，对代理协议本身并没有提供什么改进和优化。
抗封锁：
不同协议由于其特征不同，目前被封锁主要是异常流量规则触发+协议特征的辅助判断，因此可能性各不相同，但是如果你现在用的协议稳定、高效，没有受到干扰，那就没有必要去追求其他协议。目前代理协议流量特征主要有以下几类：
- 明确特征：
  如原始的 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
延迟检测：
很多人用 ICMP Ping 去判断服务器是否可用。即使没有禁 Ping，对于中转，检测的仅仅是到国内服务器的延迟，并不能反应真实的可用性和延迟。
- HTTP 延迟检测是通过代理去访问指定外网网址，这会提供更为准确的可用性报告。
- 这个延迟数据和检测的网址有关，检测 http://www.google.com/generate_204 和 http://www.gstatic.com/generate_204 的延迟就会不一样，这是和检测网址所在线路，机房等决定的，不是节点完全决定。
- 国内很多服务商（如佩奇）会劫持检测网址，导致检测结果未到真实网址就提前返回，这会让延迟数据很低，看起来很漂亮，让延迟检测毫无意义。
- 如果遇到或怀疑服务商对 204 检测网址进行劫持，因为是网址关键词判断，可以选择非 204 的 url 进行检测，来判断真实的连接状态。
- 最后，延迟数据仅供参考，不代表真实使用体验，如：
  1. 动态网络状况：延迟数据通常是静态测量，而实际使用中网络环境动态变化，高峰期可能导致延迟增加。
  2. 多服务器交互：真实体验涉及多个服务器，延迟数据仅反映单点，无法涵盖整体情况。
  3. 带宽影响：高带宽提升数据传输速度，低带宽即使延迟低也可能导致体验差。
  4. 网络拥塞与稳定性：丢包、抖动等问题会影响体验，而延迟数据无法反映这些情况。
  5. 应用层优化：不同应用对网络需求不同，优化策略影响体验，相同延迟下体验可能差异大。
  6. 地理位置与网络架构：地理位置和 CDN 使用影响延迟，设备性能也影响体验。