Nothing is meant to be.|
Service Worker到底是个啥东西，具体能做什么呢？
不说那些佶屈聱牙晦涩难懂的标准回答，不懂看了还是不懂。
简单说下我的看法。
它更像一个中间层middleware，可以读取注册路径下的http请求，然后根据这些请求构造回复。
那么怎么回复的呢？
https://a.com/xxx/https://www.google.com不当人的生物越来越多了。
始作俑者，其无后乎。
很多事情退一步越想越气啊啊啊啊，，，
前文通过itdog的TCP ping的方式简陋地比较了一下接入速度，现在用http ping的方式再测一遍。
测试时间在北京时间2025-07-20 13:25左右。
先讲一下心路历程。
为什么是主域名来使用腾讯的EdgeOne服务？
本来打算edge.nicelee.top使用腾讯服务作博客的镜像站的，也确实是这么做的。奈何完成后才发现Github Pages有些页面301跳转会直接到主站。
在腾讯这边研究了半天，好像没什么方法将返回的location字段的host替换（这点不如Fastly）。
没奈何只能主域名了。原先的Serv00迁移到ser.nicelee.top。
为什么使用上传的证书，而不是系统自动申请免费证书？
腾讯云会验证CNAME，而托管到Cloudflare的域名会自动拉平，验证始终通不过，也就没法自动申请了。
错误提示：当前为白名单功能，非白名单用户无法使用该功能，请联系SSL证书特殊处理
这个使用的是API 更新证书内容（证书ID不变）并更新关联的云资源。
根据工单，这个接口UploadUpdateCertificateInstance目前只能更新CLB资源，建议使用接口UpdateCertificateInstance去更新证书。
详情可参考一键更新新旧证书资源。
新生成的证书每次证书ID都在变化，那么该如何获取呢？
通过查询近三个月内的获取证书操作日志，找到最新的uploadFromYunAPI操作，就能找到CertId。
如果有多个证书，你可以为每个证书分配不同权限，匹配SubAccountUin即可。
举例如下：
json_output='
{
"Response": {
"AllTotal": 3,
"TotalCount": 3,
"OperateLogs": [
{
"Action": "用户[uin: 10001] 上传 证书[id: foo1]",
"CreatedOn": "2025-07-12 18:18:18",
"Uin": "10001",
"SubAccountUin": "10001",
"CertId": "foo1",
"Type": "uploadFromYunAPI"
},
{
"Action": "用户[uin: 10001] 证书[id: foo0]",
"CreatedOn": "2025-07-12 18:18:18",
"Uin": "10001",
"SubAccountUin": "10001",
"CertId": "foo0",
"Type": "ignoreExpiringNotice-1"
},
{
"Action": "用户[uin: 10001] 上传 证书[id: foo0]",
"CreatedOn": "2025-07-12 16:16:16",
"Uin": "10001",
"SubAccountUin": "10001",
"CertId": "foo0",
"Type": "uploadFromYunAPI"
}
],
"RequestId": "xxx-xxx-xxx-xxx"
}
}'
latest_cert_id=$(echo "$json_output" | \
jq -r '.Response.OperateLogs |
map(select(.Type == "uploadFromYunAPI")) |
sort_by(.CreatedOn) |
last |
.CertId'
)
闲得蛋疼搞了很多镜像，通过itdog的TCP ping的方式简陋的比较了一下接入速度。
测试时间在2025-07-12 21:20左右，应该算是接近晚高峰了吧？另外ItDog保存的图接近9M且比较长，不好展示，干脆截个图意思意思就算了。
理论上比较有说服力的应该是多次HTTP ping取平均，没这条件只能将就一下。
Location Guard应该说是较为常见的插件，一种经典的应用场景是Google搜索然后上报位置拯救宋仲基。
当我有很多隶属于不同位置的小鸡，更改位置时的一般做法是：通过关键词搜索确定大概位置，然后调整具体定位。
但是的话，由于搜索api的Key是所有人共享的，有时候会遇到次数限制，这时候就只能凭感觉盲点了，非常麻烦。
本文记录一种更方便的方法。
插件Firefox Multi-Account Containers很好用，但是也没有想象的那么好用。
本文是Putty 免密自动登录设置这篇文章的补充。
附加需求有两个，即使用指定密钥登录而不是密码登录，以及设置代理。