最通用可靠的方式是用iptables或nftables在input链加drop规则；/etc/hosts.deny仅对支持tcp_wrappers的服务有效且易被绕过；nginx的allow/deny仅作用于http层，无法拦截ssh等非http流量。
直接说结论：用 iptables 或 nftables 在 INPUT 链加 DROP 规则是最通用、最可靠的方式；/etc/hosts.deny 仅对支持 tcp_wrappers 的服务（如 sshd、vsftpd）有效，且容易被绕过；Nginx 的 allow/deny 只作用于 HTTP 层，不能拦 SSH 或其他端口。
用 iptables 禁止单个或网段 IP（最常用）
这是系统级拦截，生效快、覆盖全，适合绝大多数场景。
-
iptables -I INPUT -s 192.168.1.100 -j DROP：立即封禁该 IP 入站流量（-I插入顶部，优先级高于后续规则） -
iptables -I INPUT -s 192.168.1.0/24 -j DROP：封整个 C 类网段 - 规则不会自动持久化——CentOS 6 用
service iptables save，Ubuntu/Debian 用iptables-save > /etc/iptables/rules.v4 - 别忘了验证：
iptables -L INPUT -n --line-numbers，确认规则在第几行 - 误封自己？提前开好另一条 SSH 连接，或用 console 登录——
DROP后连不上就只能物理/控制台恢复
用 nftables 替代 iptables（新系统推荐）
如果你用的是 CentOS 8+、Ubuntu 20.04+ 或较新内核，nftables 是默认防火墙，语法更简洁、性能更好。
- 编辑
/etc/nftables.conf，在ip filter input链里加一行：ip saddr 192.168.1.100 drop - 支持 CIDR：
ip saddr 2001:db8::/32 drop（IPv6 同样适用） - 加载配置：
nft -f /etc/nftables.conf；查看当前规则：nft list chain ip filter input -
nft不依赖外部保存命令，改完文件 reload 即生效，但需确保nftables服务已启用（systemctl enable nftables） - 注意：
iptables和nftables不能混用，旧规则可能被清空——先iptables -F再切换
通过 /etc/hosts.deny 限制特定服务（简单但局限）
只影响使用 libwrap 的服务（如默认编译的 sshd），不碰网络栈，也不拦非 TCP Wrappers 服务（比如 Nginx、MySQL 默认不走这个路径）。
- 写法必须严格：
sshd: 192.168.1.100（冒号后有空格也报错） - 支持通配：
sshd: 192.168.1.匹配所有以该前缀开头的 IP；ALL: 192.168.1.0/255.255.255.0也合法 - 优先级规则：先查
hosts.deny，再查hosts.allow；若两者冲突，hosts.allow里的条目会覆盖deny（即白名单优先） - 修改后立即生效，无需重启服务——但已建立的连接不受影响
- 验证是否生效：
sshd -T | grep -i usepam，输出含usepam yes且系统装了libwrap才真正起作用
在 Nginx 中限制 IP（仅限 HTTP/HTTPS 流量）
这不是防火墙，是应用层过滤。适合做业务侧黑白名单，比如后台管理路径只允某些运维 IP 访问。
- 在
location块里写：allow 203.0.113.25;，然后必须跟deny all;（顺序不能反，否则deny all会提前终止匹配） - 支持 IPv6：
allow 2001:db8::/32; - 别用
if ($remote_addr = ...)做判断——Nginx 官方明确不推荐，易出逻辑错误 - 如果规则多，建议
include /etc/nginx/conf.d/ip_blacklist.conf;抽离管理 - reload 前务必
nginx -t：漏写deny all或语法错会导致整个 location 无法访问
实际操作时最容易忽略的一点：没有确认目标服务是否真的走你设的那层过滤。比如你只在 hosts.deny 封了 sshd，但对方用的是 Dropbear 或自编译 OpenSSH（没链接 libwrap），那就完全无效；又比如你在 Nginx 里 deny all，但攻击者直接连数据库端口，照样畅通无阻。真正的防护得层层设防，而不是只靠一个配置文件。
