@pdog18 是的 Alist 注定是阶段性产物，后续还是够折腾。你如果是想方便父母用的话，家里买个最便宜的极空间 Q2c, 电视上装个极影视 APP 就行了，资源自己通过 BT 或 PT 的方式去找，晚上下载好服务白天就能看。如果你有 Apple TV + Infuse + Emby + 梯子，也可以用我的付费方案，找个 Emby 资源服务器用。

虽然帖子无关，但是我想说，觉得楼主的头像很有品味。

有法律风险的项目最好规避掉这些风险之后再考虑变现

绝对不是。

你用过 Alist 吗，是不是很方便，但如果 Alist 的接口将来发生变化，或直接都用不了了呢？亦或者你用过类似电视家这种直接看 IPTV 的软件吗？是否经历过家里老人吐槽好好的看电视软件不能用了，或是完了卡顿不稳定。市场规律和互联网企业的历史经验会告诉我们，与其相信互联网企业或个人开发者服务的长期稳定性，不如自己买一台 NAS 在家里 （当然也可以简陋点，路由器 + 硬盘，但是出问题远程不好搞）。老人只需要会开电视 APP 选片就行了，本地片源我们帮忙搞好，不要给老人弄太复杂且流程后面可能会变的东西，比如会员服务范畴导致差异，软件更新 UI 操作流程导致的差异等等... 原是需要反复折腾的东西，后面都会返璞归真，免费的东西是最贵的。

我目前的方案是家里一个 Apple TV + Infuse + 付费 Emby 服（网络资源） / SMB 接本地 NAS 库. 考虑到老人的习惯，还要用老旧的 IPTV 机顶盒看电视（在 Apple TV 用 APTV 的网络源他们嫌弃换台慢），所以老的机顶盒也还在，HDMI 切换都是单独买了个有物理按键的小设备，就是怕切换显示屏的 HTMI 信号输入流程太复杂老人记不住... 直接按一个键就好了。

虽然我们自己的折腾能力很强，但是给家里老人的服务，其流程最好是 “一成不变” 的，可能的变化要控制在我们自己手中，而不是交给互联网厂商，否则会有更多的阿里云第三方权益会员包等着你。

@745839 就是 AMD 核显的 24 大版本，持续很久了，我回退 23 才解决。

是这个地址： [罕见的 AMD 集显驱动内存泄漏]( https://blog.chai.ac.cn/posts/amd-igpu-memory-leak-tracking)

@745839 你的 AMD 驱动版本是多少？ 24 版本的话可能是遇到内存泄漏了。

参考《[罕见的 AMD 集显驱动内存泄漏]( http://localhost:5173/posts/amd-igpu-memory-leak-tracking)》

@liuzimin 确实有一种假设，像云厂商内部完全可以有独立的队伍（对外肯定称不是自己人）搞这种对自家已经建立依赖的商业客户进行攻击的操作，然后让你买他的防御业务，等你买了一段时间后，攻击升级，你的防御也得被迫升级。真是这样的话，直接变成云厂商玩具算了。

经过 [实际体验]( https://blog.chai.ac.cn/posts/zero-trust-mesh.html)，ZTM 真香！

使用代理是可以的，但是通过环境变量设置是影响不到 pull 的

很多人没有区分清楚是 pull 的时候代理还是 run 和 build 的时候代理：

可以参考这个博文的解释： https://blog.chai.ac.cn/posts/docker-proxy.html

@hanfengzxh 听你这么一解释，我就理解 ZTM 优势的地方了，刚好我自己有个地方可以用到，谢谢。

@chowdpa02k413 是的，所以还是建议用一些具备打洞 P2P 直连能力的工具。如果单纯是公网云，那我平时简单使用的话，直接搞个 rustdesk 远程桌面到内网机器得了...

@hanfengzxh 不敢苟同。你想从网络协议层面对比的话，第 7 层反而是最外层的，Tailscale 的 WireGuard 协议工作在 OSI 模型的第四层，也就是传输层，它直接处理 IP 数据包，而不是 HTTP 请求。这使得 WireGuard 可以用于任何基于 IP 的通信，不仅仅是 HTTP. 我自己使用的另外一个 Zero Trust 应用是 Cloudflare Tunnel, 不但支持 HTTP2 也支持 QUIC 协议，但是局限性依旧很大，这类应用完全无法比拟虚拟局域网。我举个最简单的例子，数据库和 SSH 协议同为 L7 层应用层，这个时候试问 ZTM 是否还能有效？要知道 IP 层的通信是无状态的，所以需要额外的机制来保持和管理连接状态，这些都增加了实现的复杂性...

> 其他的广泛的协议支持、平台兼容性、性能，都是不输 Tailscale ...
> 所在在某些受限的场景，ZTM 比 Tailscale 适应性更强。

不知道从何得来的结论，请问是否严谨地做过对比测试，直接抛结论没有说服力的，也容易误导不了解情况的人。

我明白楼主自己成功地找到了一个异地组网方案并成功实施的欣喜之情，但这不意味着就能够认为自己的方案一定是最优的，任何事情都需要辩证比较才能下结论。Tailscale 的宣告路由表功能我想楼主并没有实际体会过，简单解释一下，只要你的外地设备进入 Taiscale 网络并接受了你家里的网关设备宣告的路由，从使用体验上来说，你可以完全认为你的家庭设备已经对你的外地设备可见（就好像在一个局域网内，所以叫虚拟局域网）。而且 Tailscale 完全没必要和 ZTM, FRP 一样去为应用做单独的端口映射设置。更何况现在 Tailscale 除了 CLI 管理，还提供了完全基于 Web 界面的用户管理和 access control, 从易用性来说已经是第一梯队了（注意我这里没说是绝对第一）。

像我这种懒人，一个所谓的异地组网工具，要求单独配置端口映射、没有简单可用的 UI 客户端，已经足以劝退。

@OliverLee 同，都有云主机了，直接用来搭建个 derp 节点，结合 tailsacle 使用，能直连就直连，不能直连走 derp 中转多香啊。我一般是旁路由安装 Tailscale 负责宣告路由表，这样只要其他设备都能访问得到。

@1423 每个人的常识水平不一样，你不能因为自己的常识可能更加接近这个领域就轻下断言说，你的这个比我的简单呀。对我这种垃圾菜鸡小白来说，要做到你的水平，我要懂 cloudlared 源码最基本的结构，我要去找到代理相关的配置。就算您给出提示了（可能您之前却有研究过），我为了让这个东西跑起来，我还得去自己编译程序加部署，这在我眼里怎么都不能算得上是流程上很轻松的事情。我并不是这方面的专业人士。

在我的视角里，我认为我的方案简单，也可能单纯是因为我的常识仅仅涉及到了改改 iptables 和 xray 配置，能快速跑起来不折腾，这是我认为的简单方案。我不是在阴阳怪气，我是真觉得我们对 “麻烦” 的定义不一样。

@1423 那请大佬给出 forked 后支持 http_proxy 的代码供我等小白学习一下，反正你觉得不麻烦

@Chaiii 补充一下，针对楼主的情况，我更觉得有两种可能：

1. bitmagnet 不遵循环境变量中的代理设置 （我没用过不确定哈）
2. bitmagnet 确实使用了你的代理，但是代理规则未生效（走了直连，开全局 + tun 试试看）？

如果你不想玩旁路由，还可以试试用 iptables 级别搞透明代理。