云主机无法上传文件怎么办?

中午十二点刚过，我正准备去吃午饭，公司内部群突然炸开了锅。运营部门的同事说，客户的一份重要数据怎么都传不上测试服务器，试了FTP、试了网页后台，甚至连最简单的SCP命令都报错。那份数据是客户下午三点开会要用的，时间一分一秒过去，所有人的情绪都开始急躁起来。

我放下筷子，远程登录到那台云主机。十分钟的排查之后，发现问题出在一个所有人都没想到的地方——根目录下的一个临时文件夹被误设了只读权限，而上传流程恰好需要往这个文件夹里写入临时文件。权限改回来之后，文件嗖的一下就传上去了。

这已经是我今年经手的第四个“无法上传”的案例了。每一次问题的表象都是“传不上去”，但每一次的根因都不一样。磁盘满了、权限错了、端口没开、文件太大了、程序超时了……这个问题的麻烦之处在于，它涉及的环节实在太多，任何一个环节出了岔子，都会表现为上传失败。本文把我这些年遇到的典型情况整理出来，希望能帮你在遇到同样问题时少绕几圈。

上传失败的几种脸孔，先别急着动手

当发现文件传不上去的时候，最忌讳的就是头脑一热开始各种尝试。先花一分钟观察一下失败的具体表现，这能帮你省下大把时间。

如果你看到的是“连接超时”或者“网络不可达”，问题多半出在网络链路上。可能是你本地网络不稳定，也可能是云主机的安全组压根没开放对应的端口。如果你看到的是“权限被拒绝”，那八成是目标目录的写权限没给对。如果你看到的是“磁盘空间不足”，那就更直白了——服务器上没地方放了。还有一种情况比较隐蔽，上传小文件一切正常，一传大文件就报错，这往往是服务端对请求大小做了限制。

每一种表现对应着完全不同的解决路径。看清楚症状再下手，比瞎猫碰死耗子要靠谱得多。

磁盘满了，最朴实也最常见的元凶

这是我最先会去查的一个方向，不是因为它有多复杂，而是因为它太好查了，而且发生的频率远比想象中高。

登录云主机，敲一条命令看看磁盘的使用情况。如果某个分区的使用率达到了百分之百，那问题基本上就找到了。上传文件需要在磁盘上写入数据，磁盘都满了，自然写不进去。

我之前处理过一个比较经典的案例。客户的网站每天都有用户上传头像，本来一切都挺正常的。有一天突然所有用户都传不了头像了，后台报错。我一查磁盘，系统盘满了。再一细看，发现是网站的访问日志文件写得太疯，三个月没清理，单个文件已经到了几十个GB。把旧日志归档删除之后，磁盘空间腾出来了，上传立马恢复正常。

还有一个容易被忽略的点是，有些文件虽然你删了，但磁盘空间并没有释放。这是因为有进程还在使用这个文件，操作系统得等那个进程把文件句柄关掉之后才会真正回收空间。如果你发现删了文件但空间没变，重启一下对应的服务就能解决。

权限迷宫，Linux世界里的通行证

Linux系统对权限的执着，有时候会让刚从Windows转过来的用户非常不适应。你觉得自己明明已经是root了，怎么还没权限写文件?

上传文件这件事，涉及到的不仅仅是目标目录的写权限。想象一下这个路径：/data/www/uploads/2024/。你想往2024这个目录里写文件，那么从根目录开始，data、www、uploads、2024这四个目录都必须对执行上传操作的进程有执行权限。任何一个中间目录缺了执行权限，进程都走不到最终的目标目录。

我遇到过一位客户，他在服务器上手动创建了uploads目录，然后大手一挥给了777权限。他觉得自己已经做得够彻底了，但上传还是一直失败。我帮他一看，www目录的权限是750，属主是root，属组是root，而Web服务器进程是用www-data这个用户跑的。www-data既不是root，也不在root组里，所以它连www目录都进不去，更别说往里面写文件了。

修复的方法很简单，要么把www目录的属组改成www-data，要么给其他用户加上执行权限。至于到底用哪种方法，取决于你对安全性的要求。

还有一类权限问题来自SELinux。这个东西的出发点是好的，增加了一层额外的安全控制，但它的规则比较复杂，有时候你文件权限明明已经给到位了，SELinux策略却还在拦着。判断是不是SELinux的问题很简单，临时把它关掉再试一次上传。如果关掉之后能传了，那就说明是SELinux的策略需要调整。注意，关掉只是为了测试，生产环境不建议永久关闭，正确的做法是根据审计日志来调整策略。

网络通道不通，安全组和防火墙的检查

云主机有个特点，它外面套了一层云平台的安全组，里面还有操作系统自带的防火墙。两道防线，任何一道没放行，流量都过不去。

你用的是FTP协议，那就要检查21号端口是不是开了。你用的是SFTP，那就要检查22号端口。如果你改过默认端口，就检查你自己设置的那个端口号。这里特别提一下FTP，这个协议比较特殊，它有主动模式和被动模式之分。被动模式下，除了21号控制端口之外，服务器还会开放一个端口范围用来传输数据。如果你只开了21号端口，能登录能看到目录列表，但传文件的时候就会卡住。解决办法是在安全组里把被动模式用到的端口范围也一起放开。

我建议大部分场景下直接用SFTP替代FTP。SFTP走的是SSH的22号端口，只需要开一个端口，而且传输过程是加密的，安全性好很多。少开一个端口就少一个需要排查的点，这是运维工作的朴素智慧。

