这个检查实测并不是所有域名检测到指向家宽 IP 都会给指向 127.0.0.1 ，正规能备案的域名解析过去是没问题的。 一般的动态域名会有问题。

山东联通还会阻断家宽的域名解析，测试发现是要域名解析到的地址是家宽的 IP ，就会给污染到一个不存在的 IP 地址，导致连接不上。

#10 的方案是好使的，上面这个域名解析的限制目前看主要拦截的就是 HTTP 的访问，有 HTTP 访问会触发，之后无论是用 4G 还是宽带，nslookup 都解析失败。

这个域名解析限制看起来不出省，甚至是不出地级市：）。

想有效的解决这个 DNS 解析的限制，目前看对于能够在国内备案的域名，或者是白名单的域名能够解析。 比如在阿里云买的 org 后缀的域名可以，群辉的 com 后缀的 DDNS 也可以。

@flyingpigpig 我也是从手写 config 转到 subconverter 的，迭代 N 次之后实在觉得麻烦，而且我同时有 Surge 和 Clash 的需求，iOS 、Android 、Mac 、Windows 四种终端，还同时用了几个不同的机场。

后来发现华硕路由器的插件 MerlinClash 里带了个 subconverter ，好奇是做什么用的，一研究发现果然早就有人遇到同样的问题了，这都有了成熟的解决方案了，立马学习一下切换过去。 然后清净了，最近一年就只增加了 ChatGPT 的规则，基本 0 成本了。

@flyingpigpig 那必须得是能动态的，机场的订阅更新了，你从 subconverter 的订阅同步更新。当你同时有多个机场，还有自建的 ss/v2ray 的时候，当你需要自定义 surge/clash 规则的时候，用 subconverter 就体现出优势了。

搭建好之后，是一个 web server ，生成好一个的 url 之后，就和使用机场订阅一样的。 其实很多机场的订阅看 url 风格就是用 subconverter 实现的。

你需要修改的只是 subconverter 里的 config 模板，然后自建的 ss/v2ray 等 server （可以若干个）、机场的订阅（可以若干个）都在 url 中体现。

Surge 、Clash 、V2Ray 等客户端软件只需订阅自建的 subconverter 就可以了。具体看 subconverter 项目的文档，有中文文档，初次上手略有门槛，但是一次投入，几乎终生受益，非常超值。

家用路由器的交换部分，能力有限，大部分都没法做到所有端口线速转发。可以考虑加个交换机，TP-Link 的傻瓜交换机都能达到所有端口线速转发的。

OP 不考虑一下 subconverter 么，直接解决各种类型客户端的订阅问题了。
我跟楼主一样有用 surge/clash 访问家里服务器的需求，后来直接配置 subconverter ，自己搞好模板之后，就一次性解决了。

iOS 、Android 、Mac 、Windows 所有端都可以用了，而且无缝对接各种机场订阅，无视机场的规则，完全用自己的规则了。

@WindProtect 握个手，同样 8 年 mac 换回 win 了，真香！ 告别天价的内存和 SSD 了！

如果是华硕路由器就比较方便，改了桥接之后，华硕路由器做 PPPoE 拨号的情况下，在 WiFi 下一样可以访问光猫的 IP 地址，这个地址在华硕的管理界面能看到。
其他家路由器不清楚，至少小米的是没看到能找到光猫 IP 地址的界面。

OP 直接理解为本地发包的时候就是从路由表里进行规则匹配就对了，匹配到哪一条路由规则，就按照规则发包，规则里指定了发到哪个网卡设备，metric 信息等等。

比如说本地有 eth1 ，还有个 docker0 ，如果目的 IP 是 192.17.0.2 ，那么会匹配到 192.17.0.0/16 这个规则，会发送到 docker0 这个网卡上，这里就直接是以太网过去了。

如果目的 IP 是 1.1.1.1 ，那么最终会匹配到 default 规则，default 有 2 条，metric 较小的优先级更高，所以会把 IP 包发给 192.20.8.88 这个 IP 地址，走 eth1 网卡。192.20.8.88 是否具备 ip forward 的能力是它的问题，它会把这个包转发给谁又是根据它自己的路由表来确定的。

整个网络的交互就是这样的，一个 IP 报文就是一个节点一个节点这么转发的，每个节点都根据自己本机配置的路由表进行转发给下一个目的。 对端 IP 回包的时候，也是一样的流程。

