网站应急救援

我用一套自建鉴权规则，把 CDN 盗刷流量砍掉了 65%

Sun, 04 Oct 2026 16:03:16 +0800

背景

一个月前，我发现站点的 CDN 流量异常。

不是那种一眼能看出的暴涨，而是每天稳定在 8-12 GB 的“温水煮青蛙”式消耗，持续了整整 17 天。国内某 CDN 厂商后台的 AI 分析报告写得很清楚：连续 17 天、每天固定一批 IP、请求量稳定、UA 每日轮换、Referer 全部为空。

但该厂商的“自动防盗刷”在整整 17 天里，一次都没有拦截。它拦住了一些无关紧要的图片小文件，真正的盗刷流量，它视而不见。

问客服，客服让我“自己配黑名单”。

厂商为什么解决不了

后来我想明白了，这不是某一家厂商的能力问题，而是模式问题。

第一，厂商的防护是通用的，而攻击是定向的。

CDN 厂商面对的是几百万客户，它只能做“一刀切”的通用规则：IP 信誉库、UA 黑名单、频率阈值。这些规则对大规模、低门槛的攻击有效，但面对小批量、持续性、有针对性的盗刷，它识别不了——因为一旦把阈值调低，就会误伤海量正常客户。厂商不敢这么做。

第二，特征库永远滞后于攻击。

厂商的自动防护依赖“高危 IP 特征库”，而特征库的更新逻辑是：先有人被攻击，再有特征被提取，然后才能拦截。你的站点是第一批被攻击的，你的攻击特征还没进库，厂商自然拦不住。等你被刷了 17 天，特征可能刚进库——但攻击者已经换了一批 IP。

第三，厂商和你的利益并不完全一致。

CDN 按流量计费。盗刷产生的流量，在账单上看起来和正常流量一模一样。在人工介入之前，厂商没有动力主动识别并拦截——因为每拦掉 1GB 盗刷流量，厂商就少收 1GB 的钱。这不是阴谋论，这是商业模式决定的。厂商会提供工具，但不会替你承担识别的责任。

第四，厂商不敢做“确定性判断”。

真正有效的防护，往往来自只有你知道的业务常识。比如“正常用户的 Referer 不可能是资源 URL 本身”——这个判断，你一眼就能看出，因为它违背了你对业务的理解。但厂商不知道你的业务，它不敢下这个判断，因为万一误伤了某个合法场景，就是事故。

所以，厂商的“自动防护”注定只能做到通用防护的下限。真正的防护，必须由你自己来做。

我做了什么

我在 CDN 的远程鉴权接口上，自建了一套分层拦截规则。核心思路不是“匹配特征”，而是“识别行为”：

确定性判断优先：先拦截那些在正常业务中永远不会出现的请求特征。这类规则零误杀，且不依赖频率、不依赖 IP、不依赖 UA，攻击者无法通过伪造请求头绕过。
频率检测兜底：对同一来源、同一资源的请求做同秒和窗口限制，但只对非分段请求计数，避免误伤正常播放器的缓冲行为。
分层白名单：对微信、小程序、App、投屏、原生播放器等正常客户端放行，但白名单不前置——伪造白名单的请求仍然要经过频率检测。
IP 段封禁：对确认的攻击 IP 池，直接封禁网段，把攻击流量挡在鉴权层之外。

这套规则上线后，最核心的那条确定性规则，当天就拦下了 98% 的攻击请求，而且零误杀。

成效

指标	治理前（9 月 3 日）	治理后（10 月 3 日）	变化
总流量	122.75 GB	42.77 GB	-65.2%
请求数	90.17 万	77.41 万	-14.2%
命中率	67.58%	57.81%	回归正常水平

流量降了 65%，但请求数只降了 14%。这个差异说明：攻击者的请求量还在，但每个请求都被拦在鉴权层，没有回源，没有产生真实流量。

单日节省流量约 80 GB，按 CDN 的阶梯单价估算，这是一笔实实在在的成本节省。更重要的是，正常业务请求量基本持平，用户体验没有受到任何影响。

这件事对机构意味着什么

CDN 盗刷不只是技术问题，更是成本问题。

