通过 IP 屏蔽工具、Cloudflare、Nginx 或 Apache 拒绝拦截 IP 地址

一份面向网站站长与运维人员的深度实战教程，从拦截原理、四大方案横评、配置实战到分层防御与故障排查，全面覆盖独立 IP 屏蔽工具、Cloudflare、Nginx、Apache 四条主流 IP 拦截路径的完整落地方法。

1. 开头导语

根据 Akamai、Cloudflare 等安全厂商多年发布的《State of the Internet Security》报告，全球 Web 站点每天遭受的恶意请求中，超过 60% 来自可识别的恶意 IP 段，其中暴力破解、漏洞扫描、CC 攻击、内容爬取是四大最主要形态。这意味着，只要你的服务器暴露在公网，几乎必然会面对”该不该封掉某个 IP”的决策。

对站长和运维人员而言，能否高效、安全地拦截 IP，直接决定了三件事：服务器资源是否被无意义消耗（带宽、CPU、连接数）、业务可用性是否被拖垮（CC 攻击打垮登录接口）、以及安全合规风险（撞库导致账号泄露）。本教程将系统讲解 IP 拦截的本质原理、四种主流方案的横向对比、可直接复制的配置实战、分层防御策略、误封排查与自动化监控，帮助你建立一套可持续运转的 IP 治理体系。

2. IP 拦截的本质与适用场景

在动手配置之前，必须先理解”拦截一个 IP”到底意味着什么、以及哪些场景适合用 IP 拦截、哪些不适合。混淆场景会导致”封错对象、封错层级”的灾难性后果。

2.1 什么是 IP 拦截

IP 拦截的本质是：在网络路径上的某一层，依据来源 IP 地址（或 IP 段）对数据包做出丢弃、拒绝或挑战的判定。它可发生在从边缘到内核的任一层：

CDN 边缘层（Cloudflare）：恶意流量在到达源站前被挡掉。
主机内核层（iptables / nftables / ufw）：数据包进入网卡后即被丢弃。
反向代理层（Nginx）：在转发到后端前拒绝。
Web 服务器层（Apache）：在处理请求前返回 403。
应用层（代码逻辑）：业务级风控，按 IP 限频或弹挑战。

越靠边缘拦截，成本越低、效果越好；越靠后端，粒度越细但消耗越大。

2.2 适合 IP 拦截的场景

场景	典型特征	推荐拦截层
暴力破解 SSH / 登录接口	同一 IP 高频失败登录	fail2ban / iptables
CC / 刷接口	单 IP 高频请求某 URL	Cloudflare / Nginx
漏洞扫描	探测 `/wp-admin`、`/.env`、`/phpmyadmin`	fail2ban / Cloudflare
爬虫盗链	异常 UA + 高并发抓内容	Cloudflare Bot / Nginx
垃圾注册 / 评论	特定地区或 ASN 批量注册	Cloudflare 规则
针对性 DDoS	大量 IP 洪水请求	Cloudflare 边缘 + 上游限速
已知恶意 IP 段	威胁情报命中	iptables / Cloudflare

2.3 不适合单纯 IP 拦截的场景

动态 IP / CGNAT：攻击者频繁换 IP，封单 IP 收效甚微，应改用速率限制 + 行为挑战。
住宅代理（Residential Proxy）：IP 信誉正常，单 IP 拦截会误伤正常用户，需依赖行为分析与 TLS 指纹。
大段地区封禁：直接封整个国家段误伤严重，应交给 Cloudflare 按地区精确控制。
CDN 回源流量：若封了 CDN 节点 IP 段，等于封了所有正常用户，必须先还原真实访客 IP。

2.4 拦截动作的四种语义

动作	行为	客户端感受	适用场景
`DROP`	直接丢弃，不回应	连接超时（hang）	攻击场景默认推荐，制造不确定性
`REJECT`	回 ICMP / RST 拒绝	立即收到失败	需让合法客户端快速失败重试
`Challenge`	弹 JS 挑战 / 验证码	需通过才能访问	可疑但不确定的流量
`Log`	仅记录不拦截	正常访问	新规则灰度观察期

