iptables owner模块不能可靠限制特定服务外连，仅支持OUTPUT链按UID/GID/PID匹配；systemd服务（如nginx、redis）因UID上下文不可靠，应改用IPAddressDeny或专用UID+--uid-owner方案。
直接说结论：iptables 的 owner 模块不能可靠限制“特定服务”的外连端口权限，因为它不支持按服务名、进程名或 systemd 服务单元匹配，只能按UID/GID 或 PID作用于 OUTPUT 链——而绝大多数正式部署的服务（如 nginx、php-fpm、redis）都由 systemd 托管，其 UID 上下文在 OUTPUT 链中不可靠或被切换，规则大概率失效。
真正可行的做法，是把“服务”转化为“以专用 UID 运行的进程集合”，再用 --uid-owner 控制。下面分三类场景说明怎么做、为什么这么设、以及关键避坑点。
先确认能不能用 owner 模块
运行这条命令验证基础支持：
iptables -m owner --help | grep -E "(uid-owner|gid-owner|pid-owner)"
有输出说明模块就绪；若报错“Unknown match 'owner'”，需先执行：
sudo modprobe xt_owner
注意：必须用 root 权限操作，且仅 OUTPUT 链有效，INPUT/FORWARD 链加了也无效。
对 PHP-FPM 类服务：绑定专用 UID + OUTPUT 规则
这是最典型、最可控的场景。PHP 本身无网络控制能力，但你可以让 php-fpm worker 固定以某个 UID 运行，再封其外连：
- 编辑 pool 配置（如 /etc/php/8.1/fpm/pool.d/www.conf），确保：
user = phpapp
group = phpapp
- 创建用户并查 UID：
sudo useradd -r -s /bin/false phpapp && id -u phpapp → 得到例如 123
- 加规则（顺序很重要）：
sudo iptables -I OUTPUT -m owner --uid-owner 123 -d 127.0.0.1 -j ACCEPT（放行本地）
sudo iptables -I OUTPUT -m owner --uid-owner 123 -p tcp --dport 3306 -d 10.0.2.15 -j ACCEPT（只许连指定 MySQL）
sudo iptables -A OUTPUT -m owner --uid-owner 123 -j DROP（其余全拒）
✅ 成效：所有 php-fpm worker 发起的新连接都会被拦截，包括 curl、file_get_contents、PDO 连接等。
对 systemd 托管服务（如 nginx、redis）：别硬套 owner，改用 IPAddressDeny
nginx 启动后实际以 root 进程监听，worker 可能降权，但 OUTPUT 链 UID 不稳定；直接加 --uid-owner www-data 在多数系统上会静默失败。
更稳的方式是利用 systemd 原生网络限制：
- 编辑服务单元（如 /etc/systemd/system/nginx.service.d/limit-net.conf）：
[Service]
IPAddressDeny=0.0.0.0/0
IPAddressAllow=127.0.0.1
IPAddressAllow=10.0.2.15
- 重载并重启：
sudo systemctl daemon-reload && sudo systemctl restart nginx
✅ 成效：从内核 socket 层禁止该服务建立任何外网连接，比 iptables 更底层、更可靠，且无需担心 UID 匹配问题。
临时调试单个进程：用 --pid-owner 快速验证
适合脚本、后台任务等生命周期短、PID 明确的场景：
- 查 PID：
pgrep -f "python3 sync.py" → 得到 4567
- 加规则（只影响该次运行）：
sudo iptables -A OUTPUT -m owner --pid-owner 4567 -p tcp --dport 443 -d api.example.com -j ACCEPT
sudo iptables -A OUTPUT -m owner --pid-owner 4567 -j DROP
⚠️ 注意：进程退出后 PID 失效，规则不会自动清理；适合调试，不用于长期服务。
