打开旁路由 RA ，宣告一个 ipv6 内网网段，把 ipv4 和 ipv6 dns 全部指向旁路由内网网段，梯子上丢弃代理域名的 ipv6 解析就可以了，主路由公网地址 RA ，旁路由内网地址 RA ，本身内网地址不具有连通性设备默认不会走内网地址，解决了分流问题，pcdn 依然走主路由，pcdn 机器再手动指定一下 ipv4 的网关就可以了

源站->CloudFront->用户 1TB 免费
源站<-CloudFront<-用户 收费
通过 CloudFront 从源站下载免费，上传收费

机场这东西送客户流量出国不是什么难事，怎么能保证以极低的成本保证最高的服务质量？你怎么能保证你的上游不会出问题把你一起卖了？支付渠道这东西是会一起连坐的，上游完蛋你也要一起完蛋，很多机场是支付渠道挂了就不得已关停，这活不仅要技术还要人脉关系，而且技术不行的是第一批完蛋的，抓胆子大的人是最轻松的，因为他们会赌不会抓到自己，或者你可以试试出来之后给大伙分享以下经验哈哈。

这玩意看 ping 没用，还要看你直连带宽有多少，哪个运营商，丢不丢包，而且 google cloud 亚太地区动不动就给你干到路由全球旅游，azure 和 aws 在我这 ipv4 都能做到 40ms 以下，新加坡 ipv4 和 ipv6 延迟都还可以，贴段 ping 和路由吧，重复跳空跳删掉了。
ping 13.33.174.54 #AWS
PING 13.33.174.54 (13.33.174.54) 56(84) bytes of data.
64 bytes from 13.33.174.54: icmp_seq=1 ttl=242 time=36.1 ms
64 bytes from 13.33.174.54: icmp_seq=2 ttl=242 time=36.0 ms
64 bytes from 13.33.174.54: icmp_seq=3 ttl=242 time=35.8 ms
64 bytes from 13.33.174.54: icmp_seq=4 ttl=242 time=36.1 ms
64 bytes from 13.33.174.54: icmp_seq=5 ttl=242 time=35.7 ms
64 bytes from 13.33.174.54: icmp_seq=6 ttl=242 time=35.7 ms
64 bytes from 13.33.174.54: icmp_seq=7 ttl=242 time=36.0 ms
^C
--- 13.33.174.54 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6009ms
rtt min/avg/max/mdev = 35.683/35.921/36.136/0.162 ms
josin@debian-he:~$ ping 52.140.232.160 #Azure
PING 52.140.232.160 (52.140.232.160) 56(84) bytes of data.
64 bytes from 52.140.232.160: icmp_seq=1 ttl=113 time=34.7 ms
64 bytes from 52.140.232.160: icmp_seq=2 ttl=113 time=35.5 ms
64 bytes from 52.140.232.160: icmp_seq=3 ttl=113 time=34.4 ms
64 bytes from 52.140.232.160: icmp_seq=4 ttl=113 time=35.7 ms
64 bytes from 52.140.232.160: icmp_seq=5 ttl=113 time=34.6 ms
64 bytes from 52.140.232.160: icmp_seq=6 ttl=113 time=36.0 ms
64 bytes from 52.140.232.160: icmp_seq=7 ttl=113 time=34.5 ms
64 bytes from 52.140.232.160: icmp_seq=8 ttl=113 time=34.5 ms
^C
--- 52.140.232.160 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7011ms
rtt min/avg/max/mdev = 34.411/35.004/36.023/0.604 ms

10.10.0.1 0.53 ms * 局域网
180.110.144.1 19.16 ms AS4134 中国, 江苏, 南京, chinatelecom.com.cn, 电信
218.2.126.253 1.98 ms AS4134 中国, 江苏, 南京, chinatelecom.com.cn, 电信
218.2.125.77 5.83 ms AS4134 中国, 江苏, 南京, chinatelecom.com.cn, 电信
202.97.85.49 13.37 ms AS4134 中国, 上海, chinatelecom.com.cn, 电信
202.97.41.134 33.69 ms AS4134 日本, 东京都, 东京, chinatelecom.com.cn, 电信
203.215.236.98 34.74 ms AS4134 日本, 东京都, 东京, chinatelecom.com.cn, 电信
ae30-0.icr02.tyo31.ntwk.msn.net (104.44.235.188) 33.81 ms AS8075 日本, 东京都, 东京, microsoft.com
52.140.232.160 34.42 ms AS8075 日本, 东京都, 东京, microsoft.com

