@minsheng GB 跑分误差还是有点大，再加上目前三者跑分数量有点少，不能反应普遍的性能差异。
不过我看了下，分别去掉最高分与最低分然后平均一下：
Air 剩下 7 个记录，单核 1707，多核 7273
Pro 剩下 10 个记录，单核 1720，多核 7400
Mini 剩下 3 个记录，单核 1739，多核 7639
当然这么算也不严谨，等之后出现大量记录之后才好做普遍分析。

国内不是因为 ocsp.int-x3.letsencrypt.org 经常被污染出过不少 OCSP 相关的幺蛾子么，我以为都习以为常了 😂

我来提供个比较特别的例子：拿 iPad 玩音游……😂
特别是一众音游都支持 120fps，当初我就是为了 arcaea 换的 2018 iPad Pro

突破双星全靠 iPadPro （

图标间隔大点好，要保持社交距离

@coolkid1900
@backlin
@lc125581200
通过这几个回复对比，有的明显有的不明显，那么我感觉屏幕本身可能是有问题。

另外可以测试下把油管那个视频下载下来用本地播放器比如 nplayer 播放看看是不是 HDR/SDR 下有类似现象，可以检验是不是 app 问题。

之前是 iOS geekbench 打 macOS geekbench，这次跑分都是 macOS geekbench，还是能说明点问题的。

本质就是要实现 ip snat，win server 下确实不知道怎么做，我也是在 win 下装 linux 虚拟机借用 iptables masquerade

@dzyou2007 我这里解析到上海的结果访问不了，主要是以前 114 在我这一直是解析到北京那些服务器。

@brMu 很奇怪，之前我这里本地 isp 、114 、alidns 那些解析 google china 的服务器都能正确解析到北京，要不是今天逛到这个贴我还没发现。

我这走 114 、alidns 、本地 isp 给解析到上海电信了
Server: 114.114.114.114
Address: 114.114.114.114#53

Non-authoritative answer:
Name: translate.google.cn
Address: 180.163.150.162


走 dnspod 倒可以解析到北京谷歌云
Server: 119.29.29.29
Address: 119.29.29.29#53

Non-authoritative answer:
Name: translate.google.cn
Address: 203.208.50.66

电信

...
6 202.97.94.98 (202.97.94.98) 30.668 ms
202.97.94.102 (202.97.94.102) 28.196 ms
202.97.12.37 (202.97.12.37) 36.767 ms
7 202.97.86.138 (202.97.86.138) 192.349 ms
202.97.72.102 (202.97.72.102) 186.892 ms
202.97.18.170 (202.97.18.170) 196.807 ms
8 202.97.90.114 (202.97.90.114) 195.668 ms 201.838 ms 199.931 ms
9 218.30.54.214 (218.30.54.214) 195.040 ms 195.082 ms 195.142 ms
10 one.one.one.one (1.1.1.1) 176.330 ms 181.148 ms 180.522 ms

分流特定需求才会走 1111 解析，毕竟横跨太平洋，全部解析交给 1111 太影响体验了。

说个题外话，其实我比较好奇已经采用 listen 443 ssl;方式监听了。为什么不把 http/https 写到同一个 server 中（如果 server_name 相同，要提供的内容又是一样的话）
server {
listen 80;
listen 443 ssl;
...
}

alidns 似乎支持了，而且速度不错
```
; <<>> DiG 9.10.6 <<>> type65 v2ex.com @223.5.5.5
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35953
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;v2ex.com. IN TYPE65

;; ANSWER SECTION:
v2ex.com. 298 IN TYPE65 \# 96 000100000100150568332D32390568332D32380568332D3237026832 0004000C681409DA68140ADAAC4303BC000600302606470000100000 00000000681409DA26064700001000000000000068140ADA26064700 0010000000000000AC4303BC

;; Query time: 10 msec
;; SERVER: 223.5.5.5#53(223.5.5.5)
;; WHEN: Mon Oct 12 14:20:49 CST 2020
;; MSG SIZE rcvd: 134
```

dnspod 有响应，但 answer 空白。
114 我这里偶尔有比较快速的响应，但是大多数时间 timeout，很奇怪……

@de1ta
我这里不是联通，不能给确定答案，不过看这个描述可能是光猫防火墙的锅。
提供个方向，光猫防火墙实在关不了的话先临时改桥接用路由器拨号，先控制变量判断是不是光猫防火墙的问题。
如果确定是光猫防火墙的锅又关不掉的话那就没办法了，换个思路试试 zerotier 。

@hello365
nas 和光猫之间有额外的路由器吗？路由系统默认通常都是把 IPv6 forward 屏蔽的，只允许 ICMPv6，像 openwrt 需要手动把 forward 改成 accept，或者在 rules 里手动添加特定 port/dest ip 的 IPv6 forward 规则。

我这里比较神奇的是走 ntt 的那条线的一个 IPv4 复活了，印象中被墙了有一两年了吧。
不过这里到东京 200 左右……身处腹地没什么办法，从这到广州出口 40 。

期间 IPv6 一直是通的，不过这条线 IPv6 太绕了，绕地球一圈。

我这里电信也是一样的，且不可叠加，同时测 v4v6 抢带宽，整体速度卡死 560Mbps 。
ps：顺便吐槽下这里 500Mbps 带宽上行才 30……
[]( https://s1.ax1x.com/2020/09/08/wMyzdK.jpg)