Limit指令通过CPUQuota、MemoryMax、TasksMax、LimitNOFILE等参数限制服务资源使用，控制单个服务失控后的破坏半径，防范DoS风险。
使用 Limit 指令（实际为 systemd 中的资源限制机制，如 LimitCPU、MemoryLimit 等）可有效约束服务进程的资源使用，降低其被恶意利用导致系统级拒绝服务（DoS）的风险。关键不在于“完全阻止攻击”，而在于“限制单个服务失控后的破坏半径”。
明确可用的 Limit 类型及作用
systemd 通过 .service 单元文件中的 [Service] 段落支持多种资源限制指令，常见且实用的包括：
-
CPUQuota=：限制服务在单位时间内最多使用 CPU 的百分比（如
CPUQuota=20%表示最多占用 1 个逻辑 CPU 的 20%，即约 0.2 核）。比LimitCPU更精准，推荐优先使用。 -
MemoryMax=：硬性内存上限（如
MemoryMax=512M），超出时内核会 OOM-kill 该服务进程。这是防内存耗尽型 DoS 的核心手段。 -
TasksMax=：限制服务能创建的最大进程/线程数（如
TasksMax=100），防止 fork 炸弹类攻击或连接数失控。 -
LimitNOFILE=：限制打开文件描述符数量（如
LimitNOFILE=1024），可缓解高并发连接耗尽系统句柄的问题。
修改服务单元文件并重载配置
以限制 nginx 服务为例：
- 执行
sudo systemctl edit nginx.service（推荐方式，避免直接修改原始文件）； - 在编辑器中输入：
[Service] CPUQuota=30% MemoryMax=384M TasksMax=64 LimitNOFILE=2048
保存退出后，运行 sudo systemctl daemon-reload 使配置生效；
最后重启服务：sudo systemctl restart nginx。
注意：若服务由模板实例（如 httpd@.service）启动，需对对应实例（如 httpd@site1.service）单独设置，或在模板文件中统一定义。
验证限制是否生效
限制配置后务必验证，避免误配导致服务异常：
- 查看当前应用的限制值：
systemctl show nginx.service | grep -E "(CPU|Memory|Tasks|NOFILE)"； - 实时监控资源使用：
systemd-cgtop（按 Ctrl+T 切换树状视图），重点关注/system.slice/nginx.service所在行； - 模拟压力测试（如用
ab或wrk高并发请求），观察服务是否在达到MemoryMax或TasksMax后被自动终止（journal 日志中会出现OOM killed或tasks limit exceeded提示）。
配合其他防护形成纵深防御
仅靠 Limit 指令不能替代网络层或应用层防护：
- 前端应部署反向代理（如 Nginx、Traefik）启用连接速率限制（
limit_req）、连接数限制（limit_conn）； - 内核参数调优：如
net.core.somaxconn、net.ipv4.tcp_max_syn_backlog防 SYN Flood； - 启用
systemd的RestartSec=和StartLimitIntervalSec=防止服务频繁崩溃重启（防 crash-loop DoS）； - 敏感服务建议运行在独立 cgroup v2 层级下，并启用
ProtectSystem=strict、RestrictAddressFamilies=等安全加固选项。
