在国产化替代的推进过程中，我最近把一批业务从 x86 迁到了 arm64 的银河麒麟 V10 服务器上，系统层面倒还好，最头疼的是 Web 安全防护一直没落位。以前惯用的商业 WAF 授权贵不说，对新架构的适配也磨磨蹭蹭。后来调研了一圈，发现长亭的雷池 WAF 社区版值得一试——免费、支持 arm64 镜像、部署走 docker-compose，跟现有运维方式能无缝衔接。这篇就把我在麒麟 V10 arm64 上从零安装、初始化、接入防护站点的完整过程写出来，尤其是离线环境的处理和各种容易踩的坑，给同样要在信创环境里做 Web 防护的同学当个参考。
1. 为什么会在 arm64 麒麟上选雷池 WAF
1.1 雷池 WAF 到底解决什么问题
雷池 WAF（SafeLine）是一款开源的 Web 应用防火墙，核心作用是把真实的 Web 业务隐藏在后面，所有外部请求先经过它识别一遍，再把干净流量转给后端。它对常见的 Web 攻击有现成的拦截规则，比如 SQL 注入、XSS 跨站脚本、命令注入、路径穿越、恶意文件上传这些，基本覆盖了 OWASP Top 10 里的大部分场景。
我比较看重的是它的检测方式。传统 WAF 靠正则匹配，规则写得好不好直接影响效果，误报和漏报很难平衡。雷池社区版的检测引擎会对请求做语义层面的解析，再结合模式匹配，同一个攻击特征被编码、分块、变形之后仍然能识别，误报率比纯正则方案低不少。这个特性在实际运维里很重要，不然上线第一天就被各种业务误报轰炸，早晚得拆掉。雷池社区版对个人和中小团队免费，商用要另外谈授权，但社区版的功能已经覆盖了日常防护的大部分需求。
1.2 arm64 和 amd64 在软件部署上差在哪
先解释一个最基础的概念：arm64 和 amd64 是两种 CPU 指令集架构，amd64 是 Intel/AMD 阵营的 64 位架构，arm64 是 ARM 阵营的 64 位架构，指令集完全不兼容。这意味着在 x86 上编译好的二进制程序不能直接在 arm64 上运行，必须拿对应架构的版本。
放到 Docker 场景里，镜像也是区分架构的，同一个镜像仓库下通常会有 linux/amd64 和 linux/arm64 等多个平台的 tag。Docker 默认会拉取与当前宿主架构匹配的镜像，但如果镜像仓库没有发布 arm64 版本，安装过程就会报no matching manifest for linux/arm64之类的错误。这也是很多流行软件在国产化 arm64 环境里装不上的根本原因，不是系统不行，是软件没有适配。
所以，评估雷池 WAF 能不能在麒麟 V10 上用，第一件事就是确认它的官方 Docker 镜像是否发布了 arm64 版本。我实测下来，雷池社区版目前的镜像已经做了 arm64 适配，在线和离线两种安装方式都能在 arm64 环境跑通。
1.3 方案选型时我对比过哪些替代品
在确定雷池之前，我把市面上常见的几个开源 WAF 都过了一遍，大致情况是这样：
- ModSecurity 配合 Nginx：老牌方案，规则库庞大，但纯正则匹配为主，性能开销大，配置复杂，对新手不友好，而且 arm64 下编译要自己折腾依赖。
- Coraza：Go 实现的 WAF 引擎，部署轻量，但生态相对小，图形化管理界面基本没有，落地全靠写配置。
- 雷池 WAF 社区版：自带管理后台，图形化添加站点、配置证书、查看日志，Docker 一键部署，arm64 镜像齐全，检测能力也不错。
对运维团队来说，一个能可视化管理的 WAF 太重要了。纯命令行配置 WAF 不是不能用，但遇到问题排查起来效率太低。雷池的社区版恰好补齐了这个短板，这也是我最后选它的直接原因。
2. 麒麟 V10 环境准备与 Docker 安装
2.1 先确认系统版本和 CPU 架构，别急着动手
不管装什么软件，第一步永远是确认环境。麒麟 V10 这个产品线比较复杂，有服务器版、桌面版，底层有的基于 RPM 体系，有的基于 DEB 体系，不同小版本之间的命令和软件源差异比较大。我这次用的是银河麒麟高级服务器操作系统 V10 SP3，属于 RPM 体系，默认走 yum/dnf 包管理。
执行下面三条命令，先把底摸清楚：
cat /etc/os-release uname -m lscpu | grep Architecture如果输出里看到aarch64，说明 CPU 架构就是 arm64，后续所有镜像和安装包都要按 arm64 来选。如果看到x86_64，那就是 amd64 环境。我遇到过有人拿 x86 的镜像包硬往 arm64 上装，折腾半天都是白费功夫。另外建议一并用df -h看下磁盘空间，因为 Docker 镜像和日志都比较占空间，建议给/var/lib/docker所在的目录预留至少 20GB 以上余量。
2.2 在线安装 Docker 的操作步骤
麒麟 V10 服务器版可以直接添加 Docker 官方 CentOS 源来安装，但因为系统标识是 Kylin，yum 可能会把 releasever 识别成奇奇怪怪的版本号。比较省事的做法是直接配置阿里云的 docker-ce 镜像源，然后固定用--releasever=8参数来装，具体命令如下：
sudo yum install -y yum-utils sudo yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo sudo yum makecache --releasever=8 sudo yum install -y docker-ce docker-ce-cli containerd.io --releasever=8装完之后依次启动 Docker 并验证：
sudo systemctl enable docker sudo systemctl start docker docker version执行docker version能看到 Client 和 Server 两段信息，如果 Server 段也正常输出，说明 Docker 守护进程已经在跑了。这里有个容易忽略的细节：很多人只看到 Client 信息就以为成功了，其实 Server 没起来后面所有容器都跑不了，务必确认两段都有输出。
我还建议顺手配置一个 Docker 镜像加速器，不然拉镜像的时候可能会很慢。麒麟机器如果在内网，一般会有自己的镜像仓库，配置方式就是修改/etc/docker/daemon.json，把 registry-mirrors 指向内部地址，然后重启 Docker。
2.3 没外网环境怎么办，离线安装 Docker 的完整姿势
很多生产麒麟机器是隔离网环境，不能直接访问外网源，这时候需要离线安装。我的做法是在一台能联网的同架构机器上把 Docker 的 RPM 包全部下载下来，再拷到目标服务器安装。
先在有网机器上执行：
sudo yum install -y yum-utils sudo mkdir -p /tmp/docker-rpm sudo yumdownloader --resolve --destdir=/tmp/docker-rpm docker-ce docker-ce-cli containerd.io --releasever=8然后把这个目录打包传进麒麟服务器，在目标机器上执行：
sudo yum localinstall -y /tmp/docker-rpm/*.rpm用yum localinstall而不是rpm -ivh，是因为它能自动解析本地 RPM 包之间的依赖关系。如果依赖还缺，会提示缺少哪些包，再单独补就行。离线环境最怕的就是缺依赖时来回拷贝，建议打包时把docker-compose-plugin也一起拉下来，雷池的 compose 功能要用到它：
sudo yumdownloader --resolve --destdir=/tmp/docker-rpm docker-compose-plugin --releasever=8装完同样用docker version验证。
3. 雷池 WAF 的两种安装实操
3.1 在线一键安装，实测跑通的完整流程
雷池社区版官方提供了一键安装脚本，理论上执行一条命令就能完成安装，但我在麒麟环境上还是花了一点时间，因为脚本会先检测 Docker 和 docker-compose 插件是否可用。完整命令是：
bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/setup.sh)"这个脚本执行后，会做几件事：检查系统架构、检查 Docker 环境、生成默认的安装目录/data/safeline，然后拉取所需的 Docker 镜像并用 docker-compose 把它们编排起来。我在 arm64 麒麟上执行时，脚本顺利识别到了架构，没有出现架构不匹配的报错。
如果需要指定安装目录，可以用环境变量方式传参，比如：
export SAFELINE_DIR=/data/safeline bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/setup.sh)"整个拉镜像过程耗时取决于网络情况，我这边大概几分钟。如果长时间卡在某一个镜像上不动，多半是网络到 Docker Hub 不通畅，可以给 Docker 配好镜像加速器后重新执行脚本。脚本执行到最后会打印管理后台地址、默认端口和初始账号信息，一定要保存好。
3.2 离线包安装，适配隔离网环境的正确姿势
对不能访问外网的机器，雷池官方也提供离线安装包，这点在选型时很加分。离线包需要提前在能联网的机器上下载，而且必须选对架构——arm64 的机器要下载 arm64 版本的离线包，x86 的下载 amd64 版本，两者不能混用。
我这次是在有网的同架构测试机上，从雷池官网下载中心把离线包safeline-offline-xxx-arm64.tar.gz拉下来，然后上传到麒麟服务器上。安装步骤：
tar -xzf safeline-offline-xxx-arm64.tar.gz cd safeline-offline sudo bash setup.sh脚本会把离线包里的镜像 load 进 Docker，再生成 compose 文件并启动服务。整个过程不需要访问外网，只要镜像文件完整就能装。相比在线安装，离线包的好处是版本固定、可重复部署，适合多台机器批量交付；缺点是需要手动关注版本更新，升级时要重新下载新的离线包。
3.3 安装完成后的验证命令与关键检查项
安装脚本跑完不等于安装成功，一定要自己动手验证一遍。先用命令查看容器是否全部处于运行状态：
docker compose -f /data/safeline/docker-compose.yml ps正常情况下，你会看到 safeline-tengine、safeline-detector、safeline-mgt-api、safeline-mario 以及配套的 postgres、redis 等容器，状态都是 Up。核心的是前三个，tengine 负责流量入口，detector 做检测，mgt-api 是管理后端。
另外建议检查一下镜像架构是否真的匹配：
docker inspect --format '{{.Architecture}}' <容器镜像名或ID>输出应该是arm64。这一步很多人跳过，但在 arm64 环境里非常关键，如果不匹配，运行时会频繁报异常，甚至在 qemu 模拟层下跑得奇慢无比。
管理页面默认通过 HTTPS 的 9443 端口访问，所以还要确认安全组和防火墙有没有放行。
4. 初始化配置与防护规则落地
4.1 首次登录管理后台并完成基础设置
安装完成后，浏览器访问https://服务器IP:9443。因为用的是自签名证书，浏览器会有安全提示，点击继续访问即可。首次打开会进入初始化页面，需要创建一个管理员账号，设置登录密码。这里要提醒一句：密码强度一定要够，因为管理后台是安全产品的核心，一旦被攻破整个防护体系就形同虚设了。
登录进去之后，我建议先做三件事：一是到系统设置里把管理后台的会话超时时间调短一点，降低管理端暴露的风险；二是确认服务时间和系统时间一致，日志时间错乱会让后续排查非常痛苦；三是浏览一下仪表盘，确认 WAF 状态显示正常、检测引擎已启用。雷池的管理界面整体设计得比较直观，左侧菜单包含站点管理、证书管理、黑白名单、日志中心、系统设置等模块，基本不需要看文档就能上手。
4.2 把第一个 Web 站点接入 WAF
雷池接入站点的方式和 Nginx 反代很像，本质就是把流量先引到 WAF，再由 WAF 转发给后端源站。在管理后台的“站点管理”里点击添加站点，需要填写几个关键参数：域名或 IP、源站地址和端口、WAF 监听端口。
我这次测试时，域名填了test.local，源站指向本机 19090 端口的一个 Nginx 测试服务，WAF 会自动分配一个监听端口，也可以手动指定 80。为了测试方便，我在/etc/hosts里加了一条解析：
echo "127.0.0.1 test.local" >> /etc/hosts如果你在公网环境接入真实业务，需要把域名的 DNS 解析切换到 WAF 所在的服务器 IP，而不是直接解析到源站。这一步很关键，如果 DNS 还指向源站，请求根本不会经过 WAF，防护规则再强也白搭。
关于证书，雷池可以在证书管理里上传已有的 SSL 证书，也可以在站点的 HTTPS 配置里选择现有证书。如果暂时没有证书，可以先以 HTTP 形式接入测试，后续配上证书后直接在站点设置里切换即可，不需要重建站点。
4.3 怎么确认防护规则真的生效了
接入完成后，如果不验证一下防护效果，心里始终没底。我很推荐用下面这个思路做一轮功能测试：先在源站起一个临时测试服务，确保它能正常访问；然后通过 WAF 访问同一个服务，确认流量正常转发；最后发送几个常见的攻击特征字符串，观察是否被拦截。
先起一个测试站点：
docker run -d --name web-test -p 19090:80 nginx:alpine在管理后台把站点test.local的源站配置指到127.0.0.1:19090，然后分别执行几个测试请求：
# 正常请求，应该能正常返回 200 curl -k -H "Host: test.local" http://127.0.0.1/ # 路径穿越特征测试，应该被 WAF 拦截 curl -k -H "Host: test.local" "http://127.0.0.1/?file=../../etc/passwd" # XSS 特征测试，同样期望被拦截 curl -k -H "Host: test.local" 'http://127.0.0.1/?q=<script>alert(1)</script>'如果 WAF 拦截生效，后面两个请求的返回码不是 200，而是 403 或者雷池自带的拦截提示页面。再去日志中心的“拦截日志”里看，能看到对应的命中记录，包括请求时间、来源 IP、攻击类型、命中的规则 ID。
5. 常见问题与排查实录
5.1 arm64 环境下的几个特有坑
arm64 架构在国内还处于快速发展期，软件生态整体没有 x86 成熟，雷池安装过程中最容易遇到的就是架构不匹配的问题。
第一个坑是拉取镜像时报no matching manifest for linux/arm64。出现这个问题，要么是某个镜像没有发布 arm64 版本，要么是你的 Docker 没有正确识别宿主架构。排查方式是先确认uname -m确实是 aarch64，再检查是否设置了DOCKER_DEFAULT_PLATFORM环境变量导致 Docker 一直尝试拉取别的架构。
第二个坑是镜像能启动但性能极差。有时候 Docker 会默认尝试拉取 amd64 镜像，并通过 qemu 模拟层在 arm64 宿主上运行。这种方式能做功能验证，但性能完全不能用于生产。判断方法就是前面提到的docker inspect --format '{{.Architecture}}'，看到amd64就要警惕了。
第三个坑是有人喜欢在 x86 开发机上用 qemu 模拟 arm64 环境提前做验证，结果模拟环境里跑得好好的，部署到真机却出问题。这通常是因为模拟环境和真机的内核版本、系统库版本有差异。我的建议是尽量在真实 arm64 硬件上做预演，或者至少保证系统的内核和 Docker 版本一致。
5.2 安装脚本和端口冲突的处理
雷池默认使用 80 端口作为流量入口、9443 端口作为管理入口。如果服务器上已经装了 Nginx、Apache 或者其他软件占用了 80 端口，安装脚本虽然不会报错，但后续流量转发会出问题。
我的解决思路是：如果业务本身依赖 Nginx，可以调整雷池 compose 文件里的端口映射，把 WAF 的流量入口改成非 80 端口，然后在 Nginx 里反代到这个端口。但这样多了一层转发，增加了部署复杂度。更推荐的做法是把原 Nginx 作为源站接在雷池后面，让雷池直接监听 80/443，整体链路更干净。如果只是临时测试，把原来的服务停掉最省事。
安装过程卡在拉镜像也经常遇到。在麒麟上，如果配置了内部镜像仓库，可以先把雷池的镜像导出再导入，绕开网络问题：
# 在有网环境拉取镜像后导出 docker save -o safeline-images.tar <镜像列表> # 在离线环境导入 docker load -i safeline-images.tar5.3 麒麟系统层面的一些注意事项
麒麟 V10 默认开启了 firewalld，如果管理后台一直访问不了，多半是防火墙没放行 9443 端口。执行：
sudo firewall-cmd --permanent --add-port=9443/tcp sudo firewall-cmd --permanent --add-service=http sudo firewall-cmd --permanent --add-service=https sudo firewall-cmd --reload还有磁盘空间问题，雷池运行一段时间之后，日志和审计数据会持续增长，如果磁盘比较小，建议定期清理。日志中心里可以设置保留时间，也可以直接在系统层面做日志目录的定时清理。
系统内核参数如果被优化过，也可能影响 Docker 网络。比如net.bridge.bridge-nf-call-iptables如果被关闭，容器之间的网络通信会异常。稳妥的做法是不要随意调整运行代理类容器的主机网络参数，如果一定要调，先确认sysctl net.bridge.bridge-nf-call-iptables的值是 1。
提示：凡是修改了系统层配置，都建议重启 Docker 服务后重新验证容器状态，不要直接沿用旧的状态判断。
6. 日常使用中我比较推荐的几个运维习惯
6.1 备份和恢复的思路
雷池的配置都存在/data/safeline目录下，包括站点配置、证书、黑白名单、检测日志等。我建议对/data/safeline/resources下的配置目录做定期备份，最简单的方式就是打包拷贝到远程存储：
tar -czf safeline-backup-$(date +%F).tar.gz /data/safeline/resources恢复的时候，在新的雷池环境上把备份包解压回去，再重启容器即可。不过要注意，备份和恢复的雷池版本尽量保持一致，跨大版本恢复配置可能会出现兼容问题。
6.2 规则库和版本更新的节奏
雷池社区版会定期发布新版本，包含检测引擎的增强和规则库的更新。我建议不要一有新版本就立即升级，先看官方更新日志，在测试环境验证一轮再上生产。升级方式相对简单，管理员可以通过 Web 控制台的可视化操作完成检测引擎升级，也可以在/data/safeline目录下执行升级脚本完成版本更新。
需要特别注意的是，升级前一定要备份数据，并且避开业务高峰时段。WAF 升级需要重启所有容器，虽然时间很短，但对实时流量会有影响，最好在维护窗口期操作。
6.3 日志和监控的日常关注点
雷池的拦截日志是最有价值的安全数据来源，我习惯每周看一次日志中心，重点关注的几个维度：攻击来源 IP 的分布、被攻击最多的业务站点、经常命中的攻击类型。这些信息能帮助判断哪些业务是攻击者重点关注对象，也可以反推源站是否有潜在弱点。
此外，容器资源占用也值得关注。雷池的检测引擎在请求量大的时候会消耗不少 CPU，建议用docker stats定期观察资源使用情况。如果在 arm64 机器上发现 CPU 占用持续偏高，先确认容器镜像架构是否是 arm64，排除 qemu 模拟层的性能损耗，再考虑调整检测引擎的并发参数。
我在实际使用中还有一个体会：WAF 不是装了就能一劳永逸，它需要结合实际业务持续调优。比如某些业务场景下，正常的 URL 参数里可能会包含类似 SQL 关键字的内容，导致 WAF 误报。雷池的日志中心能清楚地看到每一次拦截的完整请求，遇到误报时，可以通过加白名单、调整规则优先级来处理，而不是直接关掉防护。每个部署环境都有自己的特殊性，多花一点时间观察日志、适配策略，WAF 才能真正发挥价值，而不是变成一台只会 403 的拦截机器。
