🧩 问题描述

线上生产环境中，Supervisor 用于守护多个 PHP 脚本任务（共计 310 个）。这些脚本长期运行，一直有正常的日志输出。然而在某天突然发现：

• 某任务的日志输出中断；
• 执行 supervisorctl status 显示任务状态为 RUNNING，没有异常；
• 但实际进程未运行、无任何日志产出；
• 尝试 supervisorctl restart 无效，任务仍然假运行，没有报错。

同时排查系统资源：

• 磁盘空间充足；
• CPU、内存无明显瓶颈；

• 任务脚本代码无更新，排除人为逻辑问题。

🛠️ Git 如何通过 VPN 代理拉取代码（支持 HTTP / SOCKS5）

在使用 Git 拉取或推送代码时，如果遇到网络不稳定、访问受限或者你正处于公司/学校网络中，挂 VPN 是一种常见的解决方案。但很多人挂上 VPN 后 Git 仍然无法正常使用，这是因为 Git 并不会自动走系统代理，需要手动配置。

本篇将教你如何让 Git 正确通过 VPN（Clash、V2Ray、Shadowsocks 等）代理拉取代码。

🌐 1. Git 使用 HTTP 代理

适用场景：

如果你使用的 VPN 工具（如 Clash、Clash Verge、Surfboard）提供 HTTP 代理端口，这是最推荐的方式。

🧾 全局设置代理

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

⚠️ 其中 127.0.0.1:7890 是 VPN 提供的 HTTP 代理端口，Clash 默认是 7890，请根据你使用的 VPN 软件调整。

🧽 取消代理

git config --global --unset http.proxy
git config --global --unset https.proxy

📌 目的

本文档旨在提供一套适用于常见 Linux 服务器（如 Ubuntu、CentOS）的主机安全加固方案，用于防止入侵、控制权限、保障生产环境稳定性。

🧱 基础安全配置

1. 禁用 Root 登录

# 编辑 SSH 配置文件
sudo vim /etc/ssh/sshd_config

# 设置
PermitRootLogin no
PasswordAuthentication no

启用仅限密钥认证，并重启 SSH 服务：

sudo systemctl restart sshd

2. 创建普通用户并授予 sudo 权限

adduser deploy
usermod -aG sudo deploy

3. 配置 SSH 公钥登录

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
vim /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

🔥 防火墙设置

Ubuntu (UFW)

sudo ufw default deny incoming
sudo ufw allow ssh
sudo ufw allow 80
sudo ufw allow 443
sudo ufw enable

CentOS (firewalld)

sudo firewall-cmd --add-service=ssh --permanent
sudo firewall-cmd --add-service=http --permanent
sudo firewall-cmd --add-service=https --permanent
sudo firewall-cmd --reload

🔒 文件与权限保护

锁定关键系统文件

chattr +i /etc/passwd
chattr +i /etc/shadow

设置目录权限

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

🧠 系统更新与补丁

Ubuntu

sudo apt update && sudo apt upgrade -y

CentOS

sudo yum update -y

可选安装自动更新服务：

sudo apt install unattended-upgrades

🧪 入侵检测与日志审计

启用 auditd 审计

sudo apt install auditd
sudo systemctl enable --now auditd

登录失败自动封禁（fail2ban）

sudo apt install fail2ban
sudo systemctl enable --now fail2ban

🔍 日志审计命令

# 查看登录历史
last

# 查看最近使用 sudo 的记录
grep 'sudo' /var/log/auth.log

# 查监听端口
ss -tulnp

# 查关键目录改动
find /etc -type f -mtime -1

☁ 云服务建议

✅ 总结

📎 参考资料

• Linux Security Checklist (CIS)
• Debian Security Guide
• fail2ban Documentation

在使用 supervisord 管理大量服务时，笔者遇到了一个奇怪的问题：当任务数量接近 200 个时，新的服务启动会失败，而 supervisor 本身没有明确报错信息。经过排查，最终确认是系统资源限制（如打开文件数、进程数）导致的问题，并通过调整配置成功解决。

💥 问题描述

当 supervisord 启动约 200 个任务之后：

• 新增的服务（program）无法正常启动
• 日志中没有明显报错，偶尔出现资源相关的提示
• 手动启动服务进程则正常运行

这表明 supervisord 自身没有问题，而是其子进程启动失败。

🔍 问题分析

Linux 系统对每个用户/进程的资源使用是有限制的。最常见的两个限制如下：

• NOFILE：一个进程最多可打开的文件描述符数量（包括 socket）
• NPROC：一个用户最多可创建的进程数

默认情况下，很多 Linux 发行版会把这两个值设得比较小（例如 1024 或 4096），这在管理大量服务时很容易触发限制。

✅ 解决方案

1. 修改 supervisor 的 systemd 启动限制

如果你使用 systemd 启动 supervisord（大多数现代 Linux 系统如此），需要修改或创建其服务文件：

sudo vim /etc/systemd/system/supervisord.service

在 [Service] 部分添加或修改以下内容：

[Service]
LimitNOFILE=8888
LimitNPROC=65535

保存后执行以下命令使配置生效：

sudo systemctl daemon-reexec
sudo systemctl daemon-reload
sudo systemctl restart supervisord

2. 修改用户级资源限制（可选）

为了彻底消除限制，建议同时修改系统用户限制配置：

编辑 /etc/security/limits.conf：

* soft nofile 8888
* hard nofile 8888
* soft nproc 65535
* hard nproc 65535

确保 PAM 模块启用资源限制，在 /etc/pam.d/common-session 或 /etc/pam.d/su 中包含如下内容：

session required pam_limits.so

3. 验证是否生效

切换到对应用户（如 supervisord 启动用户）下，运行：

ulimit -n   # 应为 8888
ulimit -u   # 应为 65535

如果仍不正确，尝试重新登录或重启服务器。

🛠 补充建议

在 supervisor.conf 或 program 配置块中，建议添加以下内容以便调试和稳定运行：

[program:your-service]
command=/path/to/your-service
autorestart=true
stderr_logfile=/var/log/supervisor/your-service.err.log

这样即使服务因资源限制失败，也能通过日志查看具体原因。

🧾 总结

在大量使用 supervisord 管理进程时，务必关注系统级资源限制。合理地设置 LimitNOFILE 和 LimitNPROC，可以让你的服务扩展更加平滑。

✅ 修改 systemd 启动参数
✅ 修改用户级 ulimit
✅ 验证配置是否生效
✅ 补充日志配置方便调试