10.10.0.1 0.23 ms * 局域网
180.110.144.1 136.57 ms AS4134 中国, 江苏, 南京, chinatelecom.com.cn, 电信
61.155.254.217 2.88 ms AS4134 中国, 江苏, 南京, chinatelecom.com.cn, 电信
61.155.254.217 1.75 ms AS4134 中国, 江苏, 南京, chinatelecom.com.cn, 电信
61.155.254.217 1.45 ms AS4134 中国, 江苏, 南京, chinatelecom.com.cn, 电信
218.2.127.49 1.71 ms AS4134 中国, 江苏, 南京, chinatelecom.com.cn, 电信
202.97.83.33 11.85 ms AS4134 中国, 上海, chinatelecom.com.cn, 电信
203.215.236.38 35.77 ms AS4134 日本, 东京都, 东京, chinatelecom.com.cn, 电信
52.93.66.74 60.61 ms * 日本, 东京都, 东京, amazon.com
52.93.66.197 34.79 ms * 日本, 东京都, 东京, amazon.com
13.33.174.54 36.14 ms AS16509 日本, 东京都, 东京, amazon.com

@qsmd42 我也是这个问题不管是 b 站还是 youtube 甚至 chrome 看视频也会卡，同个问题出现在 pe 和 Lineageos ，最后是刷了 miui 最新版本，再刷回 Lineageos 解决的，非常玄学

在南京呆了 8 年了，好吃的一般是贴着小区的或者干脆就是开在小区里面的，不过这几年没了很多，哎，也可能是我也没怎么仔细研究过吃哈哈，记住不要去老门东，夫子庙就行了。

早上遇到了，se2 备用机放口袋，口袋不咋方便就又塞包里了，不知道怎么就划开相机，录了三个小时没电关机了，差点没蚌住，这种情况也遇到好几次了。
https://i.imgur.com/Q183AnO.jpg
https://i.imgur.com/abhGMhQ.jpg

简单粗暴，家里开两个 wireguard 接口，接口 A 与 vps 互联，在 vps 转发 openwrt B 接口的端口，客户端连接 vps 上转发的端口就可以了，客户端路由全部流量到 openwrt ，隧道套隧道，不过我自己的话是单独开一台虚拟机当 wireguard 服务器，openwrt 就当一个纯网关。

我这一台 N6000 的主机跑了 Router OS x86+Ubuntu+Openwrt ，ROS 主+OP 旁，家里的是一台 ZTE 的 Wifi6 路由器(电信送的，性能还可以)直接插到光猫拨号负责家里其他成员的网络，我的网络挂了不影响他们的网络，客厅房间各一台 AP ，n6000 主机拉一条线到 ZTE 路由器上，ROS 写个静态路由，在我的网络下也可以管理 ZTE 路由网段，这样也隔离了网络，我的网络挂了也不影响家人的网络。

@ql562482472 流媒体都要翻

之前看过他 freenas 视频关注的，因为在他视频底下吐槽了 arm 的解码，前年就被这人拉黑了，属于是一点不同的声音都听不得，后面在油管上看了零星几个视频，没意思就把他点了不感兴趣，后来就没怎么在意过了，现在搜了一下还在他黑名单里面，乐

微软出过一个 Microsoft modern keyboard 走蓝牙协议可以 Windows hello 指纹

你这么一说我倒是想起来了，因为一直用 SwitchyOmega 分流每次报错都有这个域名，看了下后台原来 adg 拦截了俩域名 statsigapi.net 和 sentry.io
https://i.imgur.com/Kijo7vg.png
https://i.imgur.com/tYbGL5z.png

@klo424 如果公司内网有审计设备可以在审计设备上设置规则把解析指向内网，或者将客户端 dns 指向内网的一台服务器，在内网 dns 服务器上设置 dns 重写，证书续期用脚本定期续一下就可以了

@klo424

通过 dns 申请域名证书，再把 dns 劫持到内网地址就可以实现 https 了，我就是这么干的。

@azure2023us559 仗着带宽大硬抗，国内发生 ddos 是运营商黑洞的，不然一个节点负载过大直接瘫痪还会影响自家业务，云提供商只是负责通知你，这东西不是作不作为的问题，是你压根没法控制，清洗流量的前提是你有大过攻击流量的接入带宽和识别异常流量的能力，这部分只能通过增大与运营商的互联带宽去解决，而且这部分就是收费的，为什么国内的高仿这么贵就是这个原因，运营商源头卡死成本了，国外大部分都是 cloudflare ，带宽成本非常低，随便就是 G 口，扛个几个 T 一点事情没有，你猜为什么 warp 让你白嫖，薅了这么多他依然免费，因为这些成本可以小到忽略不计。