老王日记

OpenShell

Sun, 25 Oct 2026 17:24:03 +0800

OpenShell

给 AI agent 干活，最难的不是让它能干，而是让它只能干你允许它干的事。NVIDIA 的 OpenShell 就是冲着这个来的：一个给成群自主 agent 用的、安全又私有的运行时。你在策略里声明每个 agent 能碰什么，它负责在运行时强制执行，而不是事后看日志追悔。

这篇文章不复述 README，重点说它跟普通沙箱到底差在哪、适合谁、以及你第一次上手最容易踩的坑。

一、为什么值得关注：它把“信任”从口头变成强制

很多 agent 沙箱的逻辑是“先给权限，出事再收”。OpenShell 反过来：每个 agent 都跑在隔离沙箱里，内核层控制它能访问哪些文件、能做哪些系统调用，每一次联网都要先过策略检查才放行。这不是应用层的过滤，而是在更底层卡住，agent 绕不过去。

更关键的是第二层：策略改动不是改完就生效。改动前，它会用形式化验证先算一遍这个改动会新放开什么，比如能不能带着密钥去一个新主机、能不能调一个新 API 方法，算出高风险就先留给人审批。这一步很对安全团队的胃口，因为 agent 时代最大的风险往往不是 agent 本身，而是某次“顺手放宽一点”的策略改动。

二、它怎么跑：网关、监管器、沙箱三件套

架构上可以理解成三件套：网关是控制面，管沙箱、策略和访问；监管器盯着运行时的 agent；沙箱是 agent 真正干活的地方。默认沙箱镜像是一个最小的 Ubuntu，里面根本没装 agent，这一点第一次用的人很容易懵：装完以为就能跑 agent，其实还要按“跑第一个 agent”的指引去接一个真实 agent，比如用 OpenCode 配一个免费的 OpenRouter 模型。

安装本身是一条命令加一个建沙箱的命令，但前提要先满足：Linux、苹果芯片的 Mac，或者 Windows 加 WSL 2（还是实验性的），外加 Docker、Podman 或者主机虚拟化。没有这些，装完也跑不起来。

三、适合谁，不适合谁

适合三类人。第一类，已经在跑不止一个 agent、而且要给 agent 文件、装包、调 API、用密钥权限的团队和个人，越是 agent 多、权限杂，这个工具的价值越大。第二类，对数据和密钥外泄特别敏感的人：agent 在这里永远看不到真密钥，密钥只由 OpenShell 加到发往已批准 endpoint 的请求上。第三类，想把 agent 接进自己应用的开发者：它有 Python、TypeScript、Go、Rust 的 SDK，接网关用，但要注意 SDK 和网关尽量用同一个版本。

不适合两类人。一类是只想跟单个 agent 聊聊天、写写代码的人，这个工具的策略、网关、审批流程对他来说太重了。另一类是希望 agent 完全自主、不要人审批的人：OpenShell 的设计就是要在高风险改动前停下来等人看，追求“全自动不打扰”和追求“不出事”在这里是冲突的。

四、上手体验和坑：先把这四条看完再装

第一，别用 curl 管道直接装完就信。README 给的是一条 curl 安装脚本，先看一眼脚本里到底装了什么、装到哪，再跑，这是装任何这类工具都该有的习惯。

第二，策略要从小写起。先给 agent 最小的权限，跑起来、看它在哪些地方被拦、再按需放开，而不是一开始就给一个宽策略图省事。放宽策略的每一次改动都会先被验证器标出来，这正是这个工具想让你慢下来的地方。

第三，遥测默认是开着的。它说只收集匿名的运行类别和数量，不收集沙箱名、主机名、文件路径、提示词、密钥、模型名和用户内容，但如果你在意，还是要在网关上把 OPENSHELL_TELEMETRY_ENABLED 设为 false，或者 Helm 安装里把 server.telemetryEnabled 设为 false，也可以直接编译掉。

第四，版本还早。0.1.x 刚进入稳定发布节奏，改动和升级指引要跟上，别把生产 agent 群直接绑在一个还在快速演进的版本上，先在测试沙箱里跑通你的策略和审批流程。

五、怎么试，第一次这样试最划算

先在 Linux 或苹果芯片 Mac 上装好，建一个叫 demo 的沙箱，然后按官方指引跑第一个 agent，重点不是看 agent 能写出什么代码，而是看三件事：它第一次想访问没批准的东西时是不是真的被拦住；你放宽策略时，验证器是不是真的标出了新风险；密钥是不是真的没有出现在 agent 能看到的地方。

这三件事都通过了，这个工具在你手里才算立住了。我的判断是：它值得关注，不是因为 NVIDIA 背书，而是因为它把 agent 安全里最难的一步——“给 agent 能力，但不给它失控的自由”——做成了可强制执行的运行时，而不是一份使用规范。

https://github.com/NVIDIA/OpenShell

GitHub 项目：security-audit-skill——让 AI 审计先学会别瞎报

Sat, 24 Oct 2026 23:40:59 +0800

解读 GitHub 项目：security-audit-skill——让 AI 审计先学会别瞎报

工作台今日候选里排第一的，是 Cloudflare 的 security-audit-skill。它不是又一个“让 AI 帮你看代码”的提示词合集，而是一个给 coding agent 用的审计技能：把一次安全审计拆成固定流程跑完，最后只认有证据的结论。

这篇文章不复述 README，重点说三件事：它跟普通 AI 代码评审到底差在哪、适合谁上手、以及你第一次跑最容易踩的坑。

一、为什么值得关注：它治的是 AI 审计最常见的毛病

普通 agent 做代码评审，常见毛病不是找得少，而是报得多、证据少。一段看着可疑的代码，它能讲出一套很像那么回事的攻击链，但你顺着源码一查，发现前提根本不成立。修这种“假漏洞”比不修更浪费时间，还会把真正的风险淹没。

这个技能的核心设计，就是把“找”和“验”分给不同的人。找漏洞的 agent 不能自己给自己盖章，验证的 agent 必须想办法证伪它。证伪不了、证据链完整的，才进 confirmed；证据不完整、还差一个关键事实的，不给严重程度，只记成 needs_validation；被证伪的，记成 rejected，并且留着记录。

这个区分比结论本身更重要。对做审计的人来说，最怕的不是漏报一个低危问题，而是把“还没搞清楚”当成“已经确认”，然后按严重程度排期去修。

二、它怎么跑：六个阶段，其实就三句话

流程说起来是六个阶段，理解起来可以压成三句话。第一句，先画地图：侦察阶段把架构、可信边界、输入面和已有的覆盖情况写成 architecture.md 和 coverage-ledger.json，后面所有工作都对照这张地图查缺补漏，而不是想到哪查到哪。