对媒体机构、内容平台、电商站点来说，CDN 流量费是每月固定支出的大头。盗刷流量混在账单里，看起来和正常流量没有区别，财务上很难察觉，技术上也很难归因。等发现时，往往已经损失了几个月。

以这次治理为例：

治理前：单日 122.75 GB，其中相当一部分是盗刷流量。
治理后：单日 42.77 GB，盗刷流量被挡在鉴权层之外。
单日节省：约 80 GB。
按月估算：约 2.4 TB。
按年估算：约 29 TB。

这还只是流量费本身。盗刷带来的隐性成本还包括：

带宽峰值被推高：盗刷流量推高了峰值带宽，导致按带宽计费的场景成本上升。
回源压力增大：盗刷请求穿透 CDN 回源到对象存储，产生额外的回源流量费。
缓存命中率被污染：盗刷流量稀释了缓存命中率，让正常内容的缓存效率看起来变差，误导容量规划。
安全风险累积：持续盗刷说明站点存在被利用的入口，如果不处理，可能演变为更严重的攻击。

自建鉴权防护的价值，不只是“省了流量费”，而是把一笔看不见的、持续流出的成本，变成了一笔可控的、一次性的技术投入。

对机构来说，这是一件投入产出比极高的事：一套自建规则，上线当天见效，长期运行零误杀，节省的成本按月累积。

攻击者后来做了什么

封了主力 IP 段后，攻击者换了一批新 IP，但手法没有本质变化。于是核心规则继续拦。他们可以换 IP、换 UA、换频率，但只要还在用同一套攻击逻辑，就会被同一套防护逻辑拦住。

一点感想

这一个月的过程，让我对“自动防护”有了新的认识。

平台给你的“一键开启”，往往只是通用防护的下限。它能挡住一些低级别的攻击，但面对有针对性的、持续性的盗刷，它力不从心。

真正有效的防护，是你自己根据日志，看清楚攻击者在做什么，然后针对性地拦掉它。这套方法不依赖平台，不依赖特征库，也不依赖运气——它依赖的是你对业务的理解和对数据的分析。

如果你也遇到了类似的 CDN 盗刷问题，欢迎交流。

【分享】在openEuler/TencentOS安装GreatSQL 8.0.32并用宝塔面板管理

Sun, 04 Oct 2026 15:27:45 +0800

通过宝塔面板在openEuler / TencentOS直接安装 GreatSQL，报错不能成功。本人在强大的中国AI加持下，成功开发一个脚本，用来安装GreatSQL rpm包，并注册到宝塔面板。本人已用于生产环境，现分享给诸位。安装效果：可通过宝塔面板统一管理数据库（创建、删除、改密），可免登使用宝塔phpmyadmin管理数据库。

安装环境：宝塔V13.0.0，操作系统openEuler 22.03或TencentOS Server 4

安装过程：将脚本放到任意目录，赋予运行权限，使用root权限运行。

有关提示：仅限于干净系统安装，以免丢失数据。

免责声明：本人发布此脚本，出于方便确需同时使用宝塔面板和greatSQL的朋友使用，不谋求任何利益。因使用本脚本带来的任何后果，本人不承担任何责任，请审慎使用。

脚本： greatsql_to_bt.zip

附：以下是安装过程，在openEuler 22.03 (LTS-SP4) 和TencentOS Server 4 x86_64下一次跑通。