核心原则：拦截越靠边缘越好，但服务器本机防火墙始终是最后一道兜底，不能省；改防火墙前永远先想好怎么回滚。

3. 四种主流 IP 拦截方案横向对比

工欲善其事，必先利其器。四种方案各有定位，下表帮助快速判断该用哪条路径。

维度	独立工具（iptables/fail2ban）	Cloudflare	Nginx	Apache
拦截位置	服务器内核 / 主机层	CDN 边缘节点	反向代理 / Web 层	Web 层
是否需暴露源站	是	否（可隐藏源站 IP）	是	是
动态自动封禁	✅ fail2ban 支持	✅ 规则 + WAF	⚠️ 需脚本配合	⚠️ 需脚本配合
大规模 DDoS 抗压	❌ 受限于带宽	✅ Anycast 分散	❌	❌
配置复杂度	中	低	低	低
费用	免费	免费档够用 / 付费增强	免费	免费
按地区 / ASN 封禁	❌ 不方便	✅ 原生支持	⚠️ 需 GeoIP 模块	⚠️ 需 GeoIP 模块
适合对象	有 SSH 权限的自建服务器	任何站点，尤其受攻击站点	已用 Nginx 的站点	已用 Apache 的站点

一句话建议：

能上 Cloudflare 就上，把恶意流量挡在边缘，并隐藏源站 IP；
服务器本机用 iptables/ufw 兜底，再用 fail2ban 自动化；
应用层精细控制（按 URL / 按地区）交给 Nginx 或 Apache。

4. 方案一：独立 IP 屏蔽工具（iptables / ufw / fail2ban）

这一类工具运行在服务器本机，是最底层、性能最高的拦截手段，适合静态、明确的封禁，以及通过日志自动化的动态封禁。

4.1 iptables：内核级精准封禁

iptables 是 Linux 内核 netfilter 的用户态配置工具，数据包在进入用户态前即被判定，性能极高。

封单个 IP

# 拒绝来自 1.2.3.4 的所有入站流量
sudo iptables -A INPUT -s 1.2.3.4 -j DROP

# 仅拒绝 TCP，并返回 RST（让客户端立刻失败）
sudo iptables -A INPUT -p tcp -s 1.2.3.4 -j REJECT --reject-with tcp-reset

# 拒绝来自 1.2.3.4 的所有入站流量
sudo iptables -A INPUT -s 1.2.3.4 -j DROP

# 仅拒绝 TCP，并返回 RST（让客户端立刻失败）
sudo iptables -A INPUT -p tcp -s 1.2.3.4 -j REJECT --reject-with tcp-reset

封整个网段

# 封 10.0.0.0/8 整段
sudo iptables -A INPUT -s 10.0.0.0/8 -j DROP

# 封 10.0.0.0/8 整段
sudo iptables -A INPUT -s 10.0.0.0/8 -j DROP

封指定端口

# 只封 1.2.3.4 访问 22 端口（SSH）
sudo iptables -A INPUT -p tcp --dport 22 -s 1.2.3.4 -j DROP

# 只封 1.2.3.4 访问 22 端口（SSH）
sudo iptables -A INPUT -p tcp --dport 22 -s 1.2.3.4 -j DROP

持久化（重启不丢规则）

# Debian/Ubuntu
sudo apt-get install -y iptables-persistent
sudo netfilter-persistent save

# CentOS/RHEL
sudo yum install -y iptables-services
sudo service iptables save

# Debian/Ubuntu
sudo apt-get install -y iptables-persistent
sudo netfilter-persistent save

# CentOS/RHEL
sudo yum install -y iptables-services
sudo service iptables save

避坑：改防火墙前用一个带超时保护的计划任务定时回滚规则，避免把自己 SSH 锁死。例如 at now +5 minutes <<< "iptables -F"，5 分钟后自动清空，确认无误后再取消。