实际上的网络比这个过程要多很多细节，有各种路由交换协议来解决路由传播的问题； 在小的网络里面也有 VLAN 、VXLAN ，各种 GRE 隧道之类的。即使是在本机，路由表也不一定是上面展示的这么简单，还要看策略路由是否有配置，iptables 是否有规则表会在发包和收包的过程中做数据的转换，是 prerouting 还是 postrouting 对包的流向影响也不同。

要想有一个比较全面的理解，可能还是需要稍微系统性的了解一下计算机网络的知识才能有更深入全面的认识。
希望可以帮到 OP 。

找了个现在用的服务器上的路由信息
ip route 的输出如下：
default via 192.20.8.88 dev eth1 proto static metric 10
default via 192.20.1.1 dev eth1 proto static metric 100
192.17.0.0/16 dev docker0 proto kernel scope link src 192.17.0.1
192.20.0.0/17 dev eth1 proto kernel scope link src 192.20.31.12 metric 100

OP 可以考虑一下 XR 或者 SE2/3 ，单层主板散热好很有优势，尤其是夏天温度本来就偏高的时候更明显一些。
另外 A12 之前的处理器 Carplay 性能会有些瓶颈，够用，但是并不宽裕。Carplay 本质上也算是屏幕录像转码推流了，对性能有一定要求。

同 2019 MBP 16 ，i9-9980HK+64G+2T+5500M 8G 的配置。 改装 VRM 散热前后完全是 2 台机器，改装之后，make -j16 编译 C++项目，全核跑满可以稳定在 3.0GHz 以上，功耗能稳定在 90W 附近。

跟楼主一样，16 ～ 19 年的 MBP 续航都不太行，毕竟电池容量不给力，对于程序员来说 Touch Bar 不太好用，平时都是外接机械键盘 or Magic Keyboard ，所以倒也无所谓。

有朋友入了 M2 Max 16 寸，选配到 96GB 了，对比了一下感觉确实有不少质的提升：
1 、温度低得有点不真实了，现在这个气温，我的机器外接一个显示器，53 度左右，M2 Max 同样工作负载温度 28 度；
2 、内置屏幕有 ProMotion ，确实观感好很多啊，当然日常不怎么用内置屏幕也还好；
3 、F1 ～ F12 终于有实体键了，好评！
4 、能运行 iOS App
5 、MagSafe 回来了，而且充电能有 140W ，我的老本只有 90W 。

但是 3W 多的价格，加上这代 M2 感觉挤牙膏，所以个人选择是能等就等等。

日常开发全靠服务器，Macbook Pro 也就是个 Terminal ，家里还有台式机，很多需求直接远程到台式机搞了，需要在 Macbook Pro 上处理高负载的场景都有意通过各种办法都转移到服务器和台式机上了。

OP 的日常环境如果联网方便的话，我是觉得可以考虑一下把 HomeLab 搞起来，哪怕随便搞个台式机，性能体验都不是笔记本能比的，而且 x86 的兼容性还是好得多。 台式机 + Windows 本 + Macbook 各有各的用途，都靠笔记本干活有点太难为它了。 用 Surge 、Clash 或者 WireGuard 之类的，透明地实现与 HomeLab 的网络三层 or 二层的打通，这样只要有网络，就能干活了。

续航问题就带充电器，or 充电宝吧。 搞个 iPad Pro 作为补充也是一种选择，不少负载都可以用 iPad 完成的。

希望对 OP 有参考价值。

@mgrddsj 刚刚实测 Android 在“数据传输”模式下，用原装数据线连接 Windows 电脑，在文件资源管理器里传输一个 4.97 GB 的视频文件，耗时 2 分 1 秒，平均大概 328 Mbps 。

这个速度看起来就是 USB 2.0 的速度吧，2.0 最大速度是 480Mbps ，大概 60MB/s 。

@mgrddsj 刚刚实测 Android 在“数据传输”模式下，用原装数据线连接 Windows 电脑，在文件资源管理器里传输一个 4.97 GB 的视频文件，耗时 2 分 1 秒，平均大概 328 Mbps 。

同时用 vim 、CLion 、vscode 开发 C++用了挺长一段时间，分享一下自己的经验。
vim：用起来最顺手的，会有一点学习曲线陡峭的问题。vim 相对来说是投入产出比最高的了，一次学习，终生受益。VIM 对各种 C++项目的适应性是最好的，使用 YouCompleteMe 配合 clangd ，无论是 cmake 项目还是 makefile 项目，统统生成 compile_commands.json 之后就可以无缝衔接了。 同时配合上 gtags-cscope 之后，基本的 Find References 也比较丝滑了。 至于 easymotion 、multicursor 都是 vim 上必备的了。可以看看 skywind3000 讲解如何使用 vim 搭建 C++开发环境的，他应该主要是 Windows 环境比较多，在 Mac 上也类似的，但要讲兼容性，还是整个 ubuntu 的 vm 比较容易一些。