第二句，分头找、分头验：按覆盖清单派不同的猎手去查，覆盖评审员专门找没覆盖到的地方；每个候选漏洞都交给一个全新的验证者去证伪。第三句，只从已验证的记录生成报告，报告不是 agent 现场发挥写出来的，而是从 findings.json 和覆盖清单里推导出来的。

多次跑同一个仓库，结果是累加的：它会用以前的清单和结论去盯改动过的地方、重新验证变了的源码，而不是把旧结论当成已覆盖。这个设计很对审计的胃口，因为代码审计本来就不是一次性工作。

三、适合谁，不适合谁

适合三类人。第一类，自己维护一个有一定规模的代码库，想定期跑一次结构化审计，但请不起外部审计团队的人。第二类，团队里已经在用 Claude Code、Codex 这类支持并行子 agent 的工具，想把“AI 评审”从聊天变成可复查流程的人。第三类，想学习安全审计方法论的人：它自带的攻击面清单覆盖 Web、客户端、供应链、云和部署、协议、资源耗尽、数据隔离这些方向，照着清单走一遍，比零散看漏洞文章系统得多。

不适合两类人。一类是只想快速扫一遍、马上要一份漏洞列表交差的人，这个流程本来就慢，而且故意不给你“看起来很严重但没证据”的结论。另一类是完全没有安全基础、希望 agent 直接告诉你“修这里就行”的人：它给的是证据和待验证项，最终判断还是要人做。

四、上手体验和坑：先把这四条看完再跑

安装本身不难，用 Skills CLI 装好技能，在代码库里对 agent 说一句“security audit this codebase”就能触发。真正的坑在运行条件上。

第一，沙箱是硬要求。README 明确要求一个操作系统级沙箱：跑目标代码、测试、浏览器、模糊测试这些动作时必须断外网、环境白名单、资源受限、只写指定的临时目录。没有这个沙箱，流程不会替你冒险执行目标代码，相关线索会一直停留在 needs_validation。你以为是审计没跑完，其实是它在等一个安全的执行环境。

第二，成本和时间要按“多次跑”来算。官方自己的测试里，单次跑找到的漏洞大约只有多次跑总和的一半左右。这意味着只跑一次就下结论，很可能漏掉一半；但多次跑也意味着 token 和时间成倍涨。第一次试，建议先拿一个自己熟悉的小仓库跑，别直接上生产大仓。

第三，别把输出目录搞错。完整审计模式下，默认输出在 ~/security-audit-skill/<仓库名>/run-<编号>，只有当你明确选了一个版本控制忽略的目录时，它才会在目标仓库里写东西。跑之前先确认输出落在哪，别事后才发现审计产物混进了提交里。

第四，验证脚本别跳过。它自带两个零依赖的 Node 验证器，分别校验覆盖清单和 findings.json，流程里会在关键阶段跑它们。如果你手动改了结论文件，跑一下验证器比肉眼检查靠谱。

五、怎么试，第一次这样试最划算

先装技能，再找一个你自己写过、规模不大的项目，对 agent 说做一次安全审计。跑完先别看报告正文，先看 findings.json 里三类结论各有多少：如果 confirmed 很少、needs_validation 一大堆，问题大概率出在沙箱或执行条件上，而不是代码真的很干净。

然后挑一个 confirmed 结论，顺着它的源码追踪自己复现一遍；再挑一个 needs_validation，看看它到底卡在哪一个没确认的事实上。这个过程走完，你就知道这个技能在你手里是“能用的审计流程”，还是“又一个报得多、证据少的评审工具”。

我的判断是：它值得关注，不是因为 Cloudflare 背书，而是因为它把审计里最难的一步——“别轻信自己的发现”——做成了流程。AI 审计以后拼的不是谁找得多，而是谁的结论经得起复查，这个技能就是往那个方向走的。

项目地址：https://github.com/cloudflare/security-audit-skill

免费流量被爬虫刷爆：用 Nginx 444 精准拦截（附安全配置清单）

Thu, 22 Oct 2026 21:50:51 +0800

云服务器运维实战系列 · 第 7 篇（共 7 篇）

免费流量被爬虫刷爆：用 Nginx 444 精准拦截（附安全配置清单）

免费套餐的服务器，出站流量有额度，超了可能收费。我在面板上看到上行一直有流量、速度还不低，站点没几个人访问，数据却一直在往外发。查了 Nginx 日志，发现是大量 AI 训练爬虫和扫描器在反复抓页面、扫路径。

这篇讲怎么确认是谁在刷、怎么用 Nginx 的 444 状态码在连接层直接掐掉，以及顺手整理的一份安全配置。

第一步：确认流量是谁产生的

先看访问日志里都有哪些 User-Agent、哪些 IP 最活跃：

从访问日志统计活跃 IP 和 User-Agent。

BashBash# 统计访问最多的 IP
sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# 统计出现最多的 User-Agent
sudo awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

我看到大量请求来自这些公开的 AI/采集爬虫和扫描器（UA 里直接带名字）：

TextTextSemrushBot
meta-externalagent / meta-externalfetcher
ClaudeBot / anthropic
Bytespider
python-requests / Go-http-client / curl（扫描器常用）

它们有的反复抓整站，有的专扫 .env、wp-login、phpmyadmin 这类敏感路径。页面虽然小，但架不住请求量大，累计出站流量很可观。

第二步：为什么用 444，而不是 403

Nginx 有个非标准状态码 444（return 444）：它不返回任何 HTTP 响应，直接在 Nginx 这一端关闭连接。

命中规则后直接断开连接，不返回响应体。

对比：

403 Forbidden：仍然要走完响应，返回一个错误页，客户端还会继续换路径试；
444：连接直接断，不发响应体，不产生出站流量，对刷量的爬虫最省事。

第三步：按 User-Agent 拦截

在 http 块（通常放 /etc/nginx/conf.d/ 下的独立文件，或 nginx.conf 的 http 段）用 map 标记恶意 UA：

nginxnginx# 放在 http {} 内
map $http_user_agent $bad_bot {
    default 0;
    ~*SemrushBot             1;
    ~*meta-externalagent     1;
    ~*meta-externalfetcher   1;
    ~*ClaudeBot              1;
    ~*anthropic-ai           1;
    ~*Bytespider             1;
    ~*AhrefsBot              1;
    ~*MJ12bot                1;
    ~*DotBot                 1;
    ~*(python-requests|Go-http-client|libwww-perl) 1;
}

然后在需要保护的 server 块里拦截：

nginxnginxserver {
    listen 443 ssl;
    server_name 你的域名;

    # 命中恶意 UA 直接断连
    if ($bad_bot) {
        return 444;
    }

    # 其余正常配置 ...
}

