1. 为什么我最后还是回头用了 Windows Server 自带的 FTP先说个真实场景。去年我给一家小公司搭文件共享服务老板要求很简单销售部每个人一个账号各看各的报价单行政部能看所有人的公共资料。我第一反应是装 FileZilla Server毕竟开源免费、配置界面友好网上教程一抓一大把。结果装完没两天就出问题了——FileZilla 的 Windows 服务版在某些 Windows Server 版本上对中文路径和权限继承处理得不够干净加上公司用的是云服务器被动模式端口没放干净销售那边一会儿能连一会儿不能连折腾了一周。后来我干脆把 FileZilla 卸了直接用 Windows Server 自带的 IIS FTP 角色。一周的坑瞬间清零。这件事让我重新认识了自带 FTP 的价值它确实不是功能最全的但它是和 Windows 系统集成度最高的。账号体系直接复用本地用户或 AD 域用户NTFS 权限怎么设它就怎么执行防火墙规则装了角色之后系统自动生成不存在第三方软件被系统安全策略拦了半天下的情况。这篇文章我就把这套自带 FTP 的完整搭建流程、权限隔离方案、被动模式端口绕坑方法、常见报错排查逻辑按我实际操作的顺序全部写出来。适合三类人看一是公司内网要快速搭文件共享的运维二是在云服务器上搭 FTP 但一直连不上的新手三是想搞清楚 Windows 账户体系和 FTP 权限关系的人。一句话总结它的定位如果你只需要稳定、基础、和安全策略不打架的 FTP 服务Windows Server 自带的是最优解。别嫌它界面老别嫌它功能朴素稳定压倒一切。2. 安装前必知不同版本系统的差异和一个隐藏坑2.1 各版本对应关系和底层组件Windows Server 从 2008 到 2022FTP 服务本质都是 IIS 的一个子角色底层是同一个 ftpsvc 服务但不同版本的 IIS 内核版本不同配置入口的细节也有差别。我整理了一个对照表省得你装完发现界面和教程对不上系统版本IIS 版本FTP 角色安装入口备注Windows Server 2008 R2IIS 7.5服务器管理器 → 角色 → Web 服务器(IIS) → FTP 服务器老系统FTP 用户隔离配置在 IIS 6 管理器里Windows Server 2012 / 2012 R2IIS 8.0 / 8.5服务器管理器 → 添加角色和功能 → Web 服务器(IIS) → FTP 服务器界面开始统一到 IIS 管理器Windows Server 2016 / 2019IIS 10服务器管理器 → 添加角色和功能 → Web 服务器(IIS) → FTP 服务器目前最常见的生产环境Windows Server 2022 / 2025IIS 10同上2025 还在预览阶段时我就测过FTP 部分没变化这里有个隐藏坑值得单独说Windows Server 2012 之后的系统如果只装了 FTP 角色但没装完整的 Web 服务器(IIS) 角色FTP 的某些管理单元可能加载不正常会报Cannot read configuration file之类的错误。原因是 FTP 服务依赖 IIS 的配置存储结构applicationHost.config而这个文件是 Web 服务器角色安装时才生成的。所以安装时别只勾 FTP先把 Web 服务器(IIS) 整个角色勾上再勾 FTP 服务FTP 服务在角色服务列表里展开 Web 服务器 → FTP 服务器 就能看到。2.2 安装前必须做的三个准备动作第一个是规划目录结构。我见过太多人把 FTP 根目录直接指到 C 盘某处结果磁盘满了系统崩了。我的习惯是独立分区建D:\FTPRoot下面分Public公共区和Users用户区这样后面做用户隔离时路径清晰好排错D:\FTPRoot ├── Public # 公共共享区所有人可读指定人可写 └── Users # 用户隔离区每个用户一个子目录 ├── ZhangSan ├── LiSi └── WangWu第二个是确认系统防火墙没被第三方安全软件接管。云服务器尤其爱出这种问题——你明明开了防火墙端口但服务器厂商自带的安全 Agent 把流量拦了。我在腾讯云和阿里云上都遇到过系统防火墙规则正常但外网就是无法建立连接最后查出来是云盾 Agent 的防火墙插件默认拒绝了非备案端口。建议安装前先看一眼服务器上有哪些安全软件在跑必要时先把它们对 FTP 端口的拦截规则清掉。第三个是确定账号策略。内网小规模场景少于 20 个账号直接用本地用户就行域环境批量开会话用 AD 账号更合理。但不管哪种都要提前和需求方确认用户要不要改密码要不要限制只能访问自己的目录公共区谁能写入2.3 安装操作的完整截图流程文字版以 Windows Server 2019 为例操作路径如下打开服务器管理器点右上角管理→添加角色和功能。安装类型选基于角色或基于功能的安装下一步。服务器选择选当前服务器下一步。勾选Web 服务器(IIS)弹窗提示添加所需功能点添加功能下一步。在角色服务列表里展开FTP 服务器勾选FTP 服务和FTP 扩展性下一步。确认安装等待完成。安装完成后可以在服务管理器里看到FTP Publishing Service或者叫ftpsvc已经在运行启动类型是自动。如果 2012 R2 以前的系统没有自动启动手动设置成自动并启动一次否则重启服务器后 FTP 不会自动恢复。3. 创建 FTP 站点从物理路径到绑定的每个选项都别瞎填3.1 站点创建的完整过程和参数解释装完角色后打开 IIS 管理器在管理工具里或在服务器管理器点工具→Internet Information Services (IIS) 管理器左侧连接树里展开服务器名右键网站→添加 FTP 站点。这一步会弹出一个向导填三个关键信息站点名称我建议直接叫FTP-Production这种带环境标识的名字别叫FTP这种容易和自己的测试站点混淆。物理路径填你第一步规划的目录比如D:\FTPRoot。注意这里填的是根目录后面用户隔离和权限都在这个根目录下细分。接下来是绑定设置这一步坑最多IP 地址默认是全部未分配意思是不限制 IP。如果你服务器有多个网卡建议明确指定内网 IP避免外网网卡也暴露 FTP 端口被扫。端口默认 21一般不用改。有些安全要求高的场景会改成非标端口比如 2121。改完记得到防火墙放行对应端口。SSL 设置系统没有配证书时选无 SSL如果你有证书哪怕是自签名选允许 SSL而不是需要 SSL——后者的意思是所有客户端必须用 FTPS普通 FTP 客户端连不上会让你排查到怀疑人生。然后是身份验证和授权信息。注意这个界面分两页第一页的身份验证选基本Basic Authentication匿名访问在生产环境建议直接关闭。FTP 的基本就是明文传账号密码内网可以用省事但如果你在公网用强烈建议配合 SSL 一起用否则密码就是裸奔。第二页的授权里允许访问选指定角色或用户组填你准备用来登录的 Windows 账号或组名权限选读取还是读取和写入这里建议选读取具体写入权限到每个用户目录的 NTFS 权限里再定FTP 授权别管太细越细越乱。3.2 为什么说授权规则和 NTFS 权限要分开看很多人在这里死磕FTP 站点的授权规则明明给了某个用户读取和写入但对方登录后还是不能上传。原因是你忽略了 NTFS 权限。FTP 授权规则和 NTFS 权限是双门关系FTP 授权决定能不能进这个门NTFS 权限决定进了门能碰哪些东西。两个门都要过其中一个拒绝就白搭。我的建议是FTP 站点的授权规则统一设为指定用户或用户组 读取和写入所有精细化控制全部交给 NTFS。这样做的原因是 IIS 管理器的授权规则叠加逻辑比较绕允许多个用户时是或的关系拒绝是与的优先级更高一旦规则多了很难一眼看出某个用户实际有什么权限而 NTFS 权限右键属性里看得清清楚楚。具体 NTFS 权限设置给一组参考目录需要访问的人NTFS 权限建议D:\FTPRoot任何人列出文件夹/读取只给根目录下落点D:\FTPRoot\Public所有人读取默认上传目录要另建一个子目录给写入D:\FTPRoot\Users\ZhangSanZhangSan完全控制仅限本人这是隔离私有目录D:\FTPRoot\Users\LiSiLiSi完全控制仅限本人NTFS 修改路径右键目录 → 属性 → 安全 → 编辑 → 添加用户/组按需勾选权限。3.3 一个容易被忽略的细节新建站点后别忘重启 FTP 服务改完 FTP 站点配置或授权规则后IIS 管理器通常会提示更改可能需要重新启动 FTP 服务才能生效。但这个提示有时候不弹我建议养成习惯每改完一组关键配置就在命令行执行一次net stop ftpsvc net start ftpsvc或者用 PowerShellRestart-Service -Name ftpsvc -Force这个操作基本无风险耗时不超过三秒但能避免很多我明明改了为什么还是不行的灵异问题。4. 用户隔离配置让每个账号只能看到自己的目录4.1 三种隔离模式的取舍逻辑FTP 用户隔离是多人共用一台 FTP 时最核心的功能。IIS 的 FTP 角色支持三种模式在 IIS 管理器里右键 FTP 站点 → FTP 用户隔离你会看到三个选项不隔离用户所有人登录后都看到 FTP 根目录共享一片天地。适合公共文件交换不适合部门隔离。用户名每个用户自动进入以其用户名命名的子目录。选择这个模式时根目录下的目录结构必须是D:\FTPRoot\LocalUser\用户名注意中间有个LocalUser层级这是 IIS 的固定逻辑。用户名和域适用域环境路径变成D:\FTPRoot\LocalUser\域名\用户名复杂一些但域用户登录时会自动按域\用户名隔离。实际项目里我 90% 的情况用用户名模式就够了没有域环境就别给域模式添乱。4.2 配置文件级别的基础隔离 vs 管理器级别的物理隔离这里有个知识点我必须讲透因为网上很多教程会混在一起IIS 的用户隔离有两种实现层级一种是配置文件级别的隔离简化版不需要额外创建目录FTP 根目录就是所有人共享的家管理员在FTP 授权规则里针对不同用户设置不同权限但目录本身不隔离。一种是物理目录级别的隔离进阶版配合LocalUser\用户名的物理目录结构用户登录后直接被 chroot 到自己的目录中看不到别人也看不到公共区。如果你需要每个用户登录后只能看到自己文件夹不能看到别人就必须选物理目录级别也就是用户名隔离模式。注意选择了这个模式后匿名账号访问会被映射到IUSR账户它的目录是D:\FTPRoot\LocalUser\Public如果你关闭了匿名访问这个目录不需要建也可以。完整的目录结构应该长这样D:\FTPRoot ├── LocalUser # 用户隔离目录固定前缀勿改 │ ├── Public # 匿名用户目录可留空/不存在 │ ├── ZhangSan # 账号 ZhangSan 登录后只能看到这里 │ ├── LiSi │ └── WangWu └── 其他公共目录 # 不建议放在根下避免绕过了隔离逻辑建好目录、把每个目录的 NTFS 权限赋给对应用户见前面表格再切回FTP 用户隔离界面勾选用户名并应用测试时用 ZhangSan 登录就只能看到空目录。如果看不到你的目录八成是路径写错了或缺了LocalUser这一层。4.3 隔离模式下如何开放公共共享区业务需求里总是既要隔离又要公共区。两种方案方案一把公共区放到LocalUser之外比如D:\FTPRoot\Public然后用授权规则给所有用户读取权限。但这样做的结果是用户登录后FTP 客户端的界面里会出现两个来源不同的目录如果你用 Windows 资源管理器连接会看到LocalUser和Public两个文件夹各是各的区分清楚但有点丑。方案二在LocalUser里建一个Public目录并让所有账号对它都有读取权限。这时候用户登录后只看到一个Public和自己当前的根目录看起来像是一个逻辑空间底下既有公共文件又有个人空间。但注意LocalUser\Public是系统保留给匿名用户的目录如果你关闭了匿名访问将其用作公共区没问题但一旦你某天开启匿名行为可能不符合预期。从运维角度我倾向于方案二因为它对用户的视觉干扰最小符合一个 FTP 地址解决所有事的认知习惯。只要在建目录时把LocalUser\Public的 NTFS 权限设为Everyone 读取、指定授权者写入就能实现。5. 防火墙、被动端口和云安全组九成外网连不上的根源在这里5.1 主动模式 vs 被动模式FTP 连接失败的分水岭新手在云服务器上搭完 FTP本地测试正常拿到外网测就无法与服务器建立连接。问题几乎都出在 FTP 数据连接的端口上。FTP 用两个连接21 号端口是控制连接发指令、输账号密码而真正传数据时用的是另一个端口。主动模式下服务器主动回连客户端的随机端口这在 NAT 和云环境下基本死路一条被动模式下客户端主动连服务器的某个数据端口但那个数据端口不确定必须在防火墙里开放一个端口范围。Windows 自带的 IIS FTP 默认的被动端口范围是动态的具体范围随系统不同2016 通常是 1024–65535 的部分端口直接全开等于裸奔只开 21 端口又会出现一种诡异状况能登录能列目录但一上传/下载就卡死日志里看不到任何错误。这就是典型的被动端口没放行。5.2 在 IIS 里固定被动端口范围右键 FTP 站点 → FTP 防火墙支持在这里可以设置防火墙的外部 IP 地址如果服务器在 NAT 后面比如云服务器有内网 IP 和公网 IP 两层填公网 IP。数据通道端口范围填一个固定范围比如3000-3050意思是数据连接只在这些端口里选。范围大小取决于并发上传下载数50 个端口够普通办公用了。设置完点应用然后去系统防火墙放行入站规则TCP 端口21和3000-3050。放行的具体路径打开Windows Defender 防火墙 → 高级设置 → 入站规则 → 新建规则 → 端口 → TCP → 特定本地端口填21,3000-3050→ 允许连接 → 勾选域/专用/公用。推荐顺手把规则命名为FTP-Service-Ports以后排查时一眼认出。还有一个更省事的办法在添加角色和功能后系统会自动创建名为FTP Server (FTP 流量进)的规则放行的是 21 口但被动端口通常不会自动放行。所以上面的手动步骤省不了。5.3 云安全组的双重检查这是另一个高频坑阿里云、腾讯云、AWS 这些云平台除了系统自带防火墙还有一层安全组规则。你系统内放行了 21 和 3000-3050但是安全组没放行对应端口外网照样连不上。检查方法很简单登录云厂商控制台 → 找到实例 → 安全组 → 入方向规则确认有这么两条TCP 21 来源 0.0.0.0/0 TCP 3000-3050 来源 0.0.0.0/0不要只写 21只放 21 的话你永远复现出能登录不能传文件的问题。来源按需限制办公场景可以写成公司出口 IP安全要求高的话可以只放开特定 IP但那样客户端漫游比如员工在家连就会受限。另外提一件小事如果公司里有硬件防火墙或路由器做端口映射还要在路由器里把 21 和 3000-3050 都映射到服务器内网 IP。只映射 21 的人一定会在传文件时踩数据端口不通的坑。我做过的项目里凡是外网连不上的案例十有八九卡在这一层系统防火墙和安全组都放行了唯独路由器端口映射只做了 21。5.4 验证端口是否放行的最快方法装一个 telnet 客户端Windows 10/Server 2019 自带的是可选项在启用或关闭 Windows 功能里勾选Telnet 客户端然后命令行测试telnet 你的服务器公网IP 21如果黑屏或显示 220 欢迎信息说明控制端口通了。测数据端口就得靠实际传文件验证了。这里我建议用 FileZilla 客户端它有详细的调试输出能直接看到PASV响应里返回的端口号对照一下是不是落在你设置的 3000-3050 范围内响应: 227 Entering Passive Mode (x,x,x,x,p1,p2)。其中p1*256p2就是数据端口号。如果看到的是某个 5 位大数字比如 50782说明 IIS 的被动端口范围设置没生效回到FTP 防火墙支持里检查。6. 客户端连接、乱码和真实排错记录501、530、553 逐个拆解6.1 用什么样的客户端最省心Windows 资源管理器可以直接访问 FTP输入ftp://IP也可以直接在资源管理器地址栏输ftp://用户名IP。优势是零安装劣势也是明显的老版本资源管理器对 UTF-8 中文支持不佳连接后文件名会出现乱码另外资源管理器不做断点续传传大文件断了就重来。我日常用的组合是测试连通性用系统自带的ftp命令正式使用推荐 FileZilla Client 或 WinSCP。FileZilla 转 UTF-8 的设置在站点管理器 → 字符集 → 强制 UTF-8强制后中文文件名基本不会再乱。WinSCP 对中文路径的支持也一直很稳定而且它对 FTPSFTP over SSL/TLS支持得更顺手适合那些要求传输加密的项目。顺嘴提一句如果你在该服务器上已经有终端管理通道其实还可以考虑配套开 SFTP走 SSH但这超出了本篇文章主题按下不表。6.2 高频报错 ERIC 501、530、425、553 的排查思路我把生产环境里最常碰见的几个 FTP 报错按我实际排查的链路整理一份速查表。每个错误的排查路径我都踩过说句实话大部分问题根本不是配置复杂而是你脑子里的模型和系统实际行为对不上。报错含义排查优先级530 User cannot log in认证失败1. 账号密码对不对2. 该 Windows 账号是否有登录 FTP 的权限IIS 授权规则里是否添加了该账号3. 是否被安全策略锁定比如账户锁定阈值501 Invalid parameter or argument参数错误常见的场景是 FileZilla 发送 UTF-8 指令服务器无法识别或 FTP 命令格式不规范。对 IIS FTP 来说先把客户端字符集强制为 UTF-8再测一次。425 Cannot open data connection数据连接失败被动端口范围未放行或者防火墙/安全组只开了 21。参考第 5 节完整检查。另一个原因是客户端在 NAT 后面使用主动模式而服务器无法回连客户端换成被动模式试试。553 Cant open that fileNTFS 权限不足用户没有对该目录的写入权限右键目录看安全里有没有该用户勾上写权限。也检查根目录是否设置了只读属性。227 Entering Passive Mode 返回端口不在范围内被动范围未生效回 IIS 的FTP 防火墙支持重新确认保存然后重启 ftpsvc。6.3 一个完整排错实例能登录但一列目录就无响应有一次给客户部署完客户端 FileZilla 能输入账号密码登录但一进目录就卡在LIST命令上服务器端日志一片空白。我当时的第一步操作是检查 IIS 的FTP 防火墙支持——被动端口范围已经填了 3000-3050。第二步查系统防火墙规则在允许连接。第三步上云控制台安全组也放行了 TCP 21 和 3000-3050。到这里三层都通了但问题依旧。后来我发现客户用的是公司内网专线服务器本身在公司机房的 NAT 后面而 IIS 无法感知自己公网 IP被动模式响应包里的 IP 是内网地址比如 192.168.1.10客户端拿到这个内网地址自然连接不上。这就是FTP 防火墙支持里那个防火墙的外部 IP 地址字段派上用场的场景。我在那里填上服务器对应的公网映射 IP或者路由器的外网 IP保存重启 ftpsvc再测227响应里的 IP 变成了公网地址目录列表秒开。这个案例如果只看错误现象一定会去折腾防火墙其实根源在 FTP 协议自身对 NAT 环境不友好的宿命。凡是在 NAT 后面部署 FTP一定要检查被动模式下响应包里的 IP 到底是公网还是内网。锦囊就是抓响应的 227 行或者直接在客户端日志里看 PASV 返回的地址段。6.4 额外提醒UTF-8 与中文乱码的处理2019 及以后版本的 Windows ServerIIS FTP 默认支持 UTF-8老版本默认分两种IIS 8.5 之后默认开IIS 7.5 默认没开。如果客户端连上了但中文显示乱码按这个顺序做在 FTP 站点根目录放一个测试文件文件名写测试_中文.txt客户端连上看是否正常。如果乱码在客户端强制 UTF-8FileZilla 在站点管理器 → 字符集 → 强制 UTF-8。如果客户端不让你改字符集那么去设备上给系统装适用于 UTF-8 的语言支持控制面板 → 区域 → 管理 → 更改系统区域设置 → 勾选 Beta 版: 使用 Unicode UTF-8 提供全球语言支持。但这个操作会影响整个系统的编码行为非必要不建议开尤其在英文版系统上部署生产环境时要谨慎。我在 2012 R2 上见过一个奇葩案例服务器中文文件名称显示正常但客户端上传的中文文件名到服务器上变成乱码。后来查明是客户端 FileZilla 是远古版本默认用本机 ANSI 编码上传服务器又没开 UTF-8 校验两边就互相看不懂了。升级客户端到新版后问题消失。所以遇到乱码先问客户端再动服务器。7. 权限叠加、磁盘配额和备份运维视角的经验补全7.1 用户权限叠加和继承的暗坑IIS 授权规则是按用户组、用户、匿名分层的本地管理员组默认对 FTP 根目录有完全控制权限。听起来没问题但如果你把某个用户同时添加到多个组里而多个组的授权规则有差别最终生效的权限是并集——也就是说只要任何一个组给了写入该用户就能写。听起来很宽松对不对其实很容易造成越权。比如你把销售部所有人的账号加入了Sales组并给了写入权限但某个销售离职了你只在 IIS 授权规则里删除了该用户本人的规则却忘了他还属于 Sales 组结果他依然能上传文件。我的管理习惯是IIS 授权规则里只维护组级别的规则个人账号一律不加单独规则。用户入职就加入对应组离职就从组里移除。这样权限管理出口只剩一个AD 用户组或本地组干净利落。7.2 磁盘配额不装第三方也能限制用户空间FTP 爆盘是生产事故的高发源。Windows Server 自带的文件服务器资源管理器(FSRM) 可以针对目录设置配额限制某个文件夹的最大体积。用法服务器管理器 → 文件和存储服务 → 卷 → 右键磁盘 → 配置配额。在文件服务器资源管理器里点击配额管理 → 创建配额路径选择用户隔离目录配额比如 5GB超过时就拒绝写入。这个功能本身不是给 FTP 专门设计的但对 FTP 用户目录的容量控制非常好用不用装第三方磁盘配额软件。唯一要注意的是配额是基于卷上路径的如果LocalUser\ZhangSan这个目录跨卷比如目录被重定向到别的盘配额要针对对应卷单独建。跨卷配额的那种复杂度普通项目绕开就好直接保证一个盘符承载所有 FTP 数据简单可靠优先。7.3 备份思路FTP 数据要备FTP 配置也别漏FTP 站点数据文件当然要纳入日常备份但容易被忽略的是 IIS 配置文件C:\Windows\System32\inetsrv\config\applicationHost.config。这个文件记录了所有 FTP 站点、绑定、授权规则、隔离模式。服务器崩了重装系统后只要数据盘还在把这个文件还原到新系统对应位置FTP 站点配置就能整体恢复不用一个个重建。我用的是 PowerShell 定期复制这个文件到备份目录Copy-Item -Path C:\Windows\System32\inetsrv\config\applicationHost.config -Destination D:\FTPBackup\ -Force再加一条计划任务每天凌晨跑一次顺手把 FTP 数据目录的差异备份比如 robocopy 增量也配上。这里不展开整个备份方案了但哪怕只做了这么一条命令也比裸奔强一百倍。7.4 安全加固的三个建议第一非必要别开启匿名访问在 IUSR 账号下办公文件裸露成本很低但风险太高。第二在公网部署时建议把 FTP 端口改成非标端口比如 2121配合防火墙只放行特定源 IP能挡掉大部分自动化扫描。第三定期检查 ftpsvc 的日志大小和磁盘剩余空间日志默认存在C:\Windows\System32\LogFiles\FTPSVC1拿磁盘满了换系统换回来的成本够买几块盘了。8. 实战体感什么场景下我建议你别用自带 FTP说句公道话IIS 自带 FTP 不是万能的。我把它当成默认方案但有几种需求它确实比不过第三方工具一是需要细粒度限速的。IIS FTP 支持站点级限速在 IIS 管理器里可以设置最大带宽但做不到按用户限速、按时段限速这种精细化控制如果你要卖给客户按带宽计费建议看看别的方案。二是需要 Web 管理界面的。自带 FTP 的管理必须登录系统通过 IIS 管理器操作让非管理员通过网页自助管理账号密码它不是不行而是你得自己写一套脚本和 UI 去对接性价比太低。三是对审计要求极高的场景。IIS FTP 的日志记录连接、下载、上传没问题但如果要做内容级审计比如记录每个文件的内容哈希它做不到开箱即用。反过来如果你要的就是用户用 Windows 账号登录、按 NTFS 权限控制、被动模式端口可控、稳定跑两三年不用管那自带 FTP 的维护成本确实比大多数第三方工具低得多——它不用更新、不用授权、不用单独装服务Windows 更新会照顾好它重启后自动拉起。生产环境里没人记得它存在往往就是最好的状态。我在实际项目里已经用它替换过三个 FileZilla Server 环境。替换之后用户端没有任何感知FTP 地址不变账号密码不变但服务端不用再去折腾Windows 更新后 FileZilla 服务掉了这类破事了运维群里的告警都少了。如果你现在的 FTP 服务也动不动就闹脾气不妨按这篇文章的思路把自带 FTP 立起来试试。