4.2 ufw：iptables 的友好封装（Ubuntu 默认）

ufw（Uncomplicated Firewall）是 iptables 的简化前端，语法更直观，Ubuntu 默认预装。

# 启用
sudo ufw enable

# 封单个 IP（所有端口）
sudo ufw deny from 1.2.3.4

# 封网段
sudo ufw deny from 10.0.0.0/8

# 封 IP 访问指定端口
sudo ufw deny from 1.2.3.4 to any port 22 proto tcp

# 白名单写法（默认拒绝，再放行）
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp   # 只允许这个 IP SSH

# 查看规则
sudo ufw status numbered

# 删除规则（按编号）
sudo ufw delete 3

# 启用
sudo ufw enable

# 封单个 IP（所有端口）
sudo ufw deny from 1.2.3.4

# 封网段
sudo ufw deny from 10.0.0.0/8

# 封 IP 访问指定端口
sudo ufw deny from 1.2.3.4 to any port 22 proto tcp

# 白名单写法（默认拒绝，再放行）
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp   # 只允许这个 IP SSH

# 查看规则
sudo ufw status numbered

# 删除规则（按编号）
sudo ufw delete 3

4.3 fail2ban：自动封禁神器

fail2ban 通过扫描日志 + 动态下发 iptables 规则实现自动封禁，是应对暴力破解的标配，无需人工值守。

安装

sudo apt-get install -y fail2ban     # Debian/Ubuntu
sudo yum install -y fail2ban         # CentOS/RHEL

sudo apt-get install -y fail2ban     # Debian/Ubuntu
sudo yum install -y fail2ban         # CentOS/RHEL

自定义 jail（封 SSH 暴力破解）

编辑 /etc/fail2ban/jail.local（覆盖默认配置，不要改 jail.conf）：

[DEFAULT]
# 封禁时长（秒）；-1 或 -m 表示永久
bantime  = 1h
# 时间窗口
findtime = 10m
# 触发阈值
maxretry = 5
# 封禁动作
banaction = iptables-multiport

[sshd]
enabled  = true
port     = ssh
logpath  = %(sshd_log)s
backend  = %(sshd_backend)s

[DEFAULT]
# 封禁时长（秒）；-1 或 -m 表示永久
bantime  = 1h
# 时间窗口
findtime = 10m
# 触发阈值
maxretry = 5
# 封禁动作
banaction = iptables-multiport

[sshd]
enabled  = true
port     = ssh
logpath  = %(sshd_log)s
backend  = %(sshd_backend)s

启动并验证：

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd
sudo fail2ban-client status                # 总览
sudo fail2ban-client set sshd unbanip 1.2.3.4   # 手动解封

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd
sudo fail2ban-client status                # 总览
sudo fail2ban-client set sshd unbanip 1.2.3.4   # 手动解封

自定义 jail：封 Nginx 401/403

[nginx-limit-req]
enabled  = true
filter   = nginx-limit-req
action   = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp]
logpath  = /var/log/nginx/error.log
findtime = 600
maxretry = 10
bantime  = 7200

[nginx-limit-req]
enabled  = true
filter   = nginx-limit-req
action   = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp]
logpath  = /var/log/nginx/error.log
findtime = 600
maxretry = 10
bantime  = 7200