注意：Nginx 配置里 if 在 location 内容易踩坑，但在 server 层做简单的 return 是安全的官方用法。改完先测试再重载：

Bash

sudo nginx -t && sudo systemctl reload nginx

UA 名单按自己日志里实际出现的补，~* 表示不区分大小写。如果你希望自己的内容被某些 AI 检索，就别把对应 Bot 加进去。

第四步：拦截敏感路径扫描

扫描器最爱探测的路径，也直接 444：

nginxnginxserver {
    # ...

    # 常见敏感文件 / 后台扫描
    location ~* /\.(env|git|htaccess|htpasswd) { return 444; }
    location ~* /(wp-login|wp-admin|xmlrpc\.php) { return 444; }
    location ~* /(phpmyadmin|pma|adminer) { return 444; }
    location ~* /(vendor|tmp|backup|config)\. { return 444; }
}

这里有个我实际踩过的点：location 的匹配顺序。Nginx 正则 location 按书写顺序匹配、第一个命中即停；如果请求在 server 层已被 rewrite 改写成别的 URI，再用 location 正则去拦原始路径可能拦不到。所以拦截规则要针对最终生效的 URI，或干脆在 server 层用 if ($bad_bot) 这种不受 rewrite 影响的方式处理 UA。

第五步：限速，兜底防刷

对没被直接拉黑、但请求过密的，做连接和请求限速：

限速处理未直接拦截的高频请求。

nginxnginx# http 块定义限速区
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=addrlimit:10m;

server {
    limit_req zone=general burst=20 nodelay;
    limit_conn addrlimit 20;
}

rate=10r/s 是平均每秒 10 个请求，burst=20 允许短时 20 个排队，正常访客无感，脚本狂刷会被挡。

验证效果

重载后，用被封的 UA 本机测试：

BashBash# 用恶意 UA 请求，应直接被断开（无响应）
curl -A "SemrushBot" -I https://你的域名/

# 正常 UA 请求，应返回 200/301
curl -A "Mozilla/5.0" -I https://你的域名/

再观察面板流量和 access.log，被拦的请求不再产生响应流量，上行明显回落。也可以统计日志里 444（若记录了的话）的数量确认命中。

顺手整理的安全清单

结合这次迁移，给服务器定的几条基础防护：

只开放必要端口，面板、数据库不直接暴露公网；数据库只监听 127.0.0.1；
phpMyAdmin 等管理工具不开公网，需要时通过 SSH 隧道或反代 + 访问限制进入；
SSH 换非默认端口、禁用密码登录改用密钥、限制 root 直接登录；
面板用强密码 + 安全入口，及时更新面板和插件；
Nginx 层拦恶意 UA、敏感路径，并做限速；
网站目录权限最小化，删掉不用的站点和默认页；
定期自动导出数据库、异地备份，备份文件不放在 web 可访问目录；
定期看一眼流量和日志，异常刷量早发现。

小结

防爬虫刷量的关键是先看日志、确认是谁，再在 Nginx 层处理：恶意 UA 和敏感路径用 return 444 直接断连、不产生流量，其余靠限速兜底。免费额度有限，与其等流量超了，不如在入口就把无意义的抓取掐掉。

甲骨云服务器运维实战系列——家里连不上云服务器：TCP 能连、SSH 一握手就断，是端口被拦了

Thu, 22 Oct 2026 20:53:56 +0800

云服务器运维实战系列 · 第 6 篇（共 7 篇）

家里连不上云服务器：TCP 能连、SSH 一握手就断，是端口被拦了

从家里连云服务器，会遇到一种很隐蔽的情况：网络看着是通的，端口也像开着，但 SSH 刚握手就被掐断，报 Connection closed、Connection reset，或者干脆超时。换手机热点却能正常连。

这篇记录怎么一步步确认问题出在端口、而不是服务器，以及怎么绕过去。

先分清是哪种"连不上"

不同报错指向不同环节，先对号入座：

现象	大致含义
`Connection refused`	网络通，但目标端口没有服务监听（服务没起 / 端口错）
`Connection timed out`	包发出去没回应，可能被防火墙静默丢弃
`Connection reset / closed`	连上了，但中途被设备主动掐断
能 TCP 连通，握手立刻断	典型的中间设备针对端口的干预

我遇到的是最后一种：SSH 客户端显示连接建立，紧接着 Connection closed by <IP> port 22，服务端没留下拒绝记录。

第一步：在服务器上确认服务和防火墙

先排除服务器自身问题。在能登录的通道（其他网络、面板终端、串口控制台）上检查：

先确认 sshd 监听、防火墙规则和本机连接。

BashBash# sshd 是否在跑、监听哪个端口
sudo ss -tlnp | grep -E ':22|:8443'

# 本机连自己，验证服务正常
ssh -p 22 用户名@127.0.0.1

再看本机防火墙是否放行（甲骨文镜像默认 iptables 有兜底 REJECT，需要显式放行）：

BashBashsudo iptables -L INPUT -n --line-numbers | grep -E '22|REJECT|DROP'
sudo ufw status

如果本机连 127.0.0.1 正常、防火墙也放行了 22，但外网就是连不上，问题基本不在服务器。

第二步：看服务端有没有你的连接记录

这是判断"封锁发生在哪一段"的关键。在家里反复连接的同时，看服务器日志：

服务端无连接记录，问题可能发生在到达 sshd 之前。

BashBashsudo tail -30 /var/log/auth.log | grep -E "Connection from|Failed|Accepted"

如果日志里完全没有你家里 IP 的连接记录，但客户端却显示"TCP 已连接"，说明连接在到达 sshd 之前就被中间设备处理掉了；
如果有记录并显示 Accepted，那是连上后又被断开，方向另查。

我这边：家里连接时服务端毫无记录，手机热点连接立刻有 Connection from 和 Accepted。说明问题出在家宽到服务器之间的链路，针对 22 端口。

第三步：用 TCP 探测验证端口可达性

区分"端口被拦"还是"整条线路不通"：

BashBash# 在家用机器上探测 22 端口
nc -vz <服务器IP> 22

# 对比探测一个确定开放的端口，如 443
nc -vz <服务器IP> 443

结果是：443 能通，22 要么超时、要么连上立刻被 reset。同一台服务器、同一个出口 IP，只有特定端口异常，这就是端口级封锁的特征——不是 IP 被封，而是 22 这个端口在家宽这条路上被设备干预了（家宽网络常见对 22 等端口做限制或干扰）。

对比同一线路的 22 与 443，判断是否端口级干预。

第四步：确认是不是 fail2ban / 连接数