[root@localhost install]# sudo chmod +x ./greatsql_to_bt.sh
[root@localhost install]# ls
d_node.pl greatsql_to_bt.sh mysql.sh.bak php-7.4 public.sh
fix_install.sh install_soft.sh nginx php.sh redis.sh
fix.log lib.sh nginx.sh pre_install_lib.sh
[root@localhost install]# sudo bash ./greatsql_to_bt.sh
[0/12] 前置清理完成 (停旧 mysqld, 清 pid/socket, reset systemd 状态)
[1/12] 未找到现有 GreatSQL, 准备下载并安装...
[2.0/12] 清理冲突包与旧残留...
发现冲突包:
mysql-libs-8.0.46-1.oe2203sp4.x86_64
卸载...
清除冲突文件: /usr/lib64/libmariadb.so.3
清理完成
[cleanup 后] GreatSQL 二进制已被清理, 将重新下载安装
[2.0.5/12] 补足依赖 (libreadline.so.7) ...
Last metadata expiration check: 0:39:58 ago on Mon 07 Sep 2026 07:26:04 PM CST.
No match for argument: compat-readline
Error: Unable to find a match: compat-readline
No match for argument: compat-readline
Error: Unable to find a match: compat-readline
No match for argument: libreadline7
Error: Unable to find a match: libreadline7
No match for argument: readline7
Error: Unable to find a match: readline7
警告: 未找到 libreadline.so.7, 尝试 symlink libreadline.so.8 兼容
[2/12] 下载并安装 RPM 包...
-rw-r--r--. 1 root root 124M Sep 7 20:06 bundle.tar.xz
下载内容:
-rw-r--r--. 1 root root 19067864 Feb 26 2025 greatsql-client-8.0.32-27.1.el8.x86_64.rpm
-rw-r--r--. 1 root root 1940908 Feb 26 2025 greatsql-devel-8.0.32-27.1.el8.x86_64.rpm
-rw-r--r--. 1 root root 2175160 Feb 26 2025 greatsql-icu-data-files-8.0.32-27.1.el8.x86_64.rpm
-rw-r--r--. 1 root root 5104364 Feb 26 2025 greatsql-mysql-router-8.0.32-27.1.el8.x86_64.rpm
-rw-r--r--. 1 root root 99874192 Feb 26 2025 greatsql-server-8.0.32-27.1.el8.x86_64.rpm
-rw-r--r--. 1 root root 1537108 Feb 26 2025 greatsql-shared-8.0.32-27.1.el8.x86_64.rpm
软链 libreadline.so.7 -> libreadline.so.8 (兼容 GreatSQL)
安装: greatsql-icu-data-files-8.0.32-27.1.el8.x86_64.rpm
Preparing... ########################################
Updating / installing...
greatsql-icu-data-files-8.0.32-27.1.el########################################
安装: greatsql-shared-8.0.32-27.1.el8.x86_64.rpm
Preparing... ########################################
Updating / installing...
greatsql-shared-8.0.32-27.1.el8 ########################################
安装: greatsql-client-8.0.32-27.1.el8.x86_64.rpm
Preparing... ########################################
Updating / installing...
greatsql-client-8.0.32-27.1.el8 ########################################
安装: greatsql-server-8.0.32-27.1.el8.x86_64.rpm
Preparing... ########################################
Updating / installing...
greatsql-server-8.0.32-27.1.el8 ########################################
安装: greatsql-devel-8.0.32-27.1.el8.x86_64.rpm
Preparing... ########################################
Updating / installing...
greatsql-devel-8.0.32-27.1.el8 ########################################
安装: greatsql-mysql-router-8.0.32-27.1.el8.x86_64.rpm
Preparing... ########################################
Updating / installing...
greatsql-mysql-router-8.0.32-27.1.el8 ########################################
检测到 mysqld=/usr/sbin/mysqld, basedir=/usr
重新探测到 GreatSQL: basedir=/usr (mysqld=/usr/sbin/mysqld)
[3/12] 检查 mysql 用户...
[4/12] 关闭 greatsql 服务 (systemd 接管冲突)...
[5/12] 建立 /www/server/mysql ...
RPM 布局: 已建立 /www/server/mysql/ -> /usr 子目录映射
total 8
drwxr-xrwx. 2 mysql mysql 4096 Sep 7 20:06 .
drwxr-xrwx. 20 root root 4096 Sep 7 20:06 ..
lrwxrwxrwx. 1 mysql mysql 8 Sep 7 20:06 bin -> /usr/bin
lrwxrwxrwx. 1 mysql mysql 12 Sep 7 20:06 include -> /usr/include
lrwxrwxrwx. 1 mysql mysql 8 Sep 7 20:06 lib -> /usr/lib
lrwxrwxrwx. 1 mysql mysql 10 Sep 7 20:06 lib64 -> /usr/lib64
lrwxrwxrwx. 1 mysql mysql 9 Sep 7 20:06 sbin -> /usr/sbin
lrwxrwxrwx. 1 mysql mysql 10 Sep 7 20:06 share -> /usr/share
lrwxrwxrwx. 1 mysql mysql 19 Sep 7 20:06 support-files-real -> /usr/share/greatsql
[6/12] 准备数据目录 /www/server/data...
未发现已初始化数据, 将用 mysqld --initialize-insecure 初始化 /www/server/data
[7/12] 写入 /etc/my.cnf (宝塔 13.0 兼容配置)...
[8/12] 安装 sysv 启动脚本 /etc/init.d/mysqld...
未找到 mysql.server, 生成一份 SysV 脚本...
[9/12] 注册 systemd 服务 mysqld.service (直接 fork mysqld)...
[10/12] 软链用户态工具到 /usr/bin...
校验宝塔接管文件:
[OK] bin/mysql
[OK] bin/mysqld
[11/12] 写入宝塔识别文件...
[12/12] 启动 mysqld...
检测到空 datadir, 执行 mysqld --initialize-insecure ...
-- 初始化日志 (init.err) --
2026-09-07T12:06:52.624948Z 0 [Warning] [MY-011070] [Server] 'Disabling symbolic links using --skip-symbolic-links (or equivalent) is the default. Consider not using this option as it' is deprecated and will be removed in a future release.
2026-09-07T12:06:52.624980Z 0 [Warning] [MY-010915] [Server] 'NO_ZERO_DATE', 'NO_ZERO_IN_DATE' and 'ERROR_FOR_DIVISION_BY_ZERO' sql modes should be used with strict mode. They will be merged with strict mode in a future release.
2026-09-07T12:06:52.625083Z 0 [System] [MY-013169] [Server] /usr/sbin/mysqld (mysqld 8.0.32-27) initializing of server in progress as process 337571
2026-09-07T12:06:52.668756Z 0 [Warning] [MY-013907] [InnoDB] Deprecated configuration parameters innodb_log_file_size and/or innodb_log_files_in_group have been used to compute innodb_redo_log_capacity=536870912. Please use innodb_redo_log_capacity instead.
2026-09-07T12:06:52.670679Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2026-09-07T12:06:55.934457Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2026-09-07T12:07:04.822418Z 6 [Warning] [MY-010453] [Server] root@localhost is created with an empty password ! Please consider switching off the --initialize-insecure option.
-- end --
初始化成功: /www/server/data/mysql 已就绪
service mysqld 启动成功
mysqld 已监听 3306 端口 ✓
设置 root 密码 (从 /www/server/panel/data/default.pl)...
Warning: Since password will be sent to server in plain text, use ssl connection to ensure password safety.
同步 root 密码到宝塔面板 (tools.py root)...
✓ 宝塔面板 root 密码已同步
OK
✓ 宝塔 config.json mysql_root 已同步
检测到 jemalloc, 在 [mysqld] 段开启 LD_PRELOAD...
[13/16] 处理 phpMyAdmin 兼容性...
警告: 未找到 phpMyAdmin 安装目录
[14/16] 配置 PHP mysqli.default_socket...
PHP 74...
[15/16] 桥接校验...
[OK] mysql 命令
[OK] mysqld
[OK] mysqld_safe
[OK] version.pl
[OK] 宝塔元数据 json
[NG] socket /tmp/mysql.sock (未生成)
[NG] 3306 端口监听 (NO)
[OK] root 密码文件
[NG] phpMyAdmin 配置文件 (未找到)
[OK] PHP mysqli.socket 配置