大文件传不上去，八成是服务端限流了

如果你传几KB的小文件没问题，传几MB的大文件就报错，那问题大概率出在服务端对请求大小的限制上。

用Nginx做Web服务器的话，有个叫client_max_body_size的参数直接控制着允许的客户端请求体大小。默认是1MB，也就是说超过1MB的文件上传会被Nginx直接挡掉，连应用代码都到不了。修改这个参数之后记得重新加载Nginx配置。

后面还有一道关卡是PHP的配置。两个参数需要注意，upload_max_filesize控制单个上传文件的最大尺寸，post_max_size控制整个POST请求的最大尺寸。post_max_size需要设置得比upload_max_filesize稍微大一点，因为请求里除了文件本身可能还带别的表单字段。改完PHP配置别忘了重启PHP-FPM服务。

Java应用这边，Tomcat也有类似的限制，maxPostSize参数控制着POST请求的最大大小。Spring Boot应用还可以通过spring.servlet.multipart.max-file-size和max-request-size来单独配置。

超时设置，远距离传输的隐形杀手

这个问题在跨境传输或者移动网络环境下特别常见。你的文件很大，网速又不快，传着传着就断了，而且总是在同一个进度百分比附近断开。

这通常是某个环节的超时时间到了。Web服务器有超时设置，比如Nginx的proxy_read_timeout和send_timeout。PHP有max_execution_time和max_input_time。客户端也有自己的超时判断。任何一个环节的超时时间设得太短，上传过程就会在中途被强行掐断。

合理的做法是根据你的业务场景来设定超时时间。如果用户需要上传几百MB甚至上GB的文件，一两分钟的超时肯定是不够的。把超时时间适当调长，同时配合前端的上传进度显示，用户的体验会好很多。

对于特别大的文件，还有一个思路是改用分片上传。把一个大文件切成很多小块，一块一块地传，每块传完服务器给个确认，最后再合并。这样即使某一小块传失败了，也只需要重传那一小块，不用整个文件从头来过。云服务商的对象存储服务基本都提供了分片上传的功能接口。

FTP和SFTP的专属坑

如果你在用FTP或者SFTP上传，有一些它们特有的问题需要注意。

FTP的用户如果被限制在自己的家目录下，有时候会出现无法写入的情况。检查一下FTP服务器配置里的AllowWrite参数是不是开了。另外，被动模式的端口范围前面已经说过了，这里再强调一遍，因为实在太多人在这里栽跟头。

SFTP这边，如果你启用了Chroot功能把用户关在某个目录里，这个目录及其所有上级目录的权限要求非常严格——必须由root用户拥有，而且其他用户不能有写入权限。这个要求很苛刻，但这是出于安全考虑，防止用户逃出限制的目录。权限设置不对，SFTP可能连登录都登不了。

一个让人头疼的案例，排查了三个小时

去年有个客户的案例，我至今记忆犹新。他们的业务系统需要频繁上传PDF文件，最近一段时间上传功能时好时坏，有时候一次就成功，有时候要反复试好几次才能传上去。运维同事检查了磁盘、权限、安全组，全都正常，折腾了好几天毫无进展。

我介入之后，没有急着查配置，而是先在服务器上装了一个抓包工具，同时让同事触发一次上传操作。抓包的数据显示，上传过程中有几个数据包丢了，触发了TCP重传，但最终文件还是完整到达了。问题出在应用层，文件到了之后，应用需要做一个格式校验，这个校验过程在大文件上耗时较长，而Web服务器的超时时间设得刚好比这个耗时短了一点点。有时候校验跑得快，刚好在超时之前完成，上传就成功了;有时候校验慢了一点，超时先到了，连接被断开，浏览器就报错了。

把Web服务器的超时时间从30秒调大到120秒之后，问题彻底解决。这个案例给我的教训是，上传问题不总是“能不能传”，有时候是“传了能不能被正确处理”。排查的时候要把眼光放远一点，不要只盯着传输环节。

日常维护，让上传问题少发生

与其每次出了问题再救火，不如平时多花点心思做预防。

建立磁盘空间的监控是最基本的。设置一个告警，当磁盘使用率超过百分之八十的时候通知你，这样你有充足的时间去清理或者扩容，而不是等到写满了才被动应对。

关键目录的权限可以定期做一次巡检。特别是Web应用的上传目录和临时目录，确保它们的权限设置符合预期，没有被意外的操作改乱。

对于Web上传场景，我强烈建议在应用层面增加更明确的错误提示。磁盘满了就告诉用户“服务器空间不足”，文件太大就告诉用户“文件超过大小限制”。这样用户能第一时间知道发生了什么，而不是只看到一个红色的“上传失败”几个字。

总结

云主机无法上传文件，原因可能出在网络、权限、磁盘、配置、超时等任何一个环节。面对这个问题，不要慌乱，先观察失败的具体表现，然后按照从外到内、从简单到复杂的顺序逐一排查。

先从磁盘空间和目录权限这些最直观的入手，不行就检查安全组和防火墙的端口设置。如果是网页上传，留意一下Nginx和PHP的各种大小限制。如果传输过程总在中途断开，去看看各个超时参数是不是设得太短了。FTP和SFTP用户要特别注意被动模式和Chroot目录的特殊要求。

上传功能看起来简单，背后的链路其实很长。但只要掌握了这套排查思路，大多数问题都能在半小时之内定位到根因。