也要排除服务器端把你"ban"了的可能：

BashBashsudo fail2ban-client status sshd 2>/dev/null || echo "无 fail2ban"
sudo ss -tnp | grep ":22" | grep -v LISTEN | wc -l
grep -E "MaxStartups|Port " /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf 2>/dev/null

如果 fail2ban 的封禁列表里有你家里的出口 IP，解封即可（sudo fail2ban-client set sshd unbanip <IP>）。我这边没有 fail2ban 记录，连接数也正常，排除。

怎么绕过

确认是家宽针对端口的限制后，有三条路，按方便程度排：

1. 给 SSH 换一个高位端口。 家宽通常只针对常见端口，换个不常见的端口往往就通了：

BashBash# 新增监听端口（保留22，确认新端口可用后再决定是否关22）
echo "Port 8443" | sudo tee -a /etc/ssh/sshd_config
sudo systemctl restart ssh

# 放行新端口：iptables 和 ufw 都要
sudo iptables -I INPUT -p tcp --dport 8443 -j ACCEPT
sudo ufw allow 8443/tcp 2>/dev/null || true

连接：ssh -p 8443 用户名@<IP>。

2. 走 443，用 Nginx 反代/SSL 隧道。 443 几乎不会被家宽拦（拦了所有 HTTPS 网站都受影响）。把 SSH 藏到 443，或用 Nginx 按 SNI/流量特征分流，是最稳的长期方案。我同时也用 443 反代面板，访问明显稳定。

3. 临时用手机热点 / 其他网络。 排查和应急很方便，也能用来反证是不是家宽的问题。

排查顺序小结

服务器上确认 sshd 正常、防火墙放行、本机可连；
连接时看 auth.log 有没有你的记录——没有，说明没到服务器；
nc 对比探测 22 和 443，只有 22 异常即端口级封锁；
排除 fail2ban、连接数、MaxStartups；
换高位端口，或走 443 反代，应急用热点。

判断要点就一条：同一条线路、同一台机器，别的端口通、只有某个端口不通，问题就不在你的服务器，而在中间网络对该端口的处理。

ARM 服务器编译 PHP 报 file in wrong format：是依赖库的架构错了

Thu, 22 Oct 2026 20:50:56 +0800

云服务器运维实战系列 · 第 5 篇（共 7 篇）

ARM 服务器编译 PHP 报 file in wrong format：是依赖库的架构错了

在 ARM 服务器上用宝塔编译 PHP 8.2，前面编译都正常，到最后链接阶段突然失败：

TextText/bin/ld: /usr/local/curl_2/lib/libcurl.so: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
make: *** [Makefile:308: sapi/cli/php] Error 1
========================================================
ERROR: php-8.2.33 install failed.

file in wrong format 这个报错看着吓人，其实意思很直接：链接器拿到的某个库，架构跟当前机器对不上。这篇讲怎么定位是哪个库、为什么会这样。

报错在说什么

PHP 编译分两步：先把一个个源文件编译成 .o 目标文件，再由链接器 ld 把这些目标文件和各种依赖库（curl、openssl、ICU 等）拼到一起，生成最终的 php 可执行文件。

报错发生在链接阶段，点名了 /usr/local/curl_2/lib/libcurl.so。error adding symbols: file in wrong format 表示这个库的二进制格式不对——在 aarch64 机器上，大概率是这个库其实是 x86_64 的，链接器没法把 x86 的代码拼进 ARM 的程序。

x86 依赖库无法链接进 ARM 程序。

第一步：确认库的架构

用 file 直接看这个库：

沿着报错路径检查依赖库的实际架构。

Bash

file /usr/local/curl_2/lib/libcurl.so

如果输出里写 x86-64，而机器是 aarch64，问题就坐实了：

Bash

uname -m   # aarch64

一个 x86 的库出现在 ARM 机器上，通常是这么来的：

以前某次安装，下载/解压了错误架构的预编译包（和面板在 ARM 上拿不到正确包、回退逻辑混乱有关）；
手动装依赖时，从 x86 的来源拷了一份；
旧系统残留的目录没清干净，编译脚本按路径找到了它。

我这台机器上 /usr/local/curl_2/ 就是一份架构不对的 curl，PHP 配置时把它的 lib 路径加进了链接搜索路径，于是链接到了错误的库。

第二步：看程序到底链接了哪些库

ldd 能列出一个可执行文件（或库）依赖的所有动态库及路径：

BashBash# 看已经编出的 php（如果有）依赖了什么
ldd /www/server/php/82/bin/php

# 只看 curl / icu / sodium 相关
ldd /www/server/php/82/bin/php | grep -E 'curl|icu|sodium'

# 看有没有找不到的库
ldd /www/server/php/82/bin/php | grep 'not found'

编译中途失败、还没有最终 php 时，可以直接对那个出问题的库做检查，并全盘搜一下有没有多个同名库：

BashBash# 全盘找 libcurl，看各自路径
find / -name "libcurl.so*" 2>/dev/null

# 逐个 file 看架构
find / -name "libcurl.so*" 2>/dev/null -exec file {} \;

这样能把"正确的 ARM 库在哪、错误的 x86 库在哪"都列出来。

第三步：清掉错误的库，让它用正确的

思路是让链接器找到 aarch64 的库，而不是那份 x86 的。

1. 删除或移走错误架构的目录（确认没用后）：

BashBash# 例：这份 curl 架构不对、也没被其他服务需要
sudo rm -rf /usr/local/curl_2

2. 用 apt 装 ARM 原生的依赖，Ubuntu 源里的包一定匹配 aarch64：

换成 ARM 原生依赖，清缓存后重新编译。

BashBashsudo apt update
sudo apt install -y libcurl4-openssl-dev libssl-dev \
  libicu-dev libsodium-dev pkg-config

3. 清掉残留的半成品编译目录，重新编译。宝塔编译会在 PHP 版本目录留下缓存和 .o，不清可能继续引用旧路径：

Bash

sudo rm -rf /www/server/php/82

然后回到面板重新点"安装 PHP 8.2"，这次配置阶段通过 pkg-config 找到的是 apt 装的 ARM 库，链接就不会再报格式错误。

第四步：装好后验证

BashBash/www/server/php/82/bin/php -v
/www/server/php/82/bin/php -m | grep -E 'curl|intl|sodium'

# 确认链接的都是正常库、没有 not found
ldd /www/server/php/82/bin/php | grep 'not found'

最后一条没有输出，就说明所有依赖都正常解析了。

通用的判断方法

file in wrong format 这类问题不限于 PHP，任何在 ARM 上编译/运行的程序都可能遇到，判断套路相同：

