CentOS SFTP上传失败的排查全过程（含代理干扰分析）

背景描述

在一台 CentOS 服务器上部署了 SFTP 服务，基于 OpenSSH 默认的 sftp-server 运行，无额外安装 vsftpd 等传统 FTP 服务。系统中存在多个用户账号：

• 用户 xx：使用 MobaXterm 可正常上传文件；
• 用户 xxx：连接正常，但上传始终失败。

目标是找出 xxx 无法上传文件的根本原因。

---

初步排查：服务存在但无法上传

通过以下命令确认服务器正在运行 SFTP 服务：

ps aux | grep sftp

输出：

xxx  /usr/libexec/openssh/sftp-server
xx   /usr/libexec/openssh/sftp-server

说明 SFTP 会话已正常建立，且 sftp-server 启动成功，不存在服务层级的问题。

---

权限与配置审查

1. Home 目录权限

使用以下命令检查目录所有权和权限：

ls -ld /home/xx

结果显示所有权属于 xxx，权限为 755，不影响写入。

2. SSH 配置文件排查

检查 /etc/ssh/sshd_config，确认：

• 未对 xxx 设置 DenyUsers；
• 未使用 ChrootDirectory 限制；
• 未启用 internal-sftp 或强制 ForceCommand 等影响写入行为的配置。

---

深层线索：曾中断过上传连接

用户回忆下午使用 另一个 SFTP 工具（如 WinSCP）上传时中断，怀疑残留会话影响后续上传。

使用以下命令检查旧会话：

ps aux | grep sftp

发现旧会话仍在，尝试 kill -9 <pid> 后无果，问题依旧。

---

关键突破：代理干扰识别

用户回忆 xxx 账号下使用了 mihomo 代理。其代理脚本为：

mihomo() {
    case $1 in
    on)
        export http_proxy=http://127.0.0.1:7890
        export https_proxy=$http_proxy
        export NO_PROXY="localhost,127.0.0.1,::1"
        ~/bin/mihomo -d ~/.config/mihomo/ -f ~/.config/mihomo/config.yaml &
        ;;
    off)
        unset http_proxy
        unset https_proxy
        pkill -9 -f mihomo
        ;;
    esac
}

由于 mihomo 启动了 Clash 核心，可能以 TUN/Redir 模式劫持了全部 TCP 流量，包括 SFTP 数据传输，导致：

• 连接建立正常（SSH端口22未被拦）；
• 上传过程被代理劫持，无法稳定完成文件写入。

---

问题定位：代理干扰上传行为

验证方法：

• 关闭代理（mihomo off）后再试上传；
• 上传立即恢复正常，验证干扰源为代理。

---

解决方案

方法一：扩大 NO_PROXY 范围

将上传目标 IP/域名加入环境变量：

export NO_PROXY="localhost,127.0.0.1,::1,xx.xx.xx.xx,my-server.local"

方法二：修改 Clash 配置绕过上传目标

在 ~/.config/mihomo/config.yaml 中加入：

rules:
  - IP-CIDR,xx.xx.xx.0/24,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  - MATCH,PROXY

确保上传目标走直连，避免上传失败。

---

总结

这次排查历程说明，在多用户 Linux 环境中：

• 问题不一定在 FTP/SFTP 服务；
• 用户级代理环境亦可能成为故障源；
• 通过会话、权限、配置、网络链路逐步排查，最终定位并解决问题。

---