进阶：fail2ban 的强大在于 filter.d/*.conf 正则匹配任意日志。任何能写日志的服务（MySQL、FTP、自家 API 网关）都能接进来做自动封禁。也可让 action 指向一个被 Nginx include 的文件，实现”fail2ban 自动维护 Nginx 黑名单”的联动。

4.4 DROP 与 REJECT 的取舍

动作	行为	客户端感受	适用场景
`DROP`	直接丢弃，不回应	连接超时（hang）	默认推荐，给攻击者制造不确定性，省带宽
`REJECT`	回 ICMP / 包拒绝	立即收到失败	需让合法客户端快速失败重试

攻击场景下 DROP 更”烦人”且更省带宽；但对自家监控探活类 IP 用 REJECT 能让告警更快触发。

5. 方案二：Cloudflare 拦截 IP

Cloudflare 在 CDN 边缘完成拦截，恶意流量根本到不了源站，是抗 DDoS 与封 IP 段的最佳选择，尤其适合受攻击站点和不想暴露源站 IP 的场景。

5.1 前置：还原真实访客 IP

经 Cloudflare 后，源站看到的源 IP 是 Cloudflare 节点。若直接按 $remote_addr 封禁，封的是 CDN 节点，等于封了所有正常用户。必须先恢复真实 IP。

Nginx 还原（set_real_ip_from + Cloudflare 官方段）：

# /etc/nginx/conf.d/cloudflare-realip.conf
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;

real_ip_header CF-Connecting-IP;
real_ip_recursive on;

# /etc/nginx/conf.d/cloudflare-realip.conf
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;

real_ip_header CF-Connecting-IP;
real_ip_recursive on;

段列表会随 Cloudflare 扩容更新，定期到官方文档同步：https://www.cloudflare.com/ips/。Apache 还原可装 mod_remoteip，原理相同。

5.2 在 Cloudflare 后台封 IP

路径：Security → WAF → Tools → IP Access Rules

字段	值	效果
IP / 段 / 国家 / ASN	`1.2.3.4` 或 `10.0.0.0/8`	命中目标
Action	`Block`	直接拒绝（返回 1003 / 403）
Action	`Challenge`	弹验证码（JS / CAPTCHA）
Action	`Allow`	白名单（优先级最高）
Action	`Log`	仅记录不拦截，用于观察期

5.3 用 WAF Custom Rules 做精细条件

IP Access Rules 只能按 IP 封，Custom Rules 可叠加 URL、国家、UA 等条件。例如「封禁某国访问 /admin」：

(http.request.uri.path contains "/admin") and (ip.geoip.country eq "CN")
→ Action: Block

(http.request.uri.path contains "/admin") and (ip.geoip.country eq "CN")
→ Action: Block

又如「数据中心 IP + 工具型 UA 直接拦截」：

(http.user_agent contains "sqlmap") or (http.user_agent contains "nikto")
) and (ip.geoip.asnum in {14061 16509 24940})
→ Action: Block

(http.user_agent contains "sqlmap") or (http.user_agent contains "nikto")
) and (ip.geoip.asnum in {14061 16509 24940})
→ Action: Block

5.4 自动化：API 批量封禁

# 通过 API 把一个 IP 加入封锁列表（Zone 级）
curl -X POST "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/firewall/access_rules/rules" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{
    "mode": "block",
    "configuration": { "target": "ip", "value": "1.2.3.4" },
    "notes": "abuse: brute force login 2026-10-10"
  }'

# 通过 API 把一个 IP 加入封锁列表（Zone 级）
curl -X POST "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/firewall/access_rules/rules" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{
    "mode": "block",
    "configuration": { "target": "ip", "value": "1.2.3.4" },
    "notes": "abuse: brute force login 2026-10-10"
  }'

需要 Token 权限：Zone.Firewall Access Rules: Edit。配合日志告警可实现全自动封禁链路。

5.5 Rate Limiting：比硬封 IP 更聪明

不必硬封 IP，用 Cloudflare Rate Limiting 对「高频访问某路径」做自动挑战，能应对动态 IP 攻击：

Rule: when (http.request.uri.path eq "/api/login") and (rate over 30 req/min per ip)
→ Action: Managed Challenge

Rule: when (http.request.uri.path eq "/api/login") and (rate over 30 req/min per ip)
→ Action: Managed Challenge

经验：对登录、注册、找回密码、支付、搜索五大端点必加 Rate Limiting；对静态资源不加。

6. 方案三：Nginx 拒绝 IP

Nginx 的 allow / deny 来自 ngx_http_access_module，默认编译开启，配置极简，适合已用 Nginx 的站点做应用层精细控制。

6.1 单 IP / 段封禁

# /etc/nginx/conf.d/block.conf
location / {
    # 拒绝这两个 IP / 段
    deny  1.2.3.4;
    deny  10.0.0.0/8;

    # 放行其余
    allow all;

    # 命中 deny 时返回 403
    # proxy_pass / root 等 ...
}

# /etc/nginx/conf.d/block.conf
location / {
    # 拒绝这两个 IP / 段
    deny  1.2.3.4;
    deny  10.0.0.0/8;

    # 放行其余
    allow all;

    # 命中 deny 时返回 403
    # proxy_pass / root 等 ...
}

规则自上而下匹配，先命中先生效，allow all 必须放最后。

6.2 仅放行白名单（反向写法）

location /admin {
    allow 203.0.113.10;     # 办公室出口
    allow 198.51.100.0/24;  # 内网段
    deny  all;
    # ...
}

location /admin {
    allow 203.0.113.10;     # 办公室出口
    allow 198.51.100.0/24;  # 内网段
    deny  all;
    # ...
}

6.3 用 map + 大列表批量封禁

当封禁名单很长，写一长串 if 既丑又易错，用 map 一次性映射：

# /etc/nginx/conf.d/blacklist.conf
map $remote_addr $is_blacklisted {
    default         0;
    1.2.3.4         1;
    10.0.0.0/8      1;
    203.0.113.5     1;
}

server {
    # ...
    if ($is_blacklisted) {
        return 403;
    }
}

# /etc/nginx/conf.d/blacklist.conf
map $remote_addr $is_blacklisted {
    default         0;
    1.2.3.4         1;
    10.0.0.0/8      1;
    203.0.113.5     1;
}

server {
    # ...
    if ($is_blacklisted) {
        return 403;
    }
}

map 的 CIDR 支持依赖 ngx_http_geo_module，Nginx 默认编译含此模块。也可用 geo 块配合 include 一个外部文件，便于脚本维护。

6.4 return 自定义响应 / 跳转

location / {
    # 封禁 IP：返回 444（Nginx 特有：直接断开连接，不发响应头）
    if ($is_blacklisted) { return 444; }
    # ...
}

location / {
    # 封禁 IP：返回 444（Nginx 特有：直接断开连接，不发响应头）
    if ($is_blacklisted) { return 444; }
    # ...
}

6.5 与 fail2ban 联动：自动写 deny 列表

让 fail2ban 的 action 指向一个由 Nginx include 的文件，实现自动维护黑名单：

# /etc/fail2ban/action.d/nginx-geo.conf
[Definition]
actionstart = touch /etc/nginx/blocklist.auto.conf
actionstop  = rm -f /etc/nginx/blocklist.auto.conf
actionban   = printf '%s 1;\n' "<ip>" >> /etc/nginx/blocklist.auto.conf && nginx -s reload
actionunban = sed -i '/^<ip> 1;$/d' /etc/nginx/blocklist.auto.conf && nginx -s reload

# /etc/fail2ban/action.d/nginx-geo.conf
[Definition]
actionstart = touch /etc/nginx/blocklist.auto.conf
actionstop  = rm -f /etc/nginx/blocklist.auto.conf
actionban   = printf '%s 1;\n' "<ip>" >> /etc/nginx/blocklist.auto.conf && nginx -s reload
actionunban = sed -i '/^<ip> 1;$/d' /etc/nginx/blocklist.auto.conf && nginx -s reload

在 Nginx 中：

geo $blocked {
    default 0;
    include /etc/nginx/blocklist.auto.conf;   # fail2ban 维护此文件
}

geo $blocked {
    default 0;
    include /etc/nginx/blocklist.auto.conf;   # fail2ban 维护此文件
}

6.6 重载配置

sudo nginx -t          # 先校验语法
sudo nginx -s reload   # 热重载，不中断连接

sudo nginx -t          # 先校验语法
sudo nginx -s reload   # 热重载，不中断连接

7. 方案四：Apache 拒绝 IP

Apache 提供 .htaccess（目录级，免重启）与主配置（性能更好）两种写法，底层都是 mod_authz_host（2.4+）。

7.1 Apache 2.4 语法（Require）

# /var/www/html/.htaccess
<RequireAll>
    # 拒绝单个 IP
    Require not ip 1.2.3.4
    # 拒绝网段
    Require not ip 10.0.0.0/8
    # 其余放行
    Require all granted
</RequireAll>

# /var/www/html/.htaccess
<RequireAll>
    # 拒绝单个 IP
    Require not ip 1.2.3.4
    # 拒绝网段
    Require not ip 10.0.0.0/8
    # 其余放行
    Require all granted
</RequireAll>

仅放行白名单（典型后台保护）

<RequireAny>
    Require ip 203.0.113.10
    Require ip 198.51.100.0/24
</RequireAny>

<RequireAny>
    Require ip 203.0.113.10
    Require ip 198.51.100.0/24
</RequireAny>

7.2 旧式 2.2 语法（Order / Allow / Deny，已弃用但能见到）

Order allow,deny
Allow from all
Deny from 1.2.3.4
Deny from 10.0.0.0/8

Order allow,deny
Allow from all
Deny from 1.2.3.4
Deny from 10.0.0.0/8

迁移提醒：升级到 2.4 后旧语法需 mod_access_compat 才生效，建议改写为 Require。

7.3 启用 .htaccess（如未生效）

主配置 AllowOverride 必须打开：

<Directory /var/www/html>
    AllowOverride All
    Require all granted
</Directory>

<Directory /var/www/html>
    AllowOverride All
    Require all granted
</Directory>

然后重载：

sudo apachectl configtest
sudo systemctl reload apache2   # Debian/Ubuntu
sudo systemctl reload httpd      # CentOS/RHEL

sudo apachectl configtest
sudo systemctl reload apache2   # Debian/Ubuntu
sudo systemctl reload httpd      # CentOS/RHEL

7.4 性能建议：写主配置而非 .htaccess

.htaccess 每次请求都重新解析目录层级，高并发下性能损耗明显。推荐直接写 <Directory> / <Location> 到主配置，并设 AllowOverride None。封禁名单很长时尤其如此——不要在 .htaccess 写几千行封禁，那是性能灾难，应迁到主配置或交给 Cloudflare。

7.5 按 URL 精细封禁

<Location /admin>
    <RequireAny>
        Require ip 203.0.113.10
    </RequireAny>
</Location>

<Location /admin>
    <RequireAny>
        Require ip 203.0.113.10
    </RequireAny>
</Location>

7.6 mod_rewrite 兜底（按 UA / 来源跳转）

RewriteEngine On
# 来自某 IP 直接 403
RewriteCond %{REMOTE_ADDR} ^1\.2\.3\.4$
RewriteRule .* - [F]
# 来自某段（10.0.0.*）
RewriteCond %{REMOTE_ADDR} ^10\.0\.0\.
RewriteRule .* - [F]

RewriteEngine On
# 来自某 IP 直接 403
RewriteCond %{REMOTE_ADDR} ^1\.2\.3\.4$
RewriteRule .* - [F]
# 来自某段（10.0.0.*）
RewriteCond %{REMOTE_ADDR} ^10\.0\.0\.
RewriteRule .* - [F]

8. 组合策略：分层防御

实际生产环境通常多层叠加，下图示意典型链路：

[ 访客 ]
   │
   ▼
(1) Cloudflare 边缘 ── WAF / 速率限制 / 国家级封禁
   │  ← 挡掉 90% 噪声
   ▼
(2) 主机 iptables/ufw ── fail2ban 自动下发规则
   │  ← 兜底 + 真实 IP（已还原）
   ▼
(3) Nginx/Apache ── allow/deny + 按 URL 精细控制
   │  ← 应用层语义拦截
   ▼
(4) 应用代码 ── 业务级风控（可选）

[ 访客 ]
   │
   ▼
(1) Cloudflare 边缘 ── WAF / 速率限制 / 国家级封禁
   │  ← 挡掉 90% 噪声
   ▼
(2) 主机 iptables/ufw ── fail2ban 自动下发规则
   │  ← 兜底 + 真实 IP（已还原）
   ▼
(3) Nginx/Apache ── allow/deny + 按 URL 精细控制
   │  ← 应用层语义拦截
   ▼
(4) 应用代码 ── 业务级风控（可选）

8.1 推荐组合方案

站点类型	边缘层	主机层	应用层
个人 / 小站	Cloudflare 免费档	ufw + fail2ban（封 SSH）	—
企业站	Cloudflare（WAF + Bot）	iptables 白名单	Nginx 应用层规则
无法用 CDN 的内网服务	—	iptables + fail2ban	Nginx/Apache `allow`
高价值目标（电商 / 金融）	Cloudflare 企业版 + 专业 Bot 服务	iptables + fail2ban	Nginx + 应用风控

8.2 分层防御的核心原则

先还原真实 IP，再做任何基于 IP 的判断——否则封的是 CDN 节点。
边缘优先——能在 Cloudflare 挡掉的，不要让流量进源站。
静态规则下放主机层——明确的恶意段用 iptables 一次性挡掉，省 CPU。
动态封禁交给 fail2ban——按日志自动反应，无需人工。
应用层做语义拦截——按 URL、按业务逻辑精细控制。

9. 最佳实践与避坑清单

9.1 Do（推荐做法）

永远先 iptables -L / ufw status / nginx -t 检查再 reload，避免把自己锁死。
给 SSH 留一个带超时保护的会话再改防火墙规则，防止误封后无法登录。
封禁前确认已还原真实访客 IP（见 5.1），否则封的是 CDN 节点。
周期性归档封禁名单，避免规则无限膨胀拖慢性能。
给封禁动作加 notes，方便溯源与到期解封。
优先用速率限制 / Challenge，比硬封 IP 更能应对动态 IP 攻击。
监控 403/444 量级，异常暴涨说明规则可能误伤或攻击升级。
新拦截规则先用 Log 动作观察一周，再切 Block，灰度上线。

9.2 Don’t（避坑）

不要在 .htaccess 写几千行封禁——性能灾难，迁到主配置或 Cloudflare。
不要无脑 DROP 大段 IP（如整国），误伤严重，优先用 Cloudflare 按地区精确控制。
不要忘了持久化 iptables 规则，重启即丢。
不要在 Nginx 用一连串 if 替代 map/geo，既丑又易错。
不要把 Cloudflare 的「Under Attack 模式」当常态，会拖慢所有正常用户。
不要把整段 0.0.0.0/0 或大运营商 ASN 加入白名单，等于裸奔。
不要只封 IPv4 忘了 IPv6，攻击者会用 IPv6 绕过。

10. 故障排查

现象	排查方向
改完规则后自己也连不上	用带 `at` 的计划任务定时回滚规则，或控制台 VNC 进入清空
Cloudflare 封了但源站仍被刷	未还原真实 IP → 封的是 CF 节点；或源站 IP 泄露被直连
Nginx `allow/deny` 不生效	检查 `location` 嵌套、`allow all` 是否在 `deny` 之后、`nginx -t` 语法
Apache `.htaccess` 无效	`AllowOverride` 未开、模块未加载（`a2enmod rewrite authz_host`）
fail2ban 不封禁	检查 `logpath` 是否正确、`filter` 正则是否命中、时区与日志时间戳
封了 IP 但仍能访问	多出口 IP / CGNAT / IPv6 绕过；补封 IPv6 段

# 快速验证某 IP 是否被 iptables 命中
sudo iptables -L INPUT -v -n --line-numbers | grep 1.2.3.4

# 看某 IP 的连接计数
sudo conntrack -L | grep 1.2.3.4

# fail2ban 查看某 jail 的封禁列表
sudo fail2ban-client status sshd

# 快速验证某 IP 是否被 iptables 命中
sudo iptables -L INPUT -v -n --line-numbers | grep 1.2.3.4

# 看某 IP 的连接计数
sudo conntrack -L | grep 1.2.3.4

# fail2ban 查看某 jail 的封禁列表
sudo fail2ban-client status sshd

11. 常见问题 FAQ

Q1：开启 Cloudflare IP 封禁会影响 SEO 收录吗？

不会。Cloudflare 通过反向 DNS 验证的 Googlebot/Bingbot 会被识别为 Verified Bot 自动放行。但若你自定义了拦截规则且顺序错误，可能误拦。因此应配置一条「放行已验证机器人」规则并置于所有拦截规则之前，确保搜索引擎爬虫不受影响。

Q2：动态 IP 攻击者频繁换 IP 怎么办？

封单 IP 收效甚微，应改用速率限制 + 行为挑战。在 Cloudflare 对登录、注册等高价值端点配置 Rate Limiting（如单 IP 30 req/min 触发 Managed Challenge），让攻击者每换一个 IP 都要过挑战。同时在主机层用 fail2ban 做高频失败自动封禁，叠加 IP 段封禁（如封整个恶意 ASN）扩大覆盖面。

Q3：iptables 规则改错把自己锁在外面了怎么办？

预防为主：改防火墙前先开一个带超时的回滚任务，例如 at now +5 minutes <<< "iptables -F; iptables -X"，5 分钟后自动清空，确认无误后再取消。若已锁死，通过云服务商控制台的 VNC / 串行控制台进入，清空规则后重新配置。

Q4：.htaccess 写了几千条封禁，网站变慢怎么办？

.htaccess 每次请求都重新解析，几千条规则会导致明显延迟。解决：把规则迁到 Apache 主配置的 <Directory> 块，设 AllowOverride None；或更好的做法是把这类大名单交给 Cloudflare IP Access Rules / WAF 规则，在边缘拦截，根本不到源站。

Q5：Cloudflare 封了 IP 但源站日志里还能看到它的请求？

两种可能：第一，源站 IP 已泄露，攻击者绕过 Cloudflare 直连源站 IP——应用 Cloudflare 的「源站 IP 不泄露」最佳实践（不开放源站 80/443 给全网，仅放行 Cloudflare 段）；第二，封禁规则作用域选错（如只封了某子域），检查 IP Access Rules 的作用域是否覆盖目标域名。

Q6：免费方案能做到什么程度？

免费方案（Cloudflare 免费档 + ufw + fail2ban + Nginx/Apache allow/deny）可拦截 70%~80% 的中低级攻击，覆盖暴力破解、漏洞扫描、工具型 UA、高频请求、数据中心 IP 等主流形态。剩余 20%~30% 的高级攻击（住宅代理、无头浏览器、TLS 指纹伪造）需付费方案或专业 Bot 管理服务，建议业务量做大后再投入。

12. 总结与行动清单

IP 拦截不是单一动作，而是分层、可观测、可回滚的体系。请按以下时间线落地：

今天：开启 Cloudflare IP 封禁能力，配置「放行已验证机器人」置顶规则，确保 SEO 收录不受影响。
本周：在服务器装好 ufw + fail2ban，封 SSH 暴力破解；对登录/注册/支付端点加 Cloudflare Rate Limiting。
本月：还原真实访客 IP（Nginx set_real_ip_from / Apache mod_remoteip），编写 Nginx 或 Apache 的应用层 allow/deny 规则，灰度上线观察一周后切全量。
本季度：审计所有封禁规则和白名单，下线过期条目；评估是否需要专业 Bot 管理服务。
长期：建立每周日志审计、每月规则调优、每季度基线校准的常态化机制，让 IP 治理自运转。

记住核心原则：先还原真实 IP，再做任何基于 IP 的判断；先边缘后主机，先灰度后全量；先速率限制后硬封 IP。 持续观察、持续调优，你的网站就能在恶意流量的洪流中守住真实用户的价值。

如何通过 IP 屏蔽工具、Cloudflare、Nginx 或 Apache 拒绝拦截 IP 地址