uname -m 确认当前架构；
file <报错点名的库> 看它是什么架构；
ldd / find 把依赖和同名库都列出来对比；
删掉错误架构的库，用系统包管理器（apt/yum）装对应架构的原生库；
清编译缓存后重新编译。

核心就一句：编译器和链接器不会骗人，wrong format 九成是库的架构拿错了，顺着路径把那份错误架构的库揪出来即可。

MySQL 迁移的三个坑：ibdata1、lower_case_table_names、socket

Thu, 22 Oct 2026 17:32:02 +0800

云服务器运维实战系列 · 第 4 篇（共 7 篇）

MySQL 迁移的三个坑：ibdata1、lower_case_table_names、socket

迁数据库时，我一开始图省事，想直接把旧机器的 MySQL 数据目录整个拷到新机器，结果服务怎么都起不来。对着错误日志一条条查，最后栽在三个地方：表空间文件、一个大小写参数、还有 socket 路径。

这三个坑都不复杂，但每一个都会让 MySQL 在启动阶段直接退出。这篇把报错和解法记下来。

坑一：直接拷 ibdata1，表空间初始化失败

我最初的做法是停掉 MySQL，把旧的数据目录（含 ibdata1、mysql 库、各业务库目录）复制到新机器的 /var/lib/mysql，然后启动。错误日志立刻报：

复制物理数据目录，版本差异可能导致启动失败。

TextText[ERROR] [InnoDB] The Auto-extending innodb_system data file './ibdata1' is of a different
size ... than specified in the cnf file: initial 768 pages, max 0 ...
[ERROR] [InnoDB] Plugin initialization aborted with error Generic error.
[ERROR] [Server] Failed to initialize DD Storage Engine
[ERROR] [Server] Data Dictionary initialization failed.
[ERROR] [Server] Aborting

ibdata1 是 InnoDB 的系统表空间文件，里面有数据字典、change buffer 等关键信息。它的初始大小、页结构、内部记录的格式，跟 MySQL 版本、编译参数、配置强相关。我新旧两边 MySQL 小版本不同（一边 8.0.45、一边 8.0.46），文件对不上，InnoDB 读到的结构和它预期的不一致，直接拒绝初始化。

我一度想靠在配置里写 innodb_data_file_path = ibdata1:10M:autoextend 去对齐，但这个参数是初始化时定的，对一个已经存在、内容不匹配的文件没用，反而因为重定向写错位置（没加 sudo、文件落到了 /root）白折腾。

结论：物理拷贝数据目录这条路，跨版本、跨架构基本走不通。 正确做法是逻辑迁移（见文末）。

坑二：lower_case_table_names 必须初始化前定

解决了表空间，又冒出新报错：

新库初始化之前就要对齐表名大小写设置。

TextText[ERROR] [Server] Different lower_case_table_names settings for server ('0') and data dictionary ('1').
[ERROR] [Server] Data Dictionary initialization failed.

lower_case_table_names 控制库名、表名的大小写敏感：

0：按你创建时的大小写存，查询区分大小写（Linux 默认）；
1：统一转小写存储，查询不区分大小写（Windows 默认）。

关键点：这个参数必须在 MySQL 数据目录初始化（initialize）之前就定好，初始化之后不能改。旧数据字典里记录的是 1，新服务器默认 0，启动时一比对不一致，就拒绝启动。

正确处理是在初始化阶段就指定，而不是等服务装完再改配置。如果是全新初始化：

BashBash# 初始化时就带上参数（以实际配置方式为准）
sudo mysqld --initialize --lower-case-table-names=1 ...

我这边是导入已有数据，需要让新实例和旧实例保持一致：在配置文件 /etc/mysql/mysql.conf.d/mysqld.cnf 的 [mysqld] 段加上：

ini

INI

lower_case_table_names = 1

但务必在数据目录初始化/导入前设置；数据字典已经按 0 建好之后再改，同样起不来。改之前先确认旧库这个值：

BashBash# 旧机器上查
mysql -e "SHOW VARIABLES LIKE 'lower_case_table_names';"

坑三：socket 路径对不上

服务好不容易起来了，命令行连接又报：

核对服务状态与 socket 路径，必要时改走 TCP。

TextTextERROR 2002 (HY000): Can't connect to local MySQL server through socket
'/var/run/mysqld/mysqld.sock' (2)

本地用 mysql 命令连接时，默认走 Unix socket 文件，路径编译时定死。报错末尾的 (2) 是系统错误码 ENOENT，意思是这个 socket 文件不存在——要么服务没真正起来，要么实际 socket 在别的路径。

排查顺序：

BashBash# 1. 确认服务真的在运行
systemctl status mysql

# 2. 找实际的 socket 文件在哪
sudo find / -name "mysql*.sock" 2>/dev/null

# 3. 看配置里指定的 socket
grep -rn "socket" /etc/mysql/

常见情况：

服务没起来（前两个坑没解决），socket 自然不存在——回到错误日志继续查；
socket 在别的路径，连接时显式指定：mysql -S /run/mysqld/mysqld.sock；
或干脆走 TCP：mysql -h 127.0.0.1 -P 3306 -u root -p。

正确的迁移方式：逻辑导出导入

物理文件不能搬，就用 mysqldump 把数据导成 SQL 文本，再到新库执行。文本不挑架构、不挑小版本，最稳：

BashBash# 旧机器：导出（含建库、建表、触发器等）
mysqldump -u root -p --single-transaction --routines --triggers --events \
  --databases 你的库名 > backup.sql

# 拷贝 backup.sql 到新机器后导入
mysql -u root -p < backup.sql

--single-transaction 让 InnoDB 在不锁表的情况下拿到一致性快照；--routines --triggers --events 把存储过程、触发器、定时事件也带上。

迁移前的检查清单

新旧都查 SELECT VERSION();，大版本一致（同为 8.0）最稳；
新旧都查 lower_case_table_names，新实例初始化前就设成一致；
用 mysqldump 导出，不复制 ibdata1 和数据目录；
导入后核对库表数量，再验证站点连接；
连不上先看 systemctl status mysql 和错误日志，再区分是服务没起还是 socket 路径问题。

数据库迁移，搬的是逻辑数据，不是物理文件——这一条记住，能省掉大半天对着启动报错发呆。

宝塔面板在 Ubuntu 上装不上 MySQL：日志显示"执行成功"，软件却没装上

Thu, 22 Oct 2026 17:22:37 +0800

云服务器运维实战系列 · 第 3 篇（共 7 篇）

宝塔面板在 Ubuntu 上装不上 MySQL：日志显示"执行成功"，软件却没装上