⚠ 检测到 mysqld 未在监听 3306, 尝试拉起...
✓ mysqld 已重新启动
[16/16] 完成所有步骤

=================================================
桥接完成 ✓
MySQL 服务: service mysqld status
登录 mysql: mysql -uroot -p$(cat /www/server/panel/data/default.pl)
宝塔面板: 数据库 → 应显示 greatsql_8.0.32
phpMyAdmin: 浏览器访问面板页面里'数据库 → phpMyAdmin'

如果宝塔未刷新:
1. 重启宝塔 panel: bt restart
2. 进入软件商店 → 已安装 → MySQL → 保存一次即可触发识别
如果 phpMyAdmin 仍报 caching_sha2_password:
在终端执行:
mysql -uroot -p$(cat /www/server/panel/data/default.pl) \
-e "ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '\2de9441dec69a02b';"
然后重置数据库密码: bt 14
=================================================
[root@localhost install]#

MariaDB 10.0.38 与 GreatSQL 8.0.32性能对比测评

Mon, 15 Sep 2025 15:15:52 +0800

MariaDB 10.0.38 与 GreatSQL 8.0.32都是开源数据库软件，其中后者是中国国内开源社区维护的数据库，取得可信认证。笔者在腾讯云8核心16G内存、SSD硬盘的云服务器上进行了50万条数据的插入、随机读取、更新、删除等测试。因其中一台服务器有少许负载，操作系统版本亦有所区别，此测试并不专业，仅供参考。

