关于远程连接

家庭网络情况：光猫桥接，路由器拨号，NAS分配了ipv6地址，防火墙放行了NAS特定端口的流量。
绿联NAS用了一个多月了，外网连接时，登陆后过一会就会显示为p2p直连模式，潜意识觉得应该很快，所以没在意。用着用着发现P2P模式下，外网上传很慢，下载也很一般，经过反复试验，手机流量（同一运营商）外网上传速度基本都是1~2M/s，下载差不多5M/s左右的速度，根据个人以往使用的经验，这个速度是比较慢的。而且有时候发现一会儿显示P2P模式，一会儿又显示中转模式......
于是对比了一下相同网络下的群晖NAS，使用官方的QC连接，没有打开中转，在外网连接后，手机上传到群晖的速度达到约10M/s，从群晖下载速度达到15M/s以上。

这个问题折磨了我几天，都没搞明白，问客服也答不出个所以然。然后我在绿联上试了一下DDNS连接，速度直接起飞了，与群晖直连的速度基本差不多。
所以这是为啥，我不明白，我问豆包（如果她说得对），大概懂了，绿联官方的UGlink有很大问题，希望可以优化，并且增加“是否启用中转”的选项，现在基本都有IPV6，完全可以像群晖一样用TCP直连。

下面是豆包的解答：

两端同运营商、均有公网 IPv6，P2P依旧远慢于 IPv6 DDNS 完整原因。

先明确前提：IPv6 无 NAT、同运营商骨干路由延迟极低，不存在跨网 QoS、CGNAT 端口刷新问题，速度差距全部来自「绿联 P2P 协议架构、运营商 UDP 策略、软件机制」三层硬损耗，和路由无关。

一、底层传输协议天生不对等（最核心差距）

1. P2P：UDP 打底双层封装，运营商 UDP 单独限流

绿联 ICE P2P 流程：文件TCP 数据 → 封装进 UDP 打洞报文 → IPv6 传输→ 客户端拆 UDP 再拆 TCP

国内运营商普遍对长连接 UDP 小包流实施 QoS 限速，同运营商也不例外：TCP 家用上行可跑满 90%+，UDP 常被压到30%~60% 带宽上限；

双层协议头带来额外分片、重组开销，每包有效载荷占比下降，同等流量下传输耗时显著增加；

UDP 无内置拥塞控制，一旦轻微丢包，上层 TCP 立刻缩小滑动窗口，速度持续走低。

2. IPv6 DDNS：原生单层TCP 直连，无额外封装

DDNS 访问链路：客户端 TCP → IPv6 直达 NAS，仅一层TCP+IPv6 头部

运营商 TCP 流量优先级高、无隐性限速，带宽利用率稳定 95% 以上，能直接摸到家庭宽带上行物理瓶颈。

二、P2P 必须持续占用带宽的信令 +心跳开销（DDNS 完全没有）

哪怕两端都是公网 IPv6、同运营商，P2P全程离不开绿联云端信令交互：

连接建立阶段：NAS、客户端分别向绿联STUN 服务器上报 IPv6 地址，服务器交换两端地址，这一步会占用上行；

传输全程高频 UDP 心跳保活：每几十毫秒双向发送检测小包，防止链路被路由器 / 运营商空闲断开；

持续不断的小包挤占上行资源，真正用于文件传输的有效带宽被持续稀释；

IPv6 前缀更新重协商：家用 PD 前缀定时刷新，P2P 不会自动同步新 IPv6，通道失效后必须重新走一遍完整信令协商，传输中断、反复减速重传。

而 IPv6 DDNS 仅首次 DNS解析，解析完成后全程无第三方服务器参与、无持续心跳包，所有带宽全部用来传文件。

三、绿联 P2P 内置智能链路降级逻辑，人为压低平均速度

系统后台实时监测 P2P 链路丢包、延迟，只要出现轻微抖动就触发降级：

心跳 UDP 包少量丢包 → 判定P2P 链路不稳定，主动断开直连，短暂切绿联 TURN 中转；

长时间大文件传输时，后台主动限制 P2P 并发带宽，减少官方 STUN 服务器负载；

无手动锁定纯 P2P 开关，只能被动自动切换，“P2P 直连 + 中转” 来回跳，平均速度大幅下滑。

DDNS 完全脱离 UGLink 管控，厂商无任何带宽干预、自动降级逻辑，带宽只受运营商物理线路限制。

四、路由器 IPv6 防火墙对UDP/TCMP 的隐性干扰

......

五、MTU 分片问题只折磨 P2PUDP 链路

......

为什么同样的网络环境下，使用群晖的官方 QuickConnect 服务的速度可以跑满带宽？它和绿联的官方连接有什么区别？

群晖 QuickConnect vs 绿联 UGLink P2P：同运营商双公网 IPv6 环境下速度差距根源

先点明核心结论：

群晖 QC 在两端公网 IPv6、同运营商时能跑满带宽，是因为它的 P2P 直连逻辑、协议栈、服务器策略、链路优先级全部针对国内 IPv6 优化；而绿联 UGLink 的 P2P 架构设计初衷是降低厂商服务器负载，牺牲传输效率，再叠加 UDP 底层先天短板、强制自动切换逻辑，哪怕 IPv6 无 NAT 也跑不满上行。

一、连接优先级与链路选择逻辑完全相反（最关键差异）

1. 群晖 QuickConnect：优先复用原生 TCP 直连，P2P 为辅，兼容DDNS 逻辑

：

2. 绿联 UGLink：强制优先自研 UDP-P2P 隧道，原生直连被后置

UGLink 固定策略：

强制先尝试 UDP P2P 打洞（无论是否有公网 IPv6、是否做好端口转发）

P2P 链路测速不达标 / 丢包，才临时切官方中转

不会自动复用路由器已放行的 TCP 原生端口

哪怕你配置了 IPv6 端口转发，UGLink客户端依然会套一层 UDP 封装隧道传输文件，不会直接走裸TCP，天然多一层开销。

社区大量用户反馈：明明 IPv6 可裸连，APP 仍强行套 P2P 隧道，速度暴跌，且无手动关闭 P2P、强制原生直连开关

。

二、传输协议栈设计：群晖规避 UDP 限速，绿联全程依赖 UDP 隧道

三、P2P 协商、心跳机制开销差距巨大

四、厂商服务器策略与链路干预逻辑相反

群晖 QuickConnect：直连场景厂商不做任何带宽限制

绿联 UGLink 内置主动压低P2P 带宽的后台策略

绿联设计 P2P 的核心目的是减轻自家中转服务器负载，因此内置限速逻辑

五、IPv6 兼容性优化深度不同

群晖 QC 原生深度适配 IPv6

绿联 UGLink IPv6 仅用于打洞协商，业务流量仍套 UDP 隧道

IPv6现在很多还没有普及，很多公共WIFI没有开启V6用不了DDNS。

风雨潇潇 发表于 2026-7-6 09:38
IPv6现在很多还没有普及，很多公共WIFI没有开启V6用不了DDNS。

如果双方都有ipv6的情况下，完全可以参照群晖直接TCP直连，没必要强制再走绿联官方的p2p还套一层UDP

twister 发表于 2026-7-6 11:16
如果双方都有ipv6的情况下，完全可以参照群晖直接TCP直连，没必要强制再走绿联官方的p2p还套一层UDP ...

确实