WinSCP脚本批量上传AWS SFTP文件报错及单次上传问题排查

• 先查WinSCP版本兼容性：AWS SFTP对SFTP协议的部分扩展支持有限，老版本WinSCP可能没做适配。直接升级到最新稳定版，新版本一般会修复这类兼容性问题。

• 确认传输选项真的生效了：

  • 确保$transferOptions在调用PutFiles/SynchronizeDirectories时明确传进去了，比如：

    $session.PutFiles($localPath, $remotePath, $False, $transferOptions)
    

  • 检查代码里有没有其他地方改了$transferOptions的属性，比如后续又重新设置了权限或时间戳参数，把之前的配置覆盖了。

• 强制关掉所有可能触发SETSTAT的操作：
  除了已经设置的FilePermissions = $Null和PreserveTimestamp = $False，再加一行：

  $transferOptions.ResumeSupport.State = [WinSCP.ResumeSupportState]::Off
  

  断点续传功能也可能触发SETSTAT，AWS SFTP基本不支持这个特性。

• 检查会话全局配置有没有冲突：

  • 看看SessionOptions里有没有隐含的权限/时间戳设置，比如PreserveRemotePermissions这类全局选项，可能会覆盖传输级别的设置。
  • 用WinSCP图形界面手动配同一个站点，勾选“不设置权限”和“不保留时间戳”，手动传一个文件试试还报错不。如果图形界面正常，说明脚本里的配置没生效，导出图形界面的会话脚本对比，找差异点。

• 搞清楚为啥传一个就断开：

  • 加try/catch包裹上传操作，打印详细错误堆栈，确认是SETSTAT报错直接导致断开，还是自己写的错误处理逻辑主动关了会话。
  • 开WinSCP调试日志（$session.DebugLogPath = "C:\temp\winscp.log"），看日志里SETSTAT报错后的会话交互细节，是服务器主动断的，还是客户端主动终止的。

• 优化批量上传策略：

  • 用单个长会话传所有文件，别传一个就断开重连，减少会话压力。
  • 试试用SynchronizeDirectories代替PutFiles，同步模式的错误处理可能更适配批量场景。
  • 调低并发上传数（$transferOptions.MaxConcurrentTransfers），AWS SFTP有并发限制，太高可能被服务器断开，先设成1-2测试，再慢慢调。

• 确认AWS SFTP端的配置：

  • 检查服务器角色权限，确保对目标路径有写入权限（虽然文件传成功了，但权限配置异常可能引发后续报错）。
  • 确认AWS SFTP用的存储服务（S3/EFS）有没有特殊配置，比如S3的权限模型和传统SFTP不一样，WinSCP的权限设置操作本来就不适用，得确保脚本完全跳过这些操作。

内容的提问来源于stack exchange，提问作者squashjunkie