在宝塔面板里点"安装 MySQL 8.0"，任务跑了一会儿，最后提示执行成功。可回到软件列表，MySQL 还是未安装，网站连不上数据库。

更怪的是，日志里反复刷 cat: /etc/redhat-release: No such file or directory，然后照样来一句"命令已执行"。这篇讲清楚这是怎么回事，以及在 ARM + Ubuntu 上怎么把 MySQL 真正装上。

先看现象

安装日志的关键片段：

TextText正在选择下载节点...
--2026-10-02 ... https://cf1-node.aapanel.com/install/0/mysql.sh
...
cat: /etc/redhat-release: No such file or directory
cat: /etc/redhat-release: No such file or directory
|-Successify --- 命令已执行! ---

脚本最后报"成功"，但：

软件商店 / 已安装列表里没有 MySQL；
mysql 命令不存在或服务起不来；
网站报数据库连接失败。

任务列表里这条记录往往标着"安装失败"，耗时只有几秒到十几秒。

脚本显示执行成功，不等于 MySQL 安装完成。

第一步：确认系统和架构

那句 cat: /etc/redhat-release 是线索。宝塔安装脚本里有一段要判断系统版本，它习惯去读红帽系（CentOS/RHEL）的 /etc/redhat-release。在 Debian/Ubuntu 上这个文件不存在，于是报错——脚本对 Debian/Ubuntu 的适配做得不完整。

先确认自己的系统：

BashBashcat /etc/os-release
# 例如：Ubuntu 22.04.3 LTS

uname -m
# aarch64 表示 ARM；x86_64 表示常见的 Intel/AMD

我这台是 Ubuntu 22.04、aarch64（甲骨文免费 Ampere）。

第二步：看真正的安装日志

面板消息盒子里那句"命令已执行"只是脚本跑完了，不代表装成功。要点"详情"看完整输出，或者看面板的安装日志文件，重点找：

有没有 ERROR、make: *** Error、No package、404 Not Found；
是"下载二进制包"还是"开始源码编译"。

宝塔对主流 x86 系统，通常直接下载预编译好的包，解压即用，几分钟搞定。而在 ARM 上，情况不一样。

根因：架构 + 脚本两个问题叠在一起

1. 没有匹配架构的预编译包。 宝塔的预编译包主要面向 x86_64。到了 aarch64，下载节点找不到对应包，脚本往往回退成"源码编译"——日志里会刷大量 Building CXX object ...、[xx%]。

ARM 缺少预编译包，可能回退到源码编译。

2. 源码编译 MySQL 极慢且容易失败。 MySQL 是几百万行级别的 C++ 工程，免费 ARM 实例上编译要很久，内存、依赖（cmake、gcc、各种 dev 库）稍有不足就中断。我这边编译卡在 20% 多反复失败，面板最终判定安装失败。

3. 脚本对 Ubuntu 适配不完整。 反复读 /etc/redhat-release 就是表现之一。它按红帽系的路径和判断逻辑走，在 Ubuntu 上会留下各种无效报错。

所以这不是"系统不干净"，而是架构和脚本适配问题。换个角度：面板里点安装，本质也是执行它下载的 shell 脚本，脚本没处理好 ARM + Ubuntu，再点几次结果一样。

怎么真正装上

在 ARM + Ubuntu 上，最省心的是直接用 Ubuntu 官方源装 MySQL，不依赖宝塔的预编译包：

BashBashsudo apt update
sudo apt install -y mysql-server

Ubuntu 22.04 官方源里的 MySQL 是匹配 aarch64 的，apt 会自动装好服务并设置开机自启。装完验证：

使用 Ubuntu ARM 系统源安装并验证服务。

BashBashsystemctl status mysql --no-pager
sudo mysql -e "SELECT VERSION();"

需要注意：

Ubuntu 源里的 MySQL 默认用 auth_socket 插件，root 在本机可以直接 sudo mysql 免密登录，设置密码和远程访问要另外处理（数据迁移那篇会讲）；
版本可能不是宝塔默认的 8.0 某个小版本，但同属 8.0，数据格式兼容；
装完宝塔面板一般能识别到系统里的 MySQL；若软件商店仍显示未安装，可在面板"数据库"里手动连接，或重启面板。

如果一定要用宝塔管理的那份，也可以在面板里选"编译安装"并耐心等它编完（可能数十分钟到数小时），期间别中断；但既然官方源有现成的 ARM 包，没必要硬等编译。

顺带说一句 PHP

同一台机器上，PHP 8.2 用面板编译也失败过，报错指向依赖库架构不对（file in wrong format）；而 PHP 7.4 能装上。这同样是 ARM 适配问题，我单独写了一篇。遇到"某个版本死活装不上"，先换个版本或换 apt 源，通常比反复点安装更有效。

排查顺序小结

cat /etc/os-release、uname -m，确认是 Ubuntu + ARM；
看完整安装日志，确认是"找不到预编译包 → 回退源码编译 → 编译失败"；
不死磕面板，改用 sudo apt install mysql-server 装官方 ARM 包；
装好后再处理 root 密码、数据导入和面板识别。

甲骨文云服务器运维实战系列云盘扩容 50G→150G

Thu, 22 Oct 2026 17:11:06 +0800

云服务器运维实战系列 · 第 2 篇（共 7 篇）

云盘扩容 50G→150G：控制台改完，为什么系统里还是老大小

迁到免费 ARM 实例后，默认系统盘只有 50G。眼下占用不高，但后面要装环境、跑数据库、留备份，我决定把它扩到 150G。

扩容时最容易懵的一点：控制台明明把盘改大了，登录机器一看，df 里还是老大小。这不是没生效，是中间还有两层没打通。这篇把完整步骤走一遍，全程不关机、业务不中断。

扩容到底在扩哪几层

一块云盘从物理容量到你能存文件，隔着三层，要逐层打通：

TextText云平台上的卷（Volume）       —— 控制台把 50G 改成 150G
        ↓
系统看到的磁盘 /dev/sda      —— 让内核重新识别磁盘大小
        ↓
分区 /dev/sda1 + 文件系统      —— 扩分区，再扩文件系统（ext4）

只做第一层，可用空间不会变，因为分区和文件系统还停在旧尺寸。

云卷、磁盘、分区和文件系统要逐层扩展。

第一层：控制台改大小

在控制台找到引导卷，编辑容量，50G 改成 150G。几点：

主流云都支持运行中在线扩引导卷，不用关机，网站不受影响；
只改容量，其他别动：性能档位（甲骨文叫 VPU，默认 10）、加密、跨区域复制保持原样，免得影响性能或产生费用；
容量只能调大、不能调回，想清楚再填。

提交后卷已经是 150G，但机器里还看不到。

