普通视图

发现新文章,点击刷新页面。
昨天以前首页

IGNORE QUERY STRING 以减少源站压力

作者 ROYWANG
2022年10月11日 08:00

之前介绍过,我的博客方案已经更换为全静态,详细可以参考我这篇文章《WordPress “纯”静态化

理论来说,所有静态资源回源一遍之后,后面的请求都会直接从CDN获取资源,并不会进行回源操作,除非我更新了资源,并且手动刷新资源。

但长久以来,还是从源站上看到了许多已经回源过的资源,而绝大多数的特征都在于 ‘?’ 这个符号之后。遂才想起,忘记了做 ignore query string,此篇文章谨当记录一下操作过程。


正文

之前文章介绍过,我是通过 NS 解析时,将请求划分为境内与境外,境内使用了 腾讯云CDN,境外为CloudFlare。所以此文也分为两个步骤分别进行。

Tencent Cloud CDN

未进行 ignore query string 操作时,在网址后面输入 ‘?*’ 时会自动回源。

img

此时,在腾讯云CDN的域名管理之中找到缓存配置,修改全部文件配置

img

修改为下图所示即可:

img

此时即可看到,没有回源,命中了缓存。

img

CloudFlare

未进行 ignore query string 操作时,在网址后面输入 ‘?*’ 时会自动回源。

img

在页面规则中,新增以下配置:

1
2
3
4
URL (required) :*youdomain/*?*
Pick a Setting (required):Forwarding URL
Select status code (required):301 - Permanent Redirect
Enter destination URL (required):https://$1youdomain/$2

如下图所示:

img

此时再进行 query string 操作时,CloudFlare便会自动的301跳转到无 query string 操作的页面,以达到ignore query string的效果

img

本方法可能不适用于您的站点,请慎重参考。

WordPress “纯”静态化

作者 ROYWANG
2022年5月24日 08:00

前几天才发表了 WordPress 的 CDN 方案,但是很快就反水了,并不是因为那个方案不够好,而是越写博客越发现,静态博客才是个人博客应有的终极形态。

很多朋友都在劝我抛弃 WordPress 转投 Hexo 的怀抱,不过确实,“纯”静态博客个人才是博客应有的样子。为什么要加一个“纯”呢?就像 WordPress,很多人通过伪静态,把页面后缀改为 html,再使 CDN 强制缓存,达到一个静态的效果。但这样的 伪静态 并非 静态博客 的真正样貌。

为什么不使用 Hexo 或者其他方案,因为仅 Hexo 对我来说是完全陌生的,而且其所使用的技术栈,也是我完全不懂的。相较于使用一些完全不懂的东西,不如去继续把手头正在用的改造的更好,毕竟内容才是博客最主要的。


方案选择

选择 WordPress 的理由

其实对于 WordPress 的理由有很多,无论是一些非常好用的插件,还是 Gutenberg,还是整个操作逻辑,对于软件使用的熟练使用程度,其所使用语言对目前我来说一些基本操作都能够实现。都在让我坚持使用 WordPress,以至于更换“纯”静态方案,没有将其替换掉的原因。

为什么要坚持所谓的”纯”静态

传统的 WordPress 加速解决方案都是使用 WP Super cache 之类的插件,生成缓存,然后生成 html 文件,使用 CDN 强制缓存,但这么做的问题是,虽然展示的是静态的,但其还是需要执行 SQL 语句来调用数据的,虽然目前市面上的 0SQL 主题不少,但是大多数还是无法避免这个操作。

而“纯”静态化,直接是 0SQL,无需后端,可以极大的缩少服务器资源的占用。就算你的服务器在海外,只要域名备案,通过国内的 CDN,都可以获取非常可观的速度。

目前方案的问题

目前方案主要拥有下面两个问题:搜索不可用以及评论不可用。

我对于这两个问题的解决直接放弃了。

本身国内的个人备案是不支持交互式网站的,而且垃圾评论实在是太多,以至于我后面开启了 reCAPTCHA,还是不断的有人来打广告。。。。

关于搜索,因为每个文章都拥有相应的 tag,点击一下即可显示相关文章,一部分承担了搜索的功能。

两个问题带来的影响都不算大,索性就不去管了,去专注内容。

更新不及时,需要手动去刷新 CDN 缓存。

Simply Static

插件地址:Simply Static

这是我目前所选择方案所使用到的插件,它最大的好处就是通过缓存可以直接将 WordPress 页面生成静态文件,并且可以将文件中的地址自动替换,直接放到服务器即可。

方案介绍

所需要的要求如下:

  • 需要用到两个域名:
    • console.domain.com //用于 WordPress 动态资源的域名
    • domain.com //用于静态博客域名(博客的主域名)
  • 两个站点都需要位于同一服务器内
  • 其余要求可以打开插件 Simply Static › Diagnostics 查看有哪些地方不符合规则

配置

Simply Static 设置

原理很简单,就是通过 Simply Static 这个插件,直接在 domain.com 也就是你博客的主域名的目录里生成静态文件。

这个插件,需要进行以下设置:

GENERAL

1、Destination URLs

此处的作用是将 WordPress 生成的静态文件中 动态博客地址,转为主博客的地址(静态地址)

img

此处需要选择 Use absolute URLs 然后填写你博客的主域名

2、Delivery Method

此处的作用,是选择把生成的静态文件通过何种方式存储。

img

此处选择:Local Directory

3、Local Directory

设置生成的静态文件存储的目录

img

此处填写 主博客所设置的目录即可。

INCLUDE/EXCLUDE

此处设置一处:Additional URLs

输入内容主要是不包含在静态页面中的链接,但还是需要生成静态文件的链接。

img

此处需要设置 动态博客 的文件链接。

主要是 sitemap、robots.txt

其他设置

其他设置可根据自身需要来进行设置,诸如可以设置:附加文件和目录、要排除的 URL、

临时文件目录、HTTP 基本身份验证(此处强推)

全部设置完毕后,可以在 Diagnostics 处进行检测,当没有错误即可进行手动生成。

生成静态文件

当设置完毕,并且检测没有问题后,在 Generate 中点击 GENERATE STATIC FILES 即可生成文件,根据需要生成的文件大小不同所需时间也不同。

img

CDN 设置

CDN 还是采用通过 DNS 区分国内国外用户,国内用户走腾讯云,国外用户走 CloudFlare。此处与之前的方案没有改变。

因为是是纯静态文件,所以无论国内还是国外的用户都会有非常不错的体验。

此处可以参考 《目前博客的 CDN 解决方案

无论是 腾讯云还是CloudFlare主要:

  • 设置防盗链
  • 开启强制缓存,并设置缓存过期时间
  • 设置浏览器缓存过期时间
  • 开启HTTPS
  • 打开 压缩静态文件

对整个网站做出更改后,可以通过 腾讯云CDN、CloudFlare 两个 WordPress 实现刷新缓存,目前无其他比较好的方法。

折腾来折腾去还是找到了对我还是对用户来说都最好的解决方案,接下来就是专心写文了。

目前博客的 CDN 解决方案

作者 ROYWANG
2022年5月19日 08:00

之前更过一篇 WordPress 配置CDN的文章 《WordPress 配置CDN,免对象存储,加速域名首页自定义》,感觉这个方案太水了,而且后面也遇到了各种各样的问题,然后重新设计了 CDN 方案,整体来说还算是满意,今天分享出来跟大家聊聊,我会详细说一说具体的配置,以及这么做的原因和弊端。


方案导图

话不多说,直接上图

img

通过 DNS 进行境内境外分流

国内用户

动态资源 - 百度云加速

原因

选择百度云减速(bushi 云加速得原因很简单——收录。

绝大多数建站的站长肯定是希望盈利的,但至少是希望尽可能的去抹平每年域名、服务器、CDN的费用。可能是出于兴趣建站,毕竟谁不希望少花点钱呢?为了均衡成本,是需要通过流量来变现,而被搜索引擎收录所带来的流量一直是很可观的,事实上很多站点也是这么做的。

中文互联网内主流的搜索引擎也就是三家:百度、Google、Bing。

Google虽然情况特殊,国内用户无法访问,但是因为对百度、Bing 特供版的不满。很多人将其当作首选的搜索引擎,收录速度虽然很快,但是 关键词排名难做,特殊原因导致中文用户基数少是其主要的问题,所以所获的流量不是很多。

Bing的情况有些特殊,虽然国内可以直接访问,而且没有像百度这样充斥着广告,国内用户虽然也有存量,但由于多年被国内互联网环境培养的用户习惯导致,Bing的用户基数很小,虽然收录很快但是站长能从中获取的流量也并不是很多。

百度,虽然百度充斥着恶臭以及各种各样的问题,但其还是作为中文互联网的搜索引擎的 No.1。由于某些特殊原因,百度的SEO优化甚至演变成为了一门十分值得研究的学问,一个新的网站如果想被百度快速大量的收录,其中所需要的条件多种多样,很多高阶条件是新人站长无法满足的,此处不再详细赘述。对于无法满足的这些条件的站长,百度还是提供了一条明路——百度云加速,这也是我选择它的原因。

缺点

百度云加速的缺点很明显,,名为加速,实则减速。现在的免费版仅仅提供可怜的三个节点(但经过我实测只有两个)它的商业模式采用的套餐制度,如果你想拥有多节点的话,加钱,最便宜的一年四位数的那种。当然不可能花钱的,所以国内的静态资源没有托管到百度,而是使用的 腾讯云的 CDN。

配置

百度云加速的配置极其简单,甚至属于对接上就行的辣种。

打开面板打开 流量功能->引擎加速收录 里的 新站百度报到

img

以及在 同在 流量功能 中的 永久在线

img

在 其他 -> 特定页面规则 中添加规则,如下所示(此处仅以WordPress为例,其他不同程序配置不同,其中规则优先级1>2):

1
2
3
4
5
6
7
规则1
URL: domain/wp-admin/*
规则配置: 缓存粒度设置 -> 不缓存
规则2
URL: domain/*
规则配置1: 缓存粒度设置 -> 细致
规则配置2:浏览器缓存有效期 -> 1天

img规则1

img规则2

至此配置完成。

静态资源 - 腾讯云 CDN

原因

稀里糊涂的选择了腾讯云 CDN,主要是可是白嫖,可能感觉服务器也是腾讯云的可能有特殊加成(?)不太记得了,但是使用了之后的体验还是非常不错的,比我用过的 UPYUN 还有 百度云加速 感觉好。

缺点

目前使用起来没感受到啥明显缺点,但是可能以后会感受到,毕竟不是一直可以白嫖的,未来的缺点就是贵。不对,这是我的缺点

配置

分享一个我使用回源策略,回源 HOST 填写 加速域名,然后在这个域名对应的站点目录中创建 软连接软件,然后将 WordPress 站点目录链接至 CDN 加速域名的站点目录,如下图所示:

img

完成初步配置后(指接入CDN),因为公开的加速服务不理想,所以我直接通过国内的服务器进行了反代,然后设置缓存,然后通过腾讯云CDN缓存起来,网站速度提升了一大截。

img

但由于此服务仅是供自己使用的,所以需要打开防盗链

进入CDN域名管理页面->访问控制,第一个既是防盗链,输入需要访问资源的域名即可。其余配置如下图:

img

进入缓存配置->缓存键规则配置,设置为全部文件,不忽略参数,不忽略大小写

img

缓存配置->节点缓存过期配置,新建规则如下:

1
2
3
类型:文件后缀
内容:jpg;png;js;css;ico;woff2;woff;tff
缓存行为:缓存七天,强制缓存

img

回源配置 -> 回源跟随301/302配置 打开

img

HTTPS配置 -> 强制跳转 打开

img

高级配置 -> HTTP响应头配置 (此项配置是为了防止出现 CORS 错误

1
2
头部参数:Access-Control-Allow-Origin
头部取值:你需要引用静态域名的域名,如图示例。

img

打开 高级配置 -> 智能压缩,如下图所示:

img

至此,CDN配置完毕,但是 WordPress 需要将静态资源地址替换为加速地址

此处以 WPJAM BASIC 插件为例(强推),选择云存储 腾讯云COS,然后输入加速的 CDN 域名。

img

保存即可,此操作可替换绝大多数静态资源链接,也可以通过反代配置自己的 Google字体加速、Gravatar加速。

国外用户

动态+静态资源 - CLOUDFALRE

原因

免费还是很香的,而且提供免费的防御,国外 CloudFlare 的速度还是非常快的。主要还是能白嫖。

缺点

无。。。。。。。可能对国内速度不佳?

配置

CloudFlare 的配置堪称傻瓜式的,也是通过 峰峰 的教导,才正确的打开了 CloudFlare 的配置方式

本站采用的是 CNAME接入,详细的接入教程参考本站文章 《CLOUDFLARE 免费官方 CNAME 接入

目前我的配置方法就是在 规则 -> 页面规则 中添加一条页面规则,具体配置如下:

1
2
3
URL: domain/*
设置1:缓存级别 -> 缓存全部内容
设置2:边缘缓存TTL -> 1个月

为什么不设置 /wp-admin/* 为不缓存。因为免费规则只有三条,超出就要收费,另外在国内不需要访问海外线路的 /wp-admin/

选择 速度 -> 优化 Auto Minify,三个选项全选

img

启用 Brotli

img

至此 CDN 优化方案完成,此方案还是存在很多暂时没有发现的问题,可能会有更好的方案。能力至此,希望各位斧正。

此方案也是目前博客所使用的方案。

CloudFlare 官方免费 CNAME 接入

作者 ROYWANG
2022年5月13日 08:00

CloudFlare 是很多站长在建站时首选的 CDN 服务商,免费、无限带宽,抗DDOS,都是选择它的理由,但由于某些方面原因,使得国内的访问速度堪忧。由于 CloudFlare 的 NS 服务器在国外,所以还需要尽可能的降低延迟,来提升网站体验,所以就有了CNAME 接入这种方式,使用国内的 NS服务器,可以一定程度缓解加载时间过长的问题。

之前可以使用 CloudFlare 提供的合伙人密钥,使用第三方网站进行添加 CNAME 接入,但由于目前 CloudFlare 的防滥用政策日渐缩紧,所以禁止了通过合伙人密钥来进行添加 CNAME 接入。各家第三方的接入平台如 笨牛网 等已经禁止了用户登录。

但目前 CloudFlare 提供了一种官方 CNAME 接入的方式。

CloudFlare for SaaS

之前使用这个功能是收费的,但自 2022/3/15 起,官方开启了免费额度。每个账户拥有目前 100 个CNAME接入的免费额度,而超过 100 的部分也由每月 2美金 每个的价格降低至了每月 0.1美金 每个。

我们所依赖这个功能所提供的免费额度,来实现免费 CNAME接入。


配置 CNAME 接入

在配置之前,您需要准备两个域名以及PayPal账号:

1
2
a.com : 此域名需要通过 NS 的方式接入CloudFlare
b.com : 此域名即为你需要加速的域名。

如何通过 NS 接入,不再详细演示。

开通CloudFlare for SaaS

打开网站配置页面,并且找到 SSL/TLS 下的自定义主机名。

订阅 CloudFlare for SaaS 需要绑定外币信用卡或 PayPal,个人建议绑定PayPal(此过程不会发生扣费)

img

由于之前已经开通过了,所以无法演示,根据页面提示进行操作即可。

设置回源域名

在配置 CNAME 接入之前,需要设置回源所需的域名。

在DNS选项中,设置一个自定义的接入CloudFlare的二级域名(即使用上文中提到的 a.com 设置一个二级域名解析到你的网站IP),解析至需要回源的 IP 或域名,并且打开 CloudFlare 的代理。

img

然后打开 SSL/TLS 下的自定义主机域,在回退源中,填写设置好的域名,并且点添加回退源,等待生效。

img

此时即可增加需要 CNAME 接入的域名

点击添加自定义主机名,输入你需要接入的域名,并且选择最低TLS版本(如不懂,请保持默认)以及证书验证方式即可。点击添加自定义主机名。

img

设置国内 NS 服务商 DNS 解析

提交后,即可看到正在初始化,在第三方的 NS服务商处设置好相应的NS解析,等待检测即可。

img

并且同时,需要将 需要接入的域名 解析到 回源域名 上

img

全部设置完成后即可等待解析生效。

解析生效

img解析生效

img

此种方法需要 PAYPAL 账号,而且好处相比第三方,数据保存在自己的手上。

而且所有关于 CNAME 接入的相关设置与统计数据,均与 通过 NS 接入的域名共享。

WordPress 配置 CDN,免对象存储,加速域名首页自定义

作者 ROYWANG
2022年2月24日 08:00

因为域名不能备案,所以目前来说只能使用海外的服务器。因为腾讯云轻量目前的香港线路时好时坏,正好手里还有个备案域名,而且DNSPOD专业版每月白送50G流量,就有了以下这一系列折腾


方案

在说方案之前先强势安利一波 WPJAM,这个插件集成功能之广,真的前所未见,真心安利。本次的CDN方案也全部基于 WPJAM 与 腾讯云;

这个项目总共就用了两个方案,第一种方案基于腾讯云的COS、CDN服务,也就是 WPJAM 插件里使用腾讯云用CDN进行网站加速作者所给出的方案,详情可以点击链接看一下。

而第二种方案,只使用了腾讯云的CDN加速服务。因为加速的都是一些静态资源,而绝大多数静态资源都是长时间不会去动的,所以回源快慢基本无所谓,只有在回源的时候慢一点。CDN把资源缓存到服务器的之后,除非缓存过期,否则基本不会进行回源操作,故而去掉了腾讯的对象存储服务。这种方案也是本站目前所采用的方案。

直接上图

img

这个方案导图非常简单,但是经过配置拥有以下好处:

  • 回源速度更快
    • 因为如果采用COS服务,回源顺序是 前端 -> CDN -> COS ->源站,而这样少了一道COS,回源速度就会更快一点(手动狗头
  • 省钱(主要原因
    • 没有COS的各种各样的计费,相对来说更加省钱,基本使用效果与COS使用一致
  • 配置简单
    • 相较于传统的CDN加速方案,都是需要对接COS,这样做的好处之一便是不会让博客突然多出一个域名,如果配置不当还会被别人直接拿走整个站点。
  • 不会使博客多出一个域名,打开CDN加速域名显示为设置的单页

配置

很多操作为了方便,此处使用了宝塔面板,配置分为三个部分:宝塔的配置、腾讯云CDN配置、博客配置。

宝塔配置

新建站点

输入域名,以及修改根目录,此处根目录与博客根目录需保持一致

img

此处根目录与博客根目录需保持一致

修改默认文档

这就是打开CDN加速域名,而不是博客的原因。打开首页即是你设置的单页,但静态文件与动态文件则不受影响。

img

默认全部删除,自定义HTML文件文件名

设置SSL

选择Let’s Encrypt 申请即可

img

腾讯云 CDN 配置

添加域名

主要配置如下:

  • 加速域名:准备的备案域名
  • 加速类型:CDN网页小文件
  • 源站配置:
    • 源站类型:自由源
    • 回源协议:协议跟随
    • 回源地址:填写你的服务器IP

img

此处节点缓存过期配置需要全部文件删除,然后自定义一些静态文件后缀,为保证首页正确,所以必须缓存html。其余配置保持默认即可

img

其他配置

提交后需要设置DNS解析。设置完成后,打开管理,需要打开以下配置:

  • 缓存配置->HTTP头部缓存配置

  • 回源配置->打开回源跟随301/302配置

  • HTTPS配置

    • 配置SSL,具体操作不再演示
    • 打开HTTP 2.0配置
    • 打开强制跳转
      • 跳转类型:Http->Https
      • 跳转方式:301跳转
      • 携带头部:否
  • 高级配置->

    HTTP响应头配置

    • 具体点击查看我之前的文章
    • 如不配置,某些文件会发生跨域错误

博客配置

打开WP后台,在 WPJAM 设置->CDN加速->云存储设置 配置如下

  • 云存储:腾讯云COS
  • CDN域名:即之前填写的CDN添加的域名,需要带有HTTPS
  • 图片处理此处不要勾选

img

在本地设置中,需要添加以下其他静态文件后缀

img添加静态文件后缀

设置完成后保存,即可将博客内设置拓展名的静态链接,替换为CDN加速域名

img静态资源为CDN加速域名

CDN加速域名打开不会显示博客,而显示之前设置的单页,发布新的文章博客会自动替换图片链接

img打开主页域名不是博客

腾讯云 CDN 加速静态资源所产生的 CORS 错误

作者 ROYWANG
2022年2月22日 08:00

给站点的静态资源使用了腾讯云CDN加速,文件镜像到腾讯的对象存储里,结果配置完成后产生了CORS错误,即跨域错误


错误

img

CORS - 跨域

抽象的解释下为什么会导致跨域错误

当你拥有 A、B 两台服务器时,当 A 与 B 分别建设了一个网站,两个网站使用的域名不相同,分别为 网站A 和 网站B 。在网站A中调用了 网站B 的资源,此时由于 网站A 的头部参数与 网站B 后端程序所绑定的头部参数的不同,很大概率会导致调用B的资源虽然请求成功,但在浏览器中不会加载,这就是跨域错误。

一台服务器中建设两个或多个网站,也是同理。除此之外,除域名之外,端口、协议头不同均会导致跨域错误。

解决方法

错误报告:

1
Access to font at 'https://ras.its.he.cn/wp-content/themes/typology/assets/fonts/fontawesome-webfont.woff?v=4.7.0' from origin 'https://bcon.roywang.cn' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

发生此类错误主要是因为在请求资源时,资源头中没有 ‘Access-Control-Allow-Origin’,只需添加上即可解决

在腾讯云CDN控制台->域名管理->CDN域名管理

img

在高级配置中配置 HTTP 响应头即可

img

点击新增规格,配置如下:

1
2
3
头部操作:设置
头部参数:Access-Control-Allow-Origin
头部取值:此处为你所需访问资源的域名或IP,可为‘*’,多个域名或IP需用逗号隔开

img

保存并打开配置状态即可解决该问题。

img

Cloudflare 服务中断与 AI 图像生成模型 nano-banana-pro | 2025 年第 47 周草梅周报

作者 草梅友仁
2025年11月23日 23:08

本文在 草梅友仁的博客 发布和更新,并在多个平台同步发布。如有更新,以博客上的版本为准。您也可以通过文末的 原文链接 查看最新版本。

前言

欢迎来到草梅周报!这是一个由草梅友仁基于 AI 整理的周报,旨在为您提供最新的博客更新、GitHub 动态、个人动态和其他周刊文章推荐等内容。


gemini-3-pro-image-preview(nano-banana-pro)-20251123205603171.png

最近,知名云服务商 Cloudflare 发生严重的服务中断,导致使用了 Cloudflare 提供的 CDN、Turnstile、Workers KV 等服务的网站均出现不同程度的故障,而使用了透明代理的网站更是直接出现 502 响应码,无法正常访问网站。

有关此事件的官方详细报告已出,请参考该链接:2025 年 11 月 18 日 Cloudflare 服务中断

笔者的一些网站也使用了 Cloudflare 透明代理,例如 auth-demo.cmyr.dev,这也导致网站无法访问。

QQ截图20251118210910

其中比较尴尬的是,笔者部署的用于网站状态监测的 uptime-kuma 网站,也因为自身使用了 Cloudflare 透明代理的缘故,无法正常访问。

QQ截图20251118213106

上面是短暂恢复时的截图

除了笔者的网站外,像 ChatGPT、Twitter(X)、Pixiv、Spotify 等网站也都出现了类似的故障,甚至连监测故障网站 Downdetector 也因依赖 Cloudflare 而出现故障,无法正常访问。

gemini-3-pro-image-preview(nano-banana-pro)_20251123213034758

那么问题来了,为什么 Cloudflare 故障之后就会对整个互联网造成如此巨大的影响呢?

因为 Cloudflare 自身并不是普通的云服务商,而是一个全球最大的的安全与 CDN 服务商之一,承担了全球网站约 20% 的网站流量。

这也就导致 Cloudflare 自身变成了一个脆弱的核心,一旦故障就会触发 “多米诺骨牌效应”,从而导致灾难性后果。

image-20251123214359940

在本次事件中,Cloudflare 故障了很多产品,但其中对普通用户影响最大的一项就是核心 CDN 与安全服务。

QQ截图20251118200934

因为 CDN 是用于分发静态资源的节点网络,一旦 CDN 失效,那么即便源站运行正常,用户也会无法访问网站。这也是为什么大部分人故障网站都能看到 Cloudflare 502 页面的原因,但源站却显示正常。

image-20251123215001394

除此之外,Turnstile 服务也造成了很重大的影响,因为 Turnstile 服务负责验证用户身份(也就是平常看到最多的验证真人身份的按钮),这还间接导致仪表盘无法访问,因为用户无法通过 Turnstile 服务验证,也就无法登录仪表盘。

以上就是故障所带来的一些影响,接下来简单聊下故障的原因。

image-20251123215102600

根据官方博客的内容,可以画出以上的思维导图。

故障的直接原因是机器人管理系统的特征文件大小翻倍,这导致出现了内存溢出故障。

然后,内存溢出加上使用了unwrap(),直接导致线程崩溃,从而导致 5xx 错误。

而特征文件大小翻倍的原因则是 ClickHouse 数据库权限变更引起的,因为查询数据中出现了重复条目。

应该说,单纯的看故障原因的话,会发现就是个很简单的问题,但一个又一个小问题叠加起来,就造成了灾难性的后果。

这也告诉每一个开发者,永远要以最谨慎的态度去对待生产环境的代码,部署生产环境时一定要充分测试,重复审查,以避免出现低级错误。

随着 AI 编程越来越流行,很多程序员(包括我自己)已经不会十分严格的去审查代码变更了,似乎都默认了 AI 写的代码是完美无缺的。

然而,正是这样的心理,导致越来越多的系统性故障。

我想,还是要尽可能的依赖确定的单元测试、端对端测试等测试方法,才能避免出现类似问题。

笔者最近也在增加一些旧项目的测试用例,以增加代码健壮性。


最近 Google 推出了新一代 AI 图像生成模型 nano-banana-pro(gemini-3-pro-image-preview),是之前 nano-banana 的加强版。

和其他图片生成模型相比,nano-banana-pro 在文字渲染上技压群雄,可以在图片中精确的生成清晰、拼写正确的文字。

上一个章节中的封面和四格就是由 nano-banana-pro 生成的。

nano-banana-pro 目前可以在 https://lmarena.ai/ 上试用。

而且和之前的 nano-banana 一样,对各种各样的画风有着极强的驾驭能力,可以几乎完美的生成各种各样的图片。

下面是一些例子。

gemini-3-pro-image-preview(nano-banana-pro)20251123222623726.png

提示词来源:宝玉 xp

提示词:

创作一张手绘风格的信息图卡片,比例为 9:16 竖版。卡片主题鲜明,背景为带有纸质肌理的米色或米白色,整体设计体现质朴、亲切的手绘美感。

卡片上方以红黑相间、对比鲜明的大号毛笔草书字体突出标题,吸引视觉焦点。文字内容均采用中文草书,整体布局分为 2 至 4 个清晰的小节,每节以简短、精炼的中文短语表达核心要点。字体保持草书流畅的韵律感,既清晰可读又富有艺术气息。

卡片中点缀简单、有趣的手绘插画或图标,例如人物或象征符号,以增强视觉吸引力,引发读者思考与共鸣。整体布局注意视觉平衡,预留足够的空白空间,确保画面简洁明了,易于阅读和理解。

主题是:“做 IP 是长期复利,坚持每日出摊,持续做,肯定会有结果,因为 99%都坚持不住的。”

gemini-3-pro-image-preview(nano-banana-pro)20251123222714613.png

提示词:

为一个复古咖啡品牌设计 Logo,并将其应用到不同的周边产品上,要求文字清晰。

“Design a retro-style logo for a coffee brand named ‘Kaffe’. Use a simple two-tone palette: cream and deep brown. The logo should feature a stylized steaming coffee cup. The text ‘Kaffe’ must be clearly visible, bold, and curved around the cup. 60s vintage vibe.”

“Generate a set of product mockups using the ‘Kaffe’ logo generated above. Create high-quality images of a ceramic mug, a takeaway paper cup, and a coffee bean pouch. Maintain the same vintage color palette and lighting. The logo and text ‘Kaffe’ should be perfectly rendered on the curved surfaces.”

gemini-3-pro-image-preview(nano-banana-pro)20251123145931704-e9hb993.png

提示词:

生成一个网站的 UI 图,内容是一个视频网站的主页面,包括推荐信息流。UI 图上应该存在合适的标注,这是一份可以给前端开发的设计图。不要使用任何知名视频网站的图标,原创一个图标。

20251123144838210-aply6so.png

提示词:

生成一个哆啦 A 梦的四格黑白漫画,内容是哆啦 A 梦向其他人介绍 Nano Banana Pro 的强大之处。

通过以上的例子可以看到,nano-banana-pro 无论是生成带文本的图片还是设计图,都有着极强的能力。

对比现有的其他图像生成 AI,在逻辑一致性和细节控制上十分不错,可以说已经到了无需修改,直接上线的程度。

现在无论是编程 AI、写作 AI 还是画图 AI,都越来越强大,在可预见的未来里,AI 将彻底颠覆这个世界。

博客更新

GitHub Release

rss-impact-server

v1.17.2 - 2025-11-22 20:13:30

摘要:
版本 1.17.2 更新摘要 (2025-11-22)

测试更新:

  • 新增了 IsCustomURL 装饰器的单元测试
  • 新增了对 formatGuid 和 rssItemToArticle 函数的单元测试,以提高测试覆盖率

Bug 修复:

  • 改进了 formatGuid 和 rssItemToArticle 函数的链接处理逻辑

push-all-in-one

v4.5.1 - 2025-11-19 16:42:35

摘要:
版本 4.5.1 (2025-11-19)

主要更新内容:

Bug 修复:

  • 升级 glob 依赖至 11.1.0 及以上版本,修复安全漏洞 CVE-2025-64756(GHSA-5j98-mcp5-4vw2)

最新 GitHub 加星仓库

  • CaoMeiYouRen starred discourse - 2025-11-21 23:47:50
    社区讨论平台,采用 Ruby 语言开发,开源免费且操作简单,已获得 45623 星标
  • CaoMeiYouRen starred wechat-selkies - 2025-11-20 01:40:25
    Selkies 项目提供了一个 Linux 网页版的微信和 QQ 客户端,支持本地中文输入功能。该项目兼容 AMD64 和 ARM64 两种处理器架构,主要使用 Python 语言开发。目前在 GitHub 上获得了 1939 个星标。
  • CaoMeiYouRen starred GKD_subscription - 2025-11-19 17:45:53
    GKD 是一个 TypeScript 编写的开源项目,主要用于第三方订阅管理。该项目在 GitHub 上获得了 9379 个星标,表明其受欢迎程度较高。
  • CaoMeiYouRen starred gkd - 2025-11-19 17:39:45
    基于无障碍服务的 Android 自定义屏幕点击应用
    使用 Kotlin 开发
    支持高级选择器和订阅规则
    GitHub 星标数超过 33,600
  • CaoMeiYouRen starred cc-switch - 2025-11-18 00:00:00
    跨平台桌面全能助手工具,支持 Claude Code、Codex 和 Gemini CLI。主要开发语言为 TypeScript,GitHub 星标数达 4922。

其他博客或周刊推荐

阮一峰的网络日志

HelloGitHub 热点速览

潮流周刊

总结

本周的更新和动态如上所示。感谢您的阅读!
您可以通过以下方式订阅草梅周报的更新:

往期回顾

本文作者:草梅友仁
本文地址: https://blog.cmyr.ltd/archives/2025-47-caomei-weekly-cloudflare-outage-nano-banana-pro.html
版权声明:本文采用 CC BY-NC-SA 4.0 协议 进行分发,转载请注明出处!

DNS 解析延迟毁了我的图床优化

2025年8月11日 00:06

去年夏天,我花了不少时间搭建博客图床,核心目标是分地区解析 DNS,让国内外访客都能快速加载图片。技术方案看起来完美无缺,直到最近群友反馈首次访问时图片加载很慢,我才发现问题所在。

955 毫秒的 DNS 解析时长! 这个数字让我大吃一惊。访客点开博客后,光是确定图片服务器位置就要等将近一秒,这完全抵消了 CDN 优化的效果。

为什么之前没发现?

主要是 DNS 缓存的"功劳"。它会为后续访问记住解析结果,让我的本地测试和复访测试看起来都很正常。直到用户反馈,结合最近准备秋招复习的 DNS 解析流程(递归查询、权威查询、根域名、顶级域名等),我才定位到问题:首次访问时的 DNS 解析延迟

DNS 解析流程分析

让我们看看访客访问 static.031130.xyz 时,DNS 是如何工作的:

sequenceDiagram
    participant User as 访客浏览器
    participant Local as 本地 DNS
    participant CF as Cloudflare<br/>(国外权威)
    participant DP as DNSPod<br/>(国内权威)
    participant CDN as CDN 节点

    User->>Local: 请求 static.031130.xyz
    Local->>CF: 查询 031130.xyz 权威
    Note over Local,CF: 跨国查询,延迟高
    CF->>Local: CNAME: cdn-cname.zhul.in
    Local->>DP: 查询 zhul.in 权威
    DP->>Local: CNAME: small-storage-cdn.b0.aicdn.com
    Local->>DP: 查询 aicdn.com
    DP->>Local: CNAME: nm.aicdn.com
    Local->>DP: 查询最终 IP
    DP->>Local: 返回 CDN IP
    Local->>User: 返回解析结果
    User->>CDN: 连接并下载图片

问题就在这里:前两步查询指向了国外的 Cloudflare 权威服务器。对于国内用户,虽然最终解析到的 CDN 节点是国内的,但跨国 DNS 查询就足以拖垮首次访问体验。那 955ms 的延迟,基本都耗在与国外 DNS 服务器的通信上了。

优化方案

针对这个问题,我采取了三个措施:

1. DNS 预取

在博客 HTML 的 <head> 中添加:

<link rel="dns-prefetch" href="//static.031130.xyz">

这样浏览器在渲染页面时就会提前解析图床域名,等真正需要加载图片时,DNS 结果可能已经准备好了。

2. 延长 TTL

static.031130.xyz 的 CNAME 记录 TTL 值调大(从几分钟延长到几小时甚至一天)。这样本地 DNS 服务器会缓存更久,后续用户可以直接使用缓存结果,省掉权威查询。

3. 迁移权威 DNS(核心)

031130.xyz 域名的权威 DNS 服务器从 Cloudflare 迁移到国内的 DNSPod:

graph TB
    subgraph "优化前"
        A1[访客] --> B1[本地 DNS]
        B1 --> C1[Cloudflare 权威<br/>国外]
        C1 --> D1[DNSPod 权威<br/>国内]
        D1 --> E1[CDN 节点]
        style C1 fill:#ffcccc
    end
graph TB
    subgraph "优化后"
        A2[访客] --> B2[本地 DNS]
        B2 --> D2[DNSPod 权威<br/>国内]
        D2 --> E2[CDN 节点]
        style D2 fill:#ccffcc
    end

迁移后的好处:

  • 递归 DNS 查询 031130.xyz 时,直接找到国内的 DNSPod,响应快
  • DNSPod 直接返回 static.031130.xyz -> small-storage-cdn.b0.aicdn.com,无需中间跳转
  • 整个 DNS 解析链路在国内完成,首次访问延迟大幅降低

优化效果

虽然 DNS 缓存给测试带来了困难,但迁移权威 DNS + 调整 TTL + 添加预取后,首次访问的 DNS 解析时间降到了可接受的范围。

经验教训

  1. DNS 位置很重要:涉及多地优化时,权威 DNS 的地理位置对首次访问延迟影响很大。优先使用国内权威服务器。

  2. 首次访问是关键:虽然缓存能帮助后续访问,但首次访问体验直接影响用户印象。善用 dns-prefetch 和合理的 TTL 设置。

  3. 监控和反馈重要:本地测试环境往往有缓存加持,真实的首次访问体验需要通过监控和用户反馈来发现。

重要提醒:警惕 CNAME 拉平

如果你需要分地区解析来让访客连接到最近的 CDN 节点,务必避开 CNAME Flattening(CNAME 拉平)

什么是 CNAME 拉平?

权威 DNS 服务器(如 Cloudflare)看到 CNAME 记录后,会主动查询目标域名的最终 IP 地址,然后直接返回 IP 而不是 CNAME。

为什么会出问题?

分地区解析(GeoDNS)在权威 DNS 服务器层面实现。当权威服务器执行 CNAME 拉平时,它会在自己的位置查询目标域名的 IP。如果权威 DNS 在美国,它获取的 IP 就是美国最优节点,然后把这个 IP 返回给所有地区的查询者,包括中国用户。这样,你为中国用户配置的国内 CDN IP 策略就完全失效了。

graph LR
    subgraph "启用 CNAME 拉平的问题"
        A[中国用户] --> B[Cloudflare 权威<br/>美国节点]
        B --> C[查询目标 CNAME]
        C --> D[返回美国 CDN IP]
        D --> A
        style D fill:#ffcccc
    end

正确做法

老实使用 CNAME 指向另一个支持 GeoDNS 的域名(如 static.031130.xyz -> cdn-cname.zhul.in,后者在 DNSPod 上做分地区解析),才能保证分流策略正确执行。

如果需要分地区解析功能,不要在相关域名上启用 CNAME Flattening(或 ALIAS、ANAME 等类似功能)。

腾讯云EdgeOne,真香!

作者 w4j1e
2025年7月12日 12:00

前言

腾讯云的 EdgeOne (以下简称 EO)在上半年推广免费套餐时,我并没有多大的兴致。前几天发现云盾的速度越来越慢,切换回多吉又担心什么时候再次被刷流量,所以通过发推的方式得到了官方赠送的兑换码。关于参加活动的方式我不再赘述,体验了两天就两个字——真香!

接入域名

初次接入域名时选择绑定免费套餐,在选择加速区域时可能是备案信息没有刷新,不能选择“中国大陆可用区”,导致我只能选择了第一个选项;由于我的域名全都在 dnspod,接入模式便选择了“dnspod托管接入”。比 cloudflare 好的是,如果你的域名在其它服务商,可以选择 cname 接入方式。

eo接入域名

当然,由于域名在 dnspod,所以无需额外的验证域名归属权,方便很多。

免费版套餐支持接入一个域名,解析200个子域名,对于个人项目和小型企业来说都是完全足够的。

选择 dnspod 接入的方式还有个好处,可以在 EO 控制台很便捷地将已有的解析添加为 EO 加速域名。

在eo控制台可以一键接入

开启 EO 加速时建议不选择推荐模板(网站加速、大文件下载等),如果有需要可以在规则引擎里创建缓存规则。

ssl证书

如果域名在腾讯云,可以把申请的免费证书一键部署到 EO 等项目上;如果在其它平台,可以在 cname 接入后在 EO 上申请免费证书。根据文档,在到期前半个月会自动续期。

eo https证书配置

腾讯云现在申请免费证书一般在一分钟左右就可以颁发,速度比以前快了非常多。

至此,基本上可以正常访问了。

访问体验

我接入域名之初选择的加速区域是“全球可用区(不含中国大陆)”,这也导致一开始我觉得在国内的访问速度并不是很快,加载一张300kb以内的图片都是逐渐显示出来的。

通过路由追踪,可以发现最后一跳在新加坡的一个任播 IP 上,外网的平均延迟甚至达到了 300 多毫秒。通过拨测可以看到国内的访问速度并不是多理想。

eo不含大陆节点的国内访问速度

当时想着这速度至少比云盾目前的状态要好,将就这样用吧。更何况我没有额外配置缓存规则,但是一开始的缓存命中率都很高。

带图片处理规则的文件也能命中缓存

昨天下午四点钟左右接入,拨测了两次,可以看到缓存大多数都是命中的。

大多数缓存都能命中

半夜我突然想到了什么,再仔细去看了一下 EO 的控制台,幸好,EO 可以切换服务区域!

eo服务区域切换

在服务区域切换中仍然没有“中国大陆可用区”,刷新检查备案后,可以从我之前选择的“全球可用区(不含中国大陆)”切换到“全球可用区”。为了验证国内的解析节点和速度是否改变,我又去拨测了一次。

可以看到拨测最快的速度总响应时间才9ms

现在全球包含中国大陆的访问也全是绿点了

通过 nslookup 验证解析以及路由追踪可以看到,确实就近解析到了腾讯云 CDN 位于重庆电信的节点。

eotraceroute

此时在无痕模式下刷新网页,图片的加载也不会一卡一卡的,非常流畅!

写在最后

之前看到论坛有人搞优选 EO 的 IP,还以为免费版不提供境内节点加速,没想到事实上比 cloudflare 大方很多,体验也好太多。

但是熟悉腾讯云的朋友都知道,嗯,我也不必多说,且用且珍惜吧。期待腾讯云的这个“长期”可以稳定地“长期”,短期内不要砍配置了。

CC攻击事件报告 20250613至20250619

作者 SKY
2025年6月23日 13:55
CC攻击事件报告 20250613至20250619

CC攻击事件报告 20250613至20250619

过程和初步评价

发生于 2025-06-13 23点 左右短期,当时很快就结束了,有收到CF的邮件通知但是当时并未理会。

第二天 2025-06-14 23点 至 2025-06-15 23点 左右,持续了整整一天的 CC 攻击。

  • 攻击特征:
    • 第一波攻击固定路径,第二波攻击另一个固定路径。
    • 均为固定路径,无参数,无随机路径。
    • User-Agent (UA) 较多。
  • 攻击影响:
    • 反向代理服务器略有卡顿。
    • 后端服务器满载。
  • 流量分析:
    • UA 种类繁多,国内 IP 特别多,国外 IP 也不少。
    • CC 攻击量不小,规模上看使用了至少几千个代理 IP,其中国内 IP 都有 2000+。
    • 2025-06-14 单日 (Cloudflare 统计):
      • 独立访问者: 27.5K
      • 流量: 14TB
      • 请求数: 58.81M
    • 2025-06-15 单日 (Cloudflare 统计):
      • 独立访问者: 48.8K
      • 流量: 28TB
      • 请求数: 106.06M

后续发现是 Cloudflare 的页面规则当时设置的没缓存成功这个路径,最后通过 CDN 强制缓存控制后,问题基本解决,绝大部分请求都已缓存。

样本抽取

抽取了以下几种场景样本:

  • 表A: 06-15 中国大陆IP (CF自动抽样20%)
  • 表B: 06-15 全球IP (CF自动抽样20%)
  • 表C: 06-15 抽样百万大陆IP (通过国家盾/ASN盾/IP盾)
  • 表D: 06-15 抽样百万全球IP (通过国家盾/ASN盾/IP盾)
  • 表E: 06-14-06-15 抽样七百万全球IP (全部样本)

注:随着攻击持续,国家盾/ASN盾/IP盾在持续迭代,所以有的会从“通过”变成“未通过”。

第三波攻击

第三波攻击发生在 2025-06-18 23点 至 2025-06-19 03点 左右,这时我事先额外加上了阿里CDN。

  • 防御架构: 国内由 CF CDN + 阿里CDN + 反代节点 一起抵御。
  • 过程: 发现反代节点跑了 0.5C 左右的资源,但因持续产生流量遂将其掐掉,让阿里和CF来抵御。
  • 数据统计:
    • Cloudflare (2025-06-18):
      • 独立访问者: 12.98K
      • 流量: 3TB
      • 请求数: 24.62M
    • 阿里云 (同期):
      • 请求数: 55.47M
      • 客户端请求流量: 27GB
      • EdgeStart 响应流量: 253GB

样本抽取 (第三波)

  • 表F: 06-18-06-19 抽样75万大陆IP (通过国家盾/ASN盾/IP盾)
  • 表G: 06-18-06-19 抽样万全球IP (全部样本)

目前审计几个样本表后得到了 5,247个中国IP(总量23,656个IP),是目前遇到国内来源最多的一次攻击,说明攻击者在肉鸡资源上实力不俗。

IP 统计已发布在: https://github.com/BlueSkyXN/Comprehensive-Network-Defense/blob/master/IPs/IPs_CCATK-20250614-0619.csv

防御策略

防御策略上,重点在于 Cloudflare 规则,其次阿里 CDN 套娃 CF 还能双重防御,后面其实还可以接宝塔 NGINX 和雷池。

Cloudflare 防御

首先重点肯定是大善人 CF 了,CF 的设置项目非常多。整体来说包括:缓存规则、自定义规则(原WAF规则)、速率限制规则、安全级别、自定义列表、IP和ASN访问规则。

缓存规则

这是一个比较重要的点,无论是日常使用还是防止简单 CC 都有很好的效果。免费用户可以设置 10 条缓存规则。

  1. 缓存级别:
    • 忽略缓存控制标头,使用此 TTL (例如设置为2小时): 这个选项可以强制缓存那些服务器标记为动态但实际内容不变的页面 (除非你需要很多真实动态内容)。
  2. 缓存密钥:
    • 缓存欺骗盔甲: 开启。
    • 按设备类型缓存: 可开,如果攻击 UA 大量随机化,可能需要关闭。
    • 忽略查询字符串: 可选开启,如果对方进行随机查询字符串攻击则需要开启。
    • 查询字符串排序: 建议开启。
  3. 其他:
    • 重新验证时提供过时内容: 设置为“否”。
    • 源服务器错误页面通过: 设置为“否”。

自定义规则 (原WAF规则)

免费用户可以设置 5 条自定义规则。这是高级表达式发挥作用的地方。

速率限制规则

免费用户只能设置 1 条。由于限制,只能当作全局限制来用,例如单IP在10秒内请求超过100次则封禁10秒。

安全级别

遭遇攻击时开启“我正在受到攻击”模式即可。

自定义列表

免费用户只能创建 1 个自定义列表,但支持多达 10,000 个条目,支持 IPv4/IPv6 和 CIDR。可以和国家、ASN 盾配合使用(在自定义规则中调用它)。

IP和ASN访问规则

免费用户支持 50,000 条规则,优先级较高,对全账户通用。支持 IPv4/IPv6、CIDR、ASN 和国家。但手动只能一条一条添加,且日志记录不全。

阿里 CDN 防御

目前国际站免费,有不少限制但是够用。内置了负载均衡池等功能,适合套娃 CF。

WAF - 智能限频

藏得比较深,是一个高级的速率限制规则。位于“安全防护”->“WAF”的最下面。可以设置高、中、低防护等级(默认对应10秒内4000/200/40次请求),可选开启 JS 挑战。

WAF - IP访问规则

只能添加 200 条,不是很有用。

WAF - 自定义规则

免费 3 条,可选开启 JS 挑战。匹配规则与 CF 类似,但 IP/ASN 等可以使用“分组”功能,每个分组支持 500 条,免费用户可创建 10 个分组。

规则 - 缓存规则

免费 10 条,逻辑上和 CF 一样,要覆盖源站(除非你需要很多真实动态内容)。

规则 - 安全规则

免费 2 条,与上面的自定义规则不同,结果只能是修改安全级别(最高就是 CF 的“正在攻击”模式),可应用 IP 组等。

撕开国内视频网站的4K迷雾:为什么你的4K视频还不如1080P清晰?影视飓风被下架的视频,撕开了国内视频网站的遮羞布

作者 Luke Fan
2024年10月16日 09:21

中国的4K视频还没有1080P清楚,这到底是伤害了谁呢?大家好,这里是老范讲故事的YouTube频道。今天咱们要讲一讲,一条视频撕开了国内各视频平台遮羞布的故事。

这个视频呢,是影视飓风发的。影视飓风是国内专门做影视器材、影视技术推广和科普的一个顶级自媒体。咱们说他是自媒体稍微有点亏心,毕竟好几百人一公司,专门做各种影视设备和影视技术评测与科普的。这个公司呢,上架了一条视频,就抱怨说国内各个视频平台,他们的4K视频清晰度很烂,甚至还没有前两年他们推的1080P清晰度高。

所有视频都是糊的,或者看着很奇怪。而且,越是热门的视频,看的人越多,视频就越糊。这条视频出来以后,只用了一两天的时间,就被所有的平台全部下架,因为所有平台都在干这个烂事。但是呢,这一次声音并没有被压下去,很多的博主都上来声讨这些骗钱的视频平台。因为他们是按4K找我们收的钱,你给我看的视频还没有前两年1080P清楚呢,太过分了吧。

一方面是声讨他们,另外一方面呢,也在为影视飓风所鸣不平。那么到底发生了什么事呢?中国人都知道,4K肯定应该比1080P清楚。1080P就是1920乘1080的这个分辨率,4K呢,就是4块1080P的显示器拼在一起,横着是两个1920,竖着是两个1080,这样四个拼音块叫4K,应该是比1080P清楚4倍才对。

但是呢,我们不能光看分辨率,还要看什么?还要看码流。码流什么意思?就是一秒钟视频它的文件到底有多大,或者说那个数据包到底有多大。中国的视频网站呢,是给大家4K的分辨率了,但是呢,他们把码流压得比原来的1080P还低。一秒钟的视频里头,我就给你非常非常少的数据,然后让你去渲染4K的分辨率的这个画面。

那你说这玩意怎么渲染出来?其实很简单啊,咱们现在使用的,甭管是1080P还是4K,甭管是任何一种编码算法吧,咱们这叫有损压缩。什么叫有损压缩?就是压缩完……

这个视频在还原的时候,并不是完完全全还原回去的,而是有一些节点,有一些像素是算出来的。他不能保证跟原来完全一致。在有损压缩的情况下,到底损失多少呢?那我损失多一些,那我不是一秒钟可以发的,这个数据就少一些吗?我到那边去尽可能去算就完了。他通过这样的方式来实现。那么在有损压缩牺牲码流的情况下,甭管是4K、8K或者更高的分辨率,其实都是没用的。因为就传了这么多数据出来,到那头的解析器或者播放器解码的时候,巧妇难为无米之炊啊,你没法去把它解析得很清晰。

那为什么很多视频看着还很奇怪呢?因为这些视频网站用了一个比较缺德的算法,这个算法叫什么?叫锐化。什么叫锐化呢?它就是在这个分界线上,比如说你看这是我的脸,脸外面应该是切图切出去的部分。这一部分里头呢,它发现了这个图像的边缘,在图像边缘的地方增加对比度,让所有的图像边缘变得更清晰一些。这样的话,就可以在相对比较低分辨率的时候,让你觉得这个边都给我勾清楚了,都描清楚了。

所以他说很多的视频你看着虽然是4K,第一个很糊,一点都不清楚;第二个又觉得很怪,因为所有边缘的地方都给你勾个边。他通过这样的方式去欺骗广大的消费者,广大的订阅用户。那么你说有没有一些技术,可以说我把技术升级了,少一点码流,可以多一些清晰度呢?也有,但是中国的这些视频平台相对来说都喜欢用比较旧的技术。视频编解码技术其实也没有那么多种,咱们现在常见到的也就是H.264、H.265,谷歌自己家开源的WebM,也就是VP9,还有大家一起加盟的叫AV1,谷歌、微软、英特尔、英伟达、网飞等一堆人加盟了一个新的标准的AV1。

然后呢,是H.266。你说我们没见过这些东西,我们见过的都是MP4、MKV、M4V。这个里头是这样,大家现在看到的所谓MP4,其实就是H.264。那么你说这个H.265是不是MP5?不是啊。

我们有时候会看到它那个后缀是EIC,那个就是H.265。它们呢,压缩比会更高,但是呢,会更清晰。对于这种更高的分辨率的视频来说,会更适应H.264。其实对于4K视频,已经不是那么适应了,或者说它会有一些问题。而且H.264的压缩也没有那么高,因为同样的视频,你用H.265去压缩的话,它的这个尺寸是H.264的一半。

你比如说,就算是一部4K的电影,比如说90分钟电影,如果是H.264的话,它大概压完了以后应该是有40多G;你如果用H.265的话,大概是20多G。再往后呢,就是刚才我们讲了谷歌的VP9,这个呢其实除了谷歌自己之外,别人用得很少。咱们最多见到VP9的地方就是YouTube,YouTube里的大量视频,特别是4K视频,都是用VP9的。你下载下来的那个文件格式是WebM,这种格式呢,它基本上算法和整个的性能是跟H.265比较相近的。

然后AV1呢,是比WebM的VP9、比H.265还要再压缩得厉害一些,但是呢,这种压缩是不牺牲质量的情况下,通过更好的算法能够实现压缩。AV1呢,它可以把原来可能20多G的一部电影,变成十几G,可以再压小一半。但是AV1现在用得很少,国内的话就是爱奇艺和腾讯,号称要准备开始支持AV1了。国外的话,苹果、谷歌、Netflix都是AV1的。

然后H.266是最新的国际标准,这里头还有一点区别是什么,就是AV1是开源的,不用收专利费。剩下的H.264、H.265、H.266,这个由国际的IMPEC委员会、动态图像压缩委员会,大概是这样的一个名字,这些标准都是要收专利费的。国内的视频网站基本上都是用的H.264。那你说不对啊,他们想省带宽,使用AV1不就行了吗?它可以把视频压得更小,而且还很清楚。这是这样啊,天下没有白来的午餐。你想用更高算法的,或者更高技术规格的这个编码方式去编码视频的时候,你需要更高的编码算力。

原来,比如说我一台服务器,就可以对这个4K视频进行两倍速编码、三倍速编码。什么叫三倍速编码?就是原来,比如三个小时的视频,我一个小时给你编码完了,咱们就基本上认为它叫三倍速编码。但是呢,如果你用AV1,原来可能一个视频上来以后三个小时,你需要六个小时才能编码完成。他这个算力要求会上升很多。他通过这样的方式,把更多的信息隐藏在数据包里面去。

至于H266的话,现在刚开始去卖相关的专利和IP,还没有真正开始推起来。H266的算法应该会比AV1可能持平,或者比它稍微好一些,但现在用的人很少。为什么越热门的视频越糊呢?这个其实很多人很诧异。你按道理说,应该越热门的视频越清楚才对啊,大家都看同一个视频,那我这个视频缓冲一次不就对了吗?这个其实也很简单。你越热门的视频,它占用的带宽就越高,而在这个里边,真正费钱的不是存储空间,而是带宽。

所以,比如说今天有一个新的片子上来了,大家都要去看,那我们一定要尽可能地把这部片子压得更糊一些,让它占的带宽更少一些,才能够更省钱。否则的话,这个成本实在太高,受不了,这纯纯就是在骗钱。

那我们来分析一下视频平台关于视频分辨率的成本到底是怎么构成的。我们先想,我们上传一部视频。上传视频的时候,其实对于平台来说,他们只需要承担一个入口的费用,甚至这个可能都不是那么贵,因为我们上传视频并不要求完全实时,除非你直播。而且直播的话一般也就是1080P,不会给你做更高分辨率了。

上传完了以后,就是一个存储,我把它存下来就好了。对于视频平台来说,这个存储成本也是很大的一块钱,但对于它整体成本来说,相对占比比较小。再往后的一个巨大的成本是什么?是编码。你说我上传的就是4K MP4或者4K H265,为什么还要编码?你想,我们去看视频的时候,他会根据用户的带宽、用户的设备以及用户的付费情况,给用户不同的分辨率。所以他们去编码视频的时候……

会把我们上传的视频直接编码成,比如360K、480K、720P、1080P、2K、4K。它会把所有编码都编一遍,然后呢,还按不同的码流把它都编一遍,这样才可以在用户需要相应码流的时候,把相应的文件拉出来。

大家如果去看YouTube,或者看包括国内的一些视频网站的话,有一些专门的破解和下载软件。你把一个YouTube链接扔进去的时候,它告诉你说,我们现在从这个链接里头找到了一长串儿的URL,一长串儿的视频地址。它就是告诉你说,这个视频一共被压缩成了多少个分辨率。

我们经常去下YouTube上的这种长音乐视频,它那儿有4个小时、8个小时这种音乐视频。如果你是在很好的设备上放,你就可以下这种十几个G的版本,4K的。它一般下来是WebM的,从这个YouTube上下来。那你说,我就是想听个歌,我也不想看这个画,你就可以下这个单纯的音频,甚至说我可以下一个很低分辨率的视频的音频,可以下一个360P的,这个非常非常低分辨率。那个文件可能就几百兆就下来了。

整个的编码过程,其实是非常非常耗算力的,因为我们不停地上传视频,它就要不停地对所有上传的视频进行编码。甭管有没有人看这个编码的视频,比如说我上传了4K的,从来没有人看过这个4K的视频,它也需要重新编码一个4K,肯定是要在我那个基础上重新编码的,不会说拿我那个4K直接上去。

我一个4K 60帧的视频,上传到YouTube之前,应该是每20分钟17个G是这么大。我在本机编码完了以后,再上传的时候,20分钟大概就已经剩一半了,因为我是用本机的剪映重新编码一下,大概就剩个10个G左右。然后呢,10个G到了YouTube,你再从上面把4K视频再拉下来的时候,发现就剩4个G了。它一般是这样的一种编码方式,送上去,哪怕是从来没有人看过这个4K视频,它也会给你重新编码一下,然后变得小一些,统一的码流去处理。

当然你如果是放到B站上或者放到国内的这些视频网站上,你可能一个20分钟的4K 60帧视频,下载的时候估计也就剩下可能一两个G。这样一来,这事就是另外一个问题了。再下一个事是什么很贵呢?就是专利费。刚才我们讲了H.264,其实它因为比较旧了,它的专利费是比较便宜的。而且你买各种的编解码软件,买各种芯片的时候,它们都已经付过专利费了。

你说我做H.265,这个就要贵一些。你说我要用H.266,更贵啊。那你说我用AV1,那个便宜了。但是呢,你对于编码的算力,包括什么显卡,这些东西就都需要再增加的成本。现在支持AV1的,可能只有一些最新的显卡,以及最新的CPU,比如像苹果的这种M系列的CPU,它就会支持AV1。高通的8根2、高通888、高通8阵一都不支持。高通8根2是专门有AV1的硬编码的。

你说我没有这个硬编码,通过软件编码行不行?那个手机会冒烟的啊!那你说现在CPU,AMD也好,英特尔也好,只有最新的CPU才支持AV1的硬编码。而且它整个的算力成本是非常高的。所以国内现在用AV1的很少。就算是爱奇艺跟腾讯,也只是宣称了要用。真正我们现在在手机、平板上或者电视上想去看到AV1,还是比较难的。为什么?你把AV1弄下来以后,你到本地未必解码得开,或者你解码你只能进行软解码,就是通过CPU进行计算的解码,而不是说我这个CPU或者GPU里面有他的解码算法,有他这个解码芯片,然后我可以直接把他算硬解出来,还不是干这个。

所以他们现在也不太敢用AV1的东西出来,这个都是他们需要去思考的。存储其实成本不高,真正成本高的是带宽,CDN和宽带成本是高的。CDN叫什么?叫内容分发网络,就是它要尽量的让你在离你比较近的地方找到相应的资源,可以看到这个视频。因为我们看视频,希望能够连贯的把这个视频看完,不是说整个把它下载了以后再看,而是通过流的方式连贯的看。如果这个服务器离你很远,中间经过很多的节点……

你的传输速率就会非常不稳定,会来回抖动。那么他就不行啊,他一定要离你近的地方,重新再复制一遍这个视频,让你可以在离你最近的服务器上,尽可能尽量少的节点看到这个视频。这个成本是非常非常高的,对于视频网站,包括像直播网站,还有像什么抖音这样的网站,他们的成本最大的一块就是CDN成本。

那么中国为什么跟CDN成本这么死磕呢?一方面是咱们收的会员费低啊。你说我去跟YouTube、跟咕噜、跟HBO或者是网飞去比,大家收的会员费,中国基本上也就收了人一个零头。人家看一个月的钱,够咱看一年的,差不多是这么一个水平,所以咱们没收着钱。

另外一头呢,中国的CDN成本是美国的三倍。为什么是这样的呢?咱们中国人那么有钱吧?原因呢有两个。第一个原因是中国的网络呢,是中国移动、中国联通、中国电信,是这样的三套网络。三套网络之间呢,并没有那么通畅,而且中国的网络之间的节点是隔离的,或者说它之间的这种联通的成本是很高的。你想让很多比较远的地方人看到你的内容,你就要在当地付两三套相应的CDN服务器,你才能让他看到。

所以如果你在电信的网络上布了一个服务器,他们在联通的网上看,那这事有可能他就需要绕一个很远的中央节点再绕回来,那成本就高去了。你必须要再弄一次。那你说还有双线机房,有这种双线机房,就同时插两根线的,那就更贵呗。就这么简单的一个问题。

所以中国第一个大的问题,就是中国的网络拓扑结构非常复杂。我们在盛大的时候就遇到这样的问题,你如果想让东北的人进来打游戏,你必须在东北专门设计设置机房,否则的话他就没法跟人打,因为他特别慢,他这个节点特别远,是在中国整个的互联网拓扑结构图的一个最边缘的地方。他要想到上海服务器,就非常非常麻烦啊。

第二个问题是什么呢?垄断。中国是三大运营商垄断了这价格,而且呢,谁可以去做这个网络,谁不可以去做网络,谁可以去申请到证书,这都是国家机关可去批准的。

普通人没法去搞这样的竞争,所以呢,他们整个都价格就很贵。没有竞争需求嘛,都是国家说了算,都是国家的生意。我不能让国有资产流失了,所以中国的CDN成本是比别人贵的。那么这些视频网站就很痛苦。一方面,我收的钱比别人少,就是人家零头;另外一方面,我需要承担的最大成本是别人的价格的三倍。我该怎么办呢?我就只能是上来骗吧。我收了你4K的钱,但只给你看最不清楚的1K的视频。

中国人呢,为了应对这种CDN价格成本的问题,也想出了很多的骚操作方式。像刚才我们讲的降画质,加这个锐化,都是他们想出的办法。然后还有一种奇葩的方法,什么叫PCDN呢?我不是要到你机房里去调这个数据吗?咱不费劲了啊,咱从你电视里调,或者从你家里的机顶盒里钓。我们从每一个节点往外钓这个内容,也可以。但是后来呢,是国家不允许这么干了。你必须是从别人的机房里边调。为什么呢?因为很多人抱怨说:“你看,我这家里头买了一谁家的电视,这个电视在我不开机的时候,还跑了大量的流量出去。”这个事实在受不了。而且我影响正常使用了。我平时在电脑上,或者在其他的设备上看一些视频,或者做一些工作的时候,变得很慢。我的带宽都被这些电视去给人做P2P节点去了,这个也很讨厌。

这个也是中国人想出来的应对CDN成本的一些奇葩方法。那么,降低清晰度到底伤害了谁呢?我们题目就是这样的一个题目。付费用户的权益肯定被伤害,这没什么好说的。我花钱买了4K了,你没给我看,你给我看的比原来模糊了,这个算欺诈消费者。另外一个谎言必须要更多的谎言来弥补。他给我看4K视频,结果比原来1K的还模糊,那这就是个谎言吧。这个谎言其实损害的是整个行业的利益。

什么叫整个行业的利益?这就是视频行业。视频行业从哪开始?从相机,从摄像机,从整个的视频平台,从电视,从电脑,从手机,这都算是视频行业。你看,我最后看视频,我有可能在手机上看,有可能在平板上看,有可能在电视上看。

这都是视频行业。那你一旦撒了这个谎,等于整个行业都受损失。有人说,有这么严重吗?我不就是骗了点钱,给人看了一个低分辨率模糊的视频吗?我还给人加了个滤镜,做了个美颜,做了个锐化,一般人还看不出来,真的有这么严重啊?

咱们这样就要讲一讲,为什么这个事是由影视飓风爆出来的。影视飓风呢,是国内影视知识、影视器材的专业媒体,应该算第一名。他的创始人呢,叫Tim,也算是一个大网红。这个Tim呢,中文名叫潘天虹,算是个富二代。他父亲是圆通速递的总裁潘水苗。

这个小伙子呢,留英学的电影学,回到国内以后呢,就做了这样的一个自媒体,现在也是几百人的公司了。他呢,发现了一个问题是什么?就是你想,这刚才我们讲的什么照相机啊、电视机啊、投影仪啊,你要更新换代啊。更新换代了就找人做评测,找人写软文,找人去拍视频,去吹牛。他们这个影视飓风就专门干这个的。

结果他给人拍的这个视频,比如说,哎,上了一个新相机,我给你拍一下对比视频。这是老相机的,这是新相机的,两个视频左右一对比,说你们看看有区别没有。最后把这视频上到B站上以后,发现没区别,甚至老相机拍的,可能比新相机拍的还好一点。

那这金主爸爸就不干了,说你这不糊弄事呢吗?你拍了视频出去,我新相机没卖掉,这哪成啊?后来人家找原因,找了原因以后说,我是拍出这效果了,这所有的片子在我这看都是对的,新相机这个效果就是比老相机好。但是呢,一旦到了B站上,经过B站的压缩再传播以后,老相机的那个视频的效果,可能就比新相机还好一点。

那这事就没法整了,你跟金主爸爸怎么解释?我收人广告费了,给人拍了这新相机的这个评测,最后发现画质下降了。所以他拍了这样的一个视频,说大家如果再不注意这个问题的话,整个的行业就废了。如果大家都去看这种假4K,那我为什么要去买新相机呢?我为什么要去买新电视呢?4K电视我为什么要买呢?那我去买那个1080P的电视,不就完事了吗?我为什么要去买新的显示器?

为什么要买新手机呢?新的手机讲的是说:“哎,你看我这个手机高通8根2,高通8根3的这个芯片在里头,我可以做AV1编码,AV1解码。”我为什么觉得这个事没有意义呢?你最后喂回来的还是一口屎。如果视频平台在中间去撒谎骗人的话,整个行业就已经失去了升级的动力,大家没有升级的意义了。

你像我拍4K视频到YouTube上,大家还是能看出区别了,4K跟1080P还是不一样。但是你要到国内的,比如B站这些平台上,你上传4K视频,他们根本看不出来,比1080P还糊涂。那么他为什么要去买新的拍摄设备呢?没有任何意义。

我们所有的什么以旧换新,换电视、换手机、换相机,都没有任何意义了。这件事情就是一个被掩盖的谎言,会阻碍整个社会进步的故事。而且呢,这应该仅仅是一个被掩盖的、不能说的、拍了视频马上被下架的一个谎言。在某一个行业里头,如果出现这种谎言的话,那么整个行业就会停滞,甚至倒退。

这就是典型的案例,就是我们看到的糊视频,导致了整个的视频行业,他整个的更新换代全都停下来的一个故事。好,这个故事就跟大家讲到这里。感谢大家收听,请帮忙点赞,点小铃铛,参加Discord讨论群。也欢迎有兴趣、有能力的朋友加入我们的付费频道。再见。

ImageEngine开发者账户免费CDN,每月10GB流量,泛播加速

2024年9月12日 08:50

ImageEngine提供内容分发网络 (CDN),可帮助优化您网站的图片。它将您的图片来源 (HTTP 或 S3) 连接到公共分发地址,也称为“引擎”。

这样,您的图片便可从分发地址提供,从而加快加载速度并提高您网站的整体性能。

 

更多:免费CDN / WordPress CDN

 

注册入口

必须在这个入口注册,否则不是开发者账户!
https://imageengine.io/developer-program/

 

免费额度

支持图片,视频和js和css等前端静态资源加CDN加速

每个月10GB访问流量

支持1个引擎

不支持自定义域名

 

 

演示内容

MP4:https://arc5bhgz.dev.cdn.imgeng.in/yanshi.mp4

图片:https://arc5bhgz.dev.cdn.imgeng.in/yanshi.png

 

 

简要步骤

1,访问注册地址,点击【GET STARTED】按钮。填写源网址。

 

2,填写邮箱,密码完成账户注册。邮箱无需接收验证码。

 

3,选择源网址的协议头,是http?还是https?

 

4,注册完成后,可见随机分配的域名

 

5,分配域名国内访问情况!如图!

 

 

 

6,订阅信息可看见订阅名称是 开发者账户,没有到期时间,以及流量使用情况!

 

流量统计

哈哈哈,文章发布第一天就有大佬把我的10G流量刷完了!正好看一下流量统计!

在概览页面可看见,缓存命中情况,流量使用情况等信息。流量已经跑了25G!

流量超了之后显示:Error 429 Quota exceeded

访问 引擎分析页面,可以看到更详细的统计分析内容!

 

 

💾

自建图床小记五——费用

2024年8月21日 00:05

自建的图床自 8 月 13 日正式启用以来,已经过去一周多了,具体的费用是多少呢?原先设计的 0 额外投入有没有实现呢?

博客访问统计

这是我的博客访问统计,在这一周多的时间内,一共有 1.27k 次页面访问,被 671 个访客访问了 769 次,平均下来每天也有一百多次的页面访问。

Cloudflare Workers 和 Cloudflare R2 的免费额度全部够用,用量全部小于免费额度的 1%。

R2 的免费额度

R2 的用量

Cloudflare Workers 过去 24 小时内的请求次数

又拍云联盟每年可以领取 67 元的代金券,平均每天控制在 0.18 元内即可实现白嫖。

又拍云账单

可以看到,这一套图床在我博客当前和可见的未来的访客情况下,在不被人恶意刷流量的情况下,是不需要投入除域名续费以外的其他成本的。

自建图床小记三—— SSL 证书的自动更新与部署

2024年8月14日 10:35

为什么要自动更新?

众所周知,为站点开启 https 访问需要获得对应 host 的 ssl 证书,而如果希望证书被访客的浏览器所信任,需要拿到由 Certificate Authority (CA) 签发的 ssl 证书。在前一阵子那波 BAT 等大厂提供的云服务停止发放免费的由 TrustAsia/DigiCert 签发的一年有效期免费 ssl 证书之后,市面上已经没有被广泛信任的 CA 签发的免费的一年有效期的 ssl 证书了,于是不得不用回由 Let's Encrypt/ZeroSSL 等 CA 签发三个月免费证书。

但话又说回来,三个月有效期确实不太够,一年有效期的证书就一年一更,手动申请部署也不麻烦;三个月有效期的证书手动就有点麻烦了——我一般会在证书到期的前 15 天进行更新,防止最后几天自己太忙了没时间管。

这套图床架构的自动更新有没有困难?

境外

通过 Cloudflare SaaS 接入的域名通过验证后会自动获得由 Cloudflare 提供的由 Google Trust Services 签发的证书,不需要我们操心。

SSL Certificate provided by Cloudflare

境内

咱选用的又拍云 CDN 提供了免费的 Let's Encrypt 证书及其自动续期服务,但需要我们把图床访问域名的 DNS CNAME 解析到他们家。

SSL Certificate provided by upyun

这里有个问题,我们这套图床架构在境外的解析是解析到 Cloudflare 的,不可能通过 Let's Encrypt 的 acme challenge。如果使用 upyun 申请 ssl 证书,则意味着每次更新都要我们手动将境外的 dns 解析记录暂时解析到又拍云,待证书更新成功后再解析回 Cloudflare,非常麻烦。

使用 Github Action 跑 acme.sh 获取 ssl 证书

本着「能使用长期免费稳定服务就使用长期免费稳定服务」的思想,决定使用 Github Action 申请 ssl 证书。

在 Github Action 跑 acme.sh 获取 ssl 证书意味着不能使用 http 文件检验的方式检验域名所有权,需要使用 dns 检验。截至本文写作时间,acme.sh 已经支持了 150+ 个主流的 DNS 解析商(Managed DNS providers)的 api,针对不支持 api 修改 dns 解析记录的,还可以使用 DNS alias 模式——即将需要申请 ssl 证书的域名先 cname 到一个工具人域名上,将工具人域名通过 NS 解析到 acme.sh 支持的 DNS 解析商,进而实现 CA 对域名所有权的验证。

先在本地跑起来

我采用的是 Cloudflare,直接在个人资料页创建一个具有编辑 DNS 权限的 API 令牌

创建令牌

获得令牌

随后在自己的域名页面,找到区域 ID 和 账户 ID

区域 ID 和 账户 ID

在自己的本机安装 acme.sh,设置好 Cloudflare DNS 的几个变量

export CF_Token=""
export CF_Account_ID=""
export CF_Zone_ID=""

随后可以尝试使用 acme.sh 签发 ssl 证书

acme.sh --issue --dns dns_cf -d cdn.example.com

ssl 证书到手

上 Github Action

原本是打算直接用 Menci/acme 这个 Action的,可惜遇到了点问题。

在我本地,Cloudflare 相关的 Token 和 ID 并没有被写入到 account.conf,而是被写在 cdn.example.com_ecc/cdn.exampe.com.conf,大概就没办法直接用这个 Action 了,不得不转去手搓。不过好在 Menci/acme 中还是能抄到不少的。

压缩本地的 ca 文件夹

cd $HOME/.acme.sh/ && tar cz ca | base64 -w0

安装 acme.sh

- name: Install acme.sh
  run: curl https://get.acme.sh | sh

解压 ca 文件夹

- name: Extract account files for acme.sh
  run: |
    echo "${{ secrets.ACME_SH_ACCOUNT_TAR }}" | base64 -d | tar -C ~/.acme.sh -xz

执行 acme.sh 申请证书

- name: Issue Certificate
  run: |
    export CF_Token="${{ secrets.CF_TOKEN }}"
    export CF_Zone_ID="${{ secrets.CF_ZONE_ID }}"
    export CF_Account_ID="${{ secrets.CF_ACCOUNT_ID }}"
    mkdir -p output
    ~/.acme.sh/acme.sh --issue --dns dns_cf --force -d ${{ env.domain }} --fullchain-file output/fullchain.pem --key-file output/key.pem

压缩证书

- name: zip Certificate
  run: |
    zip -j output/${{ env.domain }}_$(date +%Y%m%d).zip output/fullchain.pem output/key.pem

通过 tg bot 发送压缩包给自己

- name: Push Certificate
  run: |
    TG_BOT_TOKEN="${{ secrets.TG_BOT_TOKEN }}"
    TG_CHAT_ID="${{ secrets.TG_CHAT_ID }}"
    curl -s -X POST https://api.telegram.org/bot${TG_BOT_TOKEN}/sendDocument -F chat_id=${TG_CHAT_ID} -F document="@output/${{ env.domain }}_$(date +%Y%m%d).zip"

部署到又拍云

这里使用的是 menci/deploy-certificate-to-upyun。由于又拍云没有提供上传 ssl 证书的 api,因此只能通过模拟用户登陆的方式实现。

- name: Deploy To Upyun
  uses: Menci/deploy-certificate-to-upyun@beta-v2
  with:
    subaccount-username: ${{ secrets.UPYUN_SUBACCOUNT_USERNAME }}
    subaccount-password: ${{ secrets.UPYUN_SUBACCOUNT_PASSWORD }}
    fullchain-file: output/fullchain.pem
    key-file: output/key.pem
    domains: |
      ${{ env.domain }}
    delete-unused-certificates: true

SSL 证书成功部署到又拍云

参见

腾讯云免费CDN终结了

作者 clark
2024年1月7日 15:02

2024 年 1 月开始,腾讯云的免费 10G CDN 流量包活动结束。

腾讯云免费 CDN 终结了

曾经的 CDN 产品,百花齐放,腾讯云,阿里云,百度云加速,360 网站卫士等等都有免费的福利额度,而且每个月自动赠送额度,对于小网站来说,根本用不完。

随着腾讯云的活动终止,大厂 CDN 福利也算是完全终结了。

目前口碑较好的,还有一个七牛云,每个月免费 10G 流量,需要的可以先切换过去:

点击领取七牛云福利

❌
❌