南京移动 默认 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 （移动上传带宽大，一般在外连接到家里移动内网）

@lostberryzz 关闭云朵是可以使用 cf 的 cdn 的，是从别处看来的，而且实际测试确实可行，看起来是个 bug，但目前来说是 feature，什么时候更改就无法预知了。我移动宽带从高峰期几乎不能用 v2，到现在差不多有 50Mb 的速度，已经非常满意了。

@lostberryzz 反馈下测试结果
关闭云朵，关闭 cf 的强制 https，关闭 caddy 自动 80 重定向到 cf，ssl 设置为灵活，无法访问网站，出现 cf 错误页面，显示 cf 到服务器错误，web server is down
关闭云朵，关闭 cf 的强制 https，关闭 caddy 自动 80 重定向到 cf，ssl 设置为严格，可以访问网站，且本地 hosts 指定 ip 也可以