控制台扩容后，来宾系统还要重新识别容量。

第二层：让内核重新扫描磁盘

扩容后操作系统未必立刻感知，需要触发一次重新扫描。甲骨文控制台扩容弹窗里会给出命令，核心是这两条：

BashBash# 对引导盘做一次只读探测，让内核重新读容量
sudo dd iflag=direct if=/dev/oracleoci/oraclevda of=/dev/null count=1

# 向 SCSI 设备的 rescan 接口写 1，触发重新扫描
echo "1" | sudo tee /sys/class/block/$(readlink /dev/oracleoci/oraclevda | cut -d'/')/device/rescan

/dev/oracleoci/oraclevda 是甲骨文对引导盘的固定别名，等价 /dev/sda。其他云、或盘名不同时，通用做法是往 /sys/class/block/<盘名>/device/rescan 写 1；嫌麻烦，重启一次实例也能识别。

扫描后确认磁盘层面已变大：

BashBashlsblk
# 或
sudo fdisk -l /dev/sda

这时 sda 整体已是 150G，但分区 sda1 可能还显示约 50G——接着做第三层。

第三层：扩分区（growpart）

用 growpart 把第 1 个分区扩到占满整块盘：

Bash

sudo growpart /dev/sda 1

/dev/sda 和分区号 1 之间有空格，意思是扩 sda 的第 1 个分区。成功会输出类似：

Text

CHANGED: partition=1 start=... old: size=... new: size=...

提示 command not found 就先装：

Bash

sudo apt update && sudo apt install -y cloud-guest-utils

第四层：扩文件系统（resize2fs）

分区大了，里面的文件系统（Ubuntu 默认 ext4）还不知道，最后在线扩一下：

Bash

sudo resize2fs /dev/sda1

ext4 支持挂载状态下在线扩容，不用卸载、不影响业务。

如果是 xfs 文件系统，对应命令是 sudo xfs_growfs /（按挂载点），别用 resize2fs。df -T 能看文件系统类型。

验证

Bash

df -h /

实际结果：

TextTextFilesystem      Size  Used Avail Use% Mounted on
/dev/sda1       146G  9.9G  136G   7% /

Size 从约 49G 变成 146G（标称 150G，文件系统略小是分区表和元数据占用，正常），可用约 136G。

扩分区与文件系统后，验证可用空间。

免费配额会不会超

用免费套餐，这步必须算清楚。按甲骨文"永久免费"文档，存储免费额度是：

块卷 + 引导卷合计 200GB，永久免费，且只在账号的"主区域"；
另有 5 个免费卷备份名额。

50G 扩到 150G 后：已用 150G，额度 200G，还剩 50G，不超标。

两个容易忽略的点：

免费额度按主区域算，卷要在主区域才计入；
我没给卷做手动快照，5 个免费卷备份名额仍空着（数据库的 .sql 备份是文件，不算卷备份）。

操作前后都建议到官方免费资源页核对一遍，政策偶尔调整，以最新文档为准。

顺序回顾

控制台改大小 → 内核 rescan（或重启）→ growpart 扩分区 → resize2fs（xfs 用 xfs_growfs）扩文件系统 → df 验证，再核对一遍免费配额。

甲骨文云免费 ARM 服务器：从 x86 迁到 ARM，"换块硬盘"为什么行不通

Sat, 03 Oct 2026 19:15:23 +0800

旧服务器要下线，我打算把站点搬到甲骨文云的免费 ARM 实例上。

动手前以为这会很轻松——云控制台点几下，把旧系统盘挂到新机器，系统、网站、数据库不就都继承了。

结果在第一步就卡住。这篇记录的就是这个卡点，以及为什么它在 x86 到 ARM 这条路上无解。

两台机器，两种 CPU

迁移涉及两台实例：

	旧实例（已下线）	新实例（免费套餐，现用）
CPU	AMD，x86_64	Ampere，ARM（aarch64）
系统	Ubuntu（x86_64）	Ubuntu 22.04（aarch64）
系统盘	150G 引导卷	50G 引导卷

甲骨文"永久免费"套餐里最值得用的就是 Ampere ARM 实例：最多 4 核、24G 内存，个人站点绰绰有余。CPU 和内存是配比关系（合计 4 OCPU / 24G），可以拆成 1 核 6G、2 核 12G 等，按需选。

想走的捷径

最省事的思路，是把旧机器那块 150G 系统盘直接挂到新机器上启动。云平台上这个操作叫"替换引导卷"：关机、分离当前引导卷、把旧卷作为引导卷挂上、开机。

我已经把旧卷先当数据盘附加到新实例（Linux 里识别为第二块盘），打算确认下里面的内容再动手。

幸好先看了一眼。

一条 file 命令，问题就清楚了

挂载旧盘后，我对旧系统里最核心的 /bin/bash 做了次检查：

# 旧盘挂载在 /mnt/oldroot
file /mnt/oldroot/bin/bash

输出：

/mnt/oldroot/bin/bash: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2 ...

x86-64。旧盘里的程序全是给 x86 编译的。

先确认可执行文件架构，旧盘不能直接启动。

再看新机器：

uname -m
# aarch64

到这儿，替换引导卷这条路就不用再想了。

为什么架构不同就没法用

x86 和 ARM 是两套不同的指令集。我们平时安装的软件，本质是源码编译成对应 CPU 能读懂的机器码。x86 编译出来的二进制，ARM 的 CPU 读不懂——不是兼容性问题，是两套语言。

Linux 可执行文件是 ELF 格式，文件头里写明了它面向哪种架构，file 读的就是这里。

于是旧盘的定位很明确：

当数据盘读、拷贝内容：可以。文件不挑架构，x86 盘里的文稿、图片、SQL、配置，ARM 机器一样能读；
当系统盘启动、跑里面的程序：不行。内核和第一个进程都是 x86 指令，机器根本起不来。

那正确的迁移方式是什么

系统和软件在 ARM 上重新装，只搬数据。旧卷继续挂着当数据盘，我逐项搬这些与架构无关的东西：

跨架构迁移：数据能搬，系统和二进制要重装。

网站源码、用户上传的文件（PHP、图片、附件，脚本和数据不挑架构）；
数据库用 mysqldump 导出成 .sql 再导入（这步坑不少，单独写了一篇）；
SSL 证书、密钥（PEM 文本）；
Nginx 等配置文件（文本，复制后按新环境改路径）；
定时任务、部署的应用，在新系统重新配置。

跟架构绑定的——操作系统、编译好的二进制、系统库——一律用 apt 或面板在 ARM 上重装。

源码、导出文件和配置逐项搬到新系统。

几个云盘操作命令

