@Donahue 我家云掉盘是咋回事，有结论没有，刚火的时候买过两个，因为有讨论掉盘的风险，，一直在吃灰

@yorkyoung #7 用的啥浏览器插件?

南京移动 默认 dns

常用的 cf 选 ip 工具网站 http://ip.flares.cloud

就在前两天被重定向到 江苏反诈公益宣传 http://www.js96110.com.cn/

刚刚测试，移动 4g 也重定向了，坐标南京

@DGideas 半小时确实够放弃这个服务了，又不是因为啥重大的意外事件，断光缆啥的，也不是没有替代服务

@julyclyde 根据我个人非常浅薄的经验，没有遇到证书的问题。我在外网有个服务器，使用 cloudflare 反代，内网将域名指向一台 linux 设备，并在 linux 上使用 haproxy 转发。
PC-->局域网 haproxy-->cloudflare-->服务器

对于 let'encrpt 证书可能会出现问题，因为确实 ip 和地址不一致，但我认为可能出问题的是在签发阶段，ip 和域名不匹配，这个很容易理解。而签发完成后，证书是否能够用在别的服务器上，这点我就不清楚了。毕竟证书只关乎公私钥，ip 是否严格限制就不知道了。而 cloudflare 证书实测可行。

但我理解 haproxy 只是转发 tcp,证书还是从服务器获得的，对于局域网来说依然是原始 ip 和证书，出问题的可能性不大。

我内网没有类似群晖已经签发 https 证书的设备，暂时无法测试可行性。

@julyclyde 楼主的群晖默认访问端口是 5000( http)、5001( https)，这是群晖出厂的默认配置，应该是内置的证书。haproxy 的 tcp 模式可以直接使用目标服务器的 ssl 证书，本地不需要特别的配置，这也是我推荐 haproxy 最主要的原因。
@no1xsyzy 手工配置还是挺香的，我倒又产生个想法，如果经常电脑访问，透明的方式比较好，app 访问多的话，完全可以装两个功能类似的 app 做隔离。

#31 群晖修改端口 serverfault.com/questions/592254/how-to-configure-synology-to-use-only-standard-http-ports-80-and-443-instead-of

@tankren @piku 确实非常接近典型的 nat 回流问题，也启发了我。区别在于楼主的情况还是有不一样的，他没有公网 ip，防火墙 /路由器默认的的 nat 回流设置需要替换外网 ip 地址，需要设备支持命令行及 iptables

在路由器有公网 ip 的情况下，可以充分利用设备特性，此时不需要添加任何设备，不需要任何命令，全图形化操作。

tp-link 企业级路由器示例：问题描述及解决方法 https://blog.csdn.net/x55x5/article/details/86146915

不过 nat 回流只解决了 ip 的问题，没解决端口。不过咱可以修改内网端口，内网改成 12345 就好 https://serverfault.com/questions/592254/how-to-configure-synology-to-use-only-standard-http-ports-80-and-443-instead-of

路由器没有公网 ip 的情况下，我建议路由器自定义 hosts，同时修改群晖端口为 12345 。
这个方案应该是最精简的了。不需要添加任何设备，不需要任何命令行操作，避免了设备限制（自定义 hosts--路由器大概率支持，修改端口--群晖大概率支持）。

最终结论：路由器自定义 hosts，同时修改群晖端口为 12345

@tankren @piku 这个解释也是靠谱的

@tankren #52 没有公网不影响吧。公网访问楼主已经自己实现了，你看原文。内外网原理是一样的，细微差别而已。
1.公网是公开的 dns 解析，内网是路由器自定义 hosts 实现，两者都实现了域名到 ip 的转换。
2.端口部分，我猜楼主用的是 frps：内网有个客户端，主动连接外网服务端保活，服务端转发到客户端实现对内网的访问。frps 和 haproxy 不深入探究原理的话，在这个例子里最根本的区别在于 frps 是反弹式的。

具体实现是否有问题还是看楼主操作后再看看。

有一个情况我觉得建导航的方式也是非常不错的，甚至部管端口，不一样就不一样。别在在手机上访问时没关流量，看电影把房子送给移动了。内外网有显著差异还是不错的，能提醒自己切换网络。

@tankren 我的方案优点在于用户对修改无感知，低门槛。建导航的方法也是极好的，对习惯用浏览器的用户比较友好，但是对客户端要求比较高。
我为何研究这个方案，因为之前我有加速下载的需求，奈何 http 不能很好的利用我宽带的多拨叠加带宽，而 http 下载工具支持镜像功能的很少，还需要大量的手工操作，忒麻烦，才催生出这套方案。
靠手工配置确实可以解决问题，但是都太麻烦了，还是中心化的解决方案比较方便，一劳永逸。
另外我的方案和导航式的并不矛盾，可以很多好的融合

另外说一句，你画的 ppt 还怪好看的

#17 有误，应为 路由器配置：192.168.1.10 nas.example.com

我有类似的经验，前两天刚刚搞定。家里的 n2n 今早挂了，无法连上去看配置，我回忆下配置。
需要的设备：能自定义 hosts 的路由器一台，linux 设备一台或 linux 虚拟机，nas 如果能安装 haproxy 也行。

路由器配置：192.168.1.10

linux 设备：安装 haproxy，frontend 中 bind 端口 12345 。backend 中 server 指向 192.168.1.10:5001

原理：访问 nas.example.com:12345 时，路由器解析到 linux 设备的 ip，而该 ip:12345，则是反代的 192.168.1.10:5001 。

优势：无需改其他设备的配置，比如端口之类的。上面几个回答都解决了 ip 的问题，但是没解决端口的转换。

@Symo #44 目前还在活跃开发中 https://github.com/ntop/n2n 。
我记得在 nebula 的帖子里，有评价 zerotier 的，说是一点中心化让配置更简单。确实如此，我尝试过 wireguard 、tinc，zerotier 。前两者需要在节点之间增删其他节点信息，还是太麻烦了。zerotier 没成功，n2n 则非常简单，还有人开发了启动器 https://bugxia.com/357.html，配置超级简单。至于 p2p 成功率我实测南京电信连接南京移动，成功率还是比较高的，不能直连时可以尝试重启本地 n2n 客户端。直连能达到 50m，不过没达到我本地移动上传上限和电信下载上限，不过已经满意了，就没兴趣继续追究

n2n 不错，架设炒鸡简单，没有自己的公网 ip 或者 vps 的话，也可以使用一些公开的服务器。tinc 和 wireguard 之类的配置还是太麻烦了
n2n 还能 p2p，我南京电信和南京移动直连的话能达到 50m （移动上传带宽大，一般在外连接到家里移动内网）