远程Docker访问应统一采用客户端的连接策略（P2P/中转）

发现一个可以优化的点：远程Docker访问的连接逻辑，和客户端本身的连接方式不统一，影响了体验。

当前问题：

当客户端（如桌面端）与NAS成功建立 P2P直连 后，常规服务都走这条低延迟通道。但此时打开 远程Docker 访问（比如容器Web UI），系统会分配一个独立的 https://app-xxxx-xxxx.cnxx.ugdocker.link 域名。

经确认，此域名的流量没有复用已建立的P2P链路，而是走了服务器中转。这就导致，即使客户端是P2P直连，Docker访问却要走可能更慢的中转线路。

（当然，在 直连/局域网 场景下，Docker访问是直连的，这点和客户端行为一致。问题主要出在远程场景。）

具体建议：
远程Docker访问的连接方式，应该自动跟随客户端的全局连接策略。

• 客户端是 P2P直连，Docker访问就走P2P。
• 客户端是 服务器中转，Docker访问再走中转。
  

技术上是可行的，已有参考案例：
客户端内的 远程浏览器应用（Firefox） 已经实现了这个模式。如下图所示，远程Firefox访问的是 http://127.0.0.1:xxxx 本地地址，其流量通过本地客户端转发，并利用了客户端与NAS之间的最佳链路（P2P）。

这说明，把Docker的远程访问流量路由到本地客户端，再由客户端根据当前连接状态（P2P/中转）转发，在架构上是完全可行的。

优化好处：

• 体验提升：P2P下访问Docker服务（如Portainer、Jellyfin网页版）延迟大幅降低，操作更跟手，解决体验割裂问题。
• 减轻服务器压力：把大量Docker访问流量从服务器中转分流到P2P网络，降低服务器带宽和负载。
• 逻辑统一：所有远程服务访问逻辑一致，用户更容易理解，架构也更清晰。
  

希望开发团队能考虑这个优化，让远程Docker访问也能充分利用P2P直连的优势。

收到反馈，已将场景提交相关负责人确认~