整个过程反复在"附加 → 挂载 → 拷贝 → 卸载 → 分离"，通用命令如下（设备名先 lsblk 确认）：

# 确认新挂上来的盘（如 /dev/sdb）
lsblk

# 挂载分区（假设数据在第2个分区）
sudo mount /dev/sdb2 /mnt/oldroot

# 拷贝数据 ...

# 用完卸载（先退出目录，确保没有进程占用）
sudo umount /mnt/oldroot

卸载后到控制台"分离（Detach）"。确认数据全部拷完、不再需要后，才"终止（Terminate）"——这步不可逆，务必先有备份。

写在最后

这次迁移给自己提了个醒：以后跨机器搬服务器，先跑一条 uname -m。

架构一致，克隆盘、做镜像都随意；架构不一致，就老老实实只搬数据，系统和软件重装。删旧卷前确认数据拷完、有备份，云盘终止找不回来。

数据库迁移、ARM 编译依赖、家宽端口这几个后续的坑，我也分别整理了，可以翻翻看。

阿宅二级域名分发系统轻量化全开源

Sat, 26 Sep 2026 21:05:32 +0800

项目介绍

AZhai Sub 是一个新一代的二级域名管理器，堪比 us.kg。无需 NS 服务器，只需要申请二级域名即可使用。

例如你拥有 xxx.com，用户申请 you.xxx.com，那么 *.you.xxx.com 下的域名都可以进行管理。

功能特性

二级域名申请与管理、域名申请审核
自定义二级域名、域名启用 / 暂停 / 恢复
DNS 解析管理、DNS 记录自动同步
SSL 证书申请
在线系统更新
管理员后台：用户管理、域名管理、DNS 服务商管理、操作日志
阿宅 OAuth 登录、多 DNS 服务商支持

DNS 解析

目前支持以下记录类型：A、AAAA、CNAME、TXT

注意：TXT 根域名验证需要用户申请 TXT 验证，管理员审核通过后，再由管理员手动添加 TXT 记录。

DNS 服务商

目前支持：Cloudflare、阿里云 DNS、华为云 DNS、腾讯云 DNS、西部数码 DNS，后续会根据实际需求继续接入更多服务商。

SSL 证书

支持 SSL 证书申请功能，用户可以针对自己的二级域名申请 SSL 证书，让分配的二级域名更方便地使用 HTTPS。

如何使用

上传项目：将项目上传到网站目录并解压
导入数据库：创建数据库后，将项目中的 database.sql 导入
修改配置：编辑 config.php，填写数据库连接信息；如需「阿宅登录」，可在此配置 OAuth 信息
登录后台：后台地址 https://你的域名/admin，默认管理员账号 azhai / azhai123，首次登录后建议立即修改默认密码

阿宅登录

支持接入「阿宅登录」：前往 oauth.azhai.de 申请 OAuth 密钥，填入 config.php。配置完成后注册一个阿宅账号，即可用同一账号登录所有接入阿宅 OAuth 的项目。

在线升级

内置在线升级功能，后续版本更新都可通过后台「系统更新」一键升级，无需重新下载、上传和覆盖文件。

技术栈

PHP 8 + MySQL 8

老王日记

OpenShell

OpenShell

一、为什么值得关注：它把“信任”从口头变成强制

二、它怎么跑：网关、监管器、沙箱三件套

三、适合谁，不适合谁

四、上手体验和坑：先把这四条看完再装

五、怎么试，第一次这样试最划算

GitHub 项目：security-audit-skill——让 AI 审计先学会别瞎报

解读 GitHub 项目：security-audit-skill——让 AI 审计先学会别瞎报

一、为什么值得关注：它治的是 AI 审计最常见的毛病

二、它怎么跑：六个阶段，其实就三句话

三、适合谁，不适合谁

四、上手体验和坑：先把这四条看完再跑

五、怎么试，第一次这样试最划算

免费流量被爬虫刷爆：用 Nginx 444 精准拦截（附安全配置清单）

免费流量被爬虫刷爆：用 Nginx 444 精准拦截（附安全配置清单）

第一步：确认流量是谁产生的

第二步：为什么用 444，而不是 403

第三步：按 User-Agent 拦截

第四步：拦截敏感路径扫描

第五步：限速，兜底防刷

验证效果

顺手整理的安全清单

小结

甲骨云服务器运维实战系列——家里连不上云服务器：TCP 能连、SSH 一握手就断，是端口被拦了

家里连不上云服务器：TCP 能连、SSH 一握手就断，是端口被拦了

先分清是哪种"连不上"

第一步：在服务器上确认服务和防火墙

第二步：看服务端有没有你的连接记录

第三步：用 TCP 探测验证端口可达性

第四步：确认是不是 fail2ban / 连接数

怎么绕过

排查顺序小结

ARM 服务器编译 PHP 报 file in wrong format：是依赖库的架构错了

ARM 服务器编译 PHP 报 file in wrong format：是依赖库的架构错了

报错在说什么

第一步：确认库的架构

第二步：看程序到底链接了哪些库

第三步：清掉错误的库，让它用正确的

第四步：装好后验证

通用的判断方法

MySQL 迁移的三个坑：ibdata1、lower_case_table_names、socket

MySQL 迁移的三个坑：ibdata1、lower_case_table_names、socket

坑一：直接拷 ibdata1，表空间初始化失败

坑二：lower_case_table_names 必须初始化前定

坑三：socket 路径对不上

正确的迁移方式：逻辑导出导入

迁移前的检查清单

宝塔面板在 Ubuntu 上装不上 MySQL：日志显示"执行成功"，软件却没装上

宝塔面板在 Ubuntu 上装不上 MySQL：日志显示"执行成功"，软件却没装上

先看现象

第一步：确认系统和架构

第二步：看真正的安装日志

根因：架构 + 脚本两个问题叠在一起

怎么真正装上

顺带说一句 PHP

排查顺序小结

甲骨文云服务器运维实战系列云盘扩容 50G→150G

云盘扩容 50G→150G：控制台改完，为什么系统里还是老大小

扩容到底在扩哪几层

第一层：控制台改大小

第二层：让内核重新扫描磁盘

第三层：扩分区（growpart）

第四层：扩文件系统（resize2fs）

验证

免费配额会不会超

顺序回顾

甲骨文云免费 ARM 服务器：从 x86 迁到 ARM，"换块硬盘"为什么行不通

两台机器，两种 CPU

想走的捷径

一条 file 命令，问题就清楚了

为什么架构不同就没法用

那正确的迁移方式是什么

几个云盘操作命令

写在最后

阿宅二级域名分发系统 轻量化全开源

项目介绍

功能特性

DNS 解析

阿宅二级域名分发系统轻量化全开源