vscode：clangd + microsoft cpp ，这个具体可以看 clangd 官方网站的介绍的 best pracitce( https://clangd.llvm.org/installation)，里面对于主流的编辑器如何配置都有详细介绍。 vscode 安装 vim 插件之后，自带了 easymotion 等一些比较好用的 vim 插件，相对来说比 JetBrains 家的 IdeaVim 要更加全面一些，但是实际用起来似乎没有 IdeaVim 那么稳定。vscode 的好处是可定制性非常强，和 vim 一样对于 cmake 和 makefile 项目都能比较好的支持，代码提示、静态代码检查这些基于 clangd 干的事也都能干得好。 通过精心配置之后，vscode 也可以做到几乎完全用键盘操作了。 如果用普通鼠标的话，vscode 的滚动比例需要调整一下，不然在 mac 下鼠标滚动非常神经质，用 trackpad 和 magic mouse 的话是感觉不到这个滚动问题的。
vscode 的最大优势个人认为是 remote 模式确实做得非常棒，比 Clion 要好很多很多很多。。。。。， 但是 vscode 时不时会有一些小问题，比如撤销编辑这个操作，cmd+z 和 vim 里的 u ，感觉有冲突，总是不小心就撤销错了。

clion： 它其实也是基于 clangd 来搞的，相对来说更加开箱即用得多，几乎是 0 配置就可用了，代码编辑这个功能本身做的个人认为比 vscode 要流畅丝滑很多，插件的成熟度比 vscode 高一些，但是数量少很多，容易有一些功能就不好实现。但是也有一些比如 multi-highlight 这种好用的插件，vscode 没有对应的。clion 的代码索引做得会比较好用一些，跟 idea 那个体验有一拼了，如果项目是完全用 cmake 管理，没有 extenral_project 的话，那么 clion 的体验是非常棒的。
clion 的缺点很明显也很要命，首先是 remote development 用起来一言难尽，与 vscode 的 remote 相比简直连 beta 都算不上，即使把服务器上 clion 的内存堆大小开到 12G 以上，也没什么实质的提升，稍微大一点的项目，动不动就索引失效了，然后卡半天建索引，体验真的一言难尽。
clion 的另一个缺点就是只能对 cmake 管理的项目有比较好的体验，一旦这个项目混合了 cmake 和 makefile ，或者 cmake 里面有 external_project ，那代码索引的能力就非常捉急了。
忍了很久 clion 的这些问题，最后放弃使用了。 有些 C++项目在 Mac 上比较难搞，所以 remote 是刚需。


总体来说，vim 有一定的学习曲线，需要投入一些时间，效率提升地反馈没有那么快。但是还是建议一定要学习和使用 vim ，因为即使 vscode 、clion 这些都在安装 vim 插件之后才有更高的效率。 另外配置 vim 插件的过程中，你能够对 c++开发过程中的很多细节有更好的理解，比如 clangd 的代码提示怎么才能生成，clang-tidy 是怎么回事，clang-format 又是怎么回事，分别是怎么配置的，vim 和 git 怎么集成的，git 内部的数据结构大概是什么样的，等等。
这样在使用 vscode 、clion 的时候，对于很多问题就会有更加透彻的理解，而不是完全只能当成一个黑盒使用。

最后，现在主力使用的是 vscode （ 70%时间），辅助使用 vim （ 25%时间），很少使用 clion （ 5%时间）。vscode 上同时使用 clangd 、clang-format （为了格式化 proto ，clangd 自身好像没法 format proto 文件）、microsoft cpp 、vim 等等插件，平时主要是用 vscode 的 remote 模式，代码和环境都放服务器上，ubuntu 、centos 、rocky 都有，虚拟机、物理机、Docker Container 都有，总体来说体验是比较好的。
vim 效率跟 vscode 差不多，由于 vscode 偶尔有些小毛病，vim 甚至可能还要效率更高，但是 vim 的主要问题是 YouCompeteMe 这个插件在一些老的系统上编译起来比较麻烦，每个机器都去配置环境也是个挺浪费时间的事，vscode 就省心很多，自动安装就行了。

啰啰嗦嗦说了很多，希望对 OP 能有帮助：）