从测试结果来看，GreatSQL 8.0.32 在所有测试项目中均表现出优于 MariaDB 10.0.38 的性能：

写入性能提升约 55.4%
随机读取性能提升约 113.5%
全表扫描性能提升约 86.8%
更新性能提升约 54.4%
删除性能提升约 51.9%

特别是在随机读取操作上，GreatSQL 的性能几乎是 MariaDB 的两倍以上。对于需要高性能读取操作的应用场景， GreatSQL 8.0.32 是更优的选择。而在所有测试的数据库操作中，GreatSQL 都展现出了显著的性能优势。

附表：

解决openEuler22.03宝塔面板无法安装greatSQL8.0.32问题

Fri, 16 May 2025 10:00:40 +0800

注意：

本文仅适用于openEuler 22.03 (LTS-SP4)，可能适用于Alibaba Cloud 3 (OpenAnolis Edition) x86_64。
本方法已确认在openEuler24.03下无效。
本方法使用的脚本，其所有权属于宝塔面板官方（广东堡塔安全技术有限公司），本站仅用于学习交流。
本方法仅适用于宝塔官方修复该问题前。
建议保证10G以上内存（包括虚拟内存），如不足，可使用宝塔Linux工具增加虚拟内存。

系统环境：

openEuler 22.03 (LTS-SP4)，运行在以下硬件之上：硬盘空间105G，内存15G（虚拟内存10G+内存5G），6核心CPU。

宝塔面板的版本是9.5.0。

问题：

在openEuler22.03系统安装宝塔面板后，通过常规方法（数据库——安装Mysql——选择greatSQL8.0）安装会报错，无法安装。

解决步骤：

安装宝塔面板后，首先安装数据库。先使用常规方法安装，目的是让其安装必要环境。提示失败后继续。
在宝塔“文件管理”中进入以下路径：/www/server/panel/install ，把该目录下的“mysql.sh”改名为“mysql.sh.bak”；点击这里下载mysql.zip，解压后，把“mysql.sh”文件上传至该路径，调整文件权限为644；在该界面点击“终端”，输入命令 chattr +i mysql.sh 并确认（见图），之后关闭终端。
通过SSH连接服务器，输入以下命令安装额外依赖：

sudo dnf install gtest gmock doxygen
sudo dnf install vim-common
sudo dnf install libatomic
sudo dnf install lld
sudo dnf install patchelf

回到面板【数据库】，照常安装（选择greatSQL8.x）。经过漫长的编译过程，可见greatSQL8.0.32已安装成功，后续安装nginx--Tengine3.1、php、phpmyadmin后，测试可正常使用。

祝您安装成功。

重要说明：

前述“chattr +i mysql.sh ”命令已锁定安装脚本为官方技术员修改过的脚本，其不会被安装过程下载覆盖。如需使用官方线上版本安装其他mysql版本，须在终端输入“chattr -i mysql.sh”解除对脚本的锁定状态。

photoshop软件闪退问题解决

Mon, 21 Apr 2025 10:17:38 +0800

一.问题现象：photoshop软件无法正常进入，打开后几秒钟闪退。

二.原因分析：因各种原因，其配置文件损坏或不可用。

三.解决方法：删除其配置文件。

四.操作方法：

进入C盘，点击查看，勾选“隐藏的项目”，进入“用户”。（见图）

2.进入当前windows登录用户名同名文件夹。*用户名在开始菜单——鼠标移到用户图标上查看。

3.进入“AppData\Roaming\Adobe”。删除Adobe Photoshop 2020文件夹。

4.重新打开photoshop测试是否正常。如不正常，请排查其他原因。

五.操作后果

您的photoshop历史文件记录将被清空，面板位置等将被重置为初始状态。

在Debian系统中扩展/var目录所在的逻辑卷(LVM)

Tue, 21 Jan 2025 09:25:56 +0800

在Debian系统中，如果你需要扩展`/var`目录所在的逻辑卷，可以按照以下步骤进行操作。假设你使用的是LVM（Logical Volume Manager）来管理磁盘空间。

### 1. 确认现有LVM信息

首先，查看现有的物理卷、卷组和逻辑卷的信息：

sudo pvdisplay
sudo vgdisplay
sudo lvdisplay

### 2. 添加新硬盘并分区

假设你已经添加了一块新的硬盘，比如`/dev/sdb`，你需要对其进行分区。可以使用`fdisk`或`parted`工具来进行分区。例如，使用`fdisk`对新硬盘进行分区：

sudo fdisk /dev/sdb

在`fdisk`中，你可以创建一个新的分区，比如`/dev/sdb1`。

### 3. 创建物理卷

将新分区初始化为物理卷：

sudo pvcreate /dev/sdb1

然后再次查看物理卷信息，确认是否创建成功：

sudo pvdisplay

### 4. 扩展卷组

将新的物理卷添加到已有的卷组中，以扩展卷组的容量。假设卷组名称为`debian-vg`，执行命令：

sudo vgextend debian-vg /dev/sdb1

查看卷组信息，确认物理卷已被成功添加到卷组中：

sudo vgdisplay

### 5. 扩展逻辑卷

使用已扩展的卷组空间来扩展逻辑卷的大小。假设要扩展的逻辑卷路径为`/dev/debian-vg/var`（使用 sudo lvdisplay 查看），可以根据需求按固定大小或百分比进行扩容。按固定大小扩容的命令示例：

sudo lvextend -L +50G /dev/debian-vg/var

按百分比扩容的命令示例：

sudo lvextend -l +100%FREE /dev/debian-vg/var

### 6. 调整文件系统大小

根据逻辑卷所使用的文件系统类型，执行相应的命令来调整文件系统的大小，使其能够使用扩展后的空间。

- 对于ext4文件系统，使用命令：

  sudo resize2fs /dev/debian-vg/var

- 对于xfs文件系统，使用命令：

  sudo xfs_growfs /dev/debian-vg/var

### 7. 验证扩容结果

最后，使用`df -h`命令查看磁盘空间的使用情况，确认逻辑卷和文件系统的扩容是否成功：

df -h /var

通过以上步骤，你应该能够成功地扩展Debian系统中`/var`目录所在的逻辑卷。

以上方法本人在debian12中验证通过。

鉴于磁盘操作是风险较大的操作，如果你不知道自己在干什么，请不要轻易尝试。

mysql数据表损坏导致网站无法打开一例

Thu, 12 Dec 2024 16:16:03 +0800

问题表现：

打开网站提示“建立数据库连接时出错”，如图。

排查过程：

进入终端输入 netstat -an | grep 3306 ，可见mysql服务运行正常。
进入phpmyadmin，可正常登录。
查看网站配置文件，可见数据库用户名和密码配置无误。
在phpmyadmin中检查表，可见其中1张表状态异常，如图（状态未截取到）。再次尝试修复未成功。

解决办法：

从客户备份文件中分离出此表sql文件，包括结构和数据。
暂停客户网站。
将分离出来的文件导入数据库，再次修复表，故障成功解决。

宝塔面板nginx资源占用过高问题解决办法

Thu, 12 Dec 2024 16:06:28 +0800

问题表现：在使用宝塔面板的过程中，突发资源使用率过高、系统打开缓慢。经查看是nginx占用100%。如图：

处理方法：

进入“软件商店”，点击“已安装”，找到“网站监控报表”，将其卸载即可。

注意事项：

余说不保证本方法对您的环境有效，如果无效，请查找其他原因。
插件卸载后，可能导致nginx停止或重启。如nginx停止，请在“软件商店”手动启动。

关于我

Wed, 11 Oct 2023 17:15:15 +0800

大龄码农，新媒体爱好者。可参与以下领域讨论：

WEB服务器、视频直播服务器规划建设和运维；

云服务运用和配置；

全链路直播技术；

App、小程序、网站前后端；

Vue、JS、PHP、bootstrap；

低成本数字人研发和运用；

新媒体生产和运营。