简介：这份 FileZilla Server 0.9.39 汉化绿色版面向需要在 Windows 环境中快速搭建 FTP 服务的个人用户、小型团队与运维初学者，解压后即可运行，适合文件共享、内网传输、课程实验和轻量级服务端测试。压缩包共 11 个文件，约 1.4MB，主要由动态链接库、可执行程序与界面程序构成，并配有帮助页面、配置文件和说明文本，便于快速理解服务端与界面端的组成及启动关系。该版本支持无限制用户接入、多线程引擎、用户与组实时管理、MD5 密码存储、传输限速、空闲连接断开以及 MODE Z 压缩，运行中也能调整选项，方便边配置边验证权限与传输效果。已有 537 人学习下载，可作为熟悉 FTP 服务配置、权限管理、速度控制、安全设置与基础排错的实用工具包，也方便在真实网络环境中演练服务端部署和用户权限划分。

1. 内网产线三天要交文件，为什么我最后选了一个解压就能跑的 FTP 服务端

某公司内网一条老产线，设备端只有一个输入框：填 IP、填账号、点上传。它不会 SFTP，不认 WebDAV，甚至连被动模式都要手动指定。甲方给的期限是三个工作日，走采购、走安装审批、走安全扫描，时间全耗在流程上，根本轮不到技术。这种时候，FileZilla Server 0.9.39 汉化绿色版就很合适：解压到任意目录，双击起服务端，管理界面是中文，配置跟着目录走，整个文件夹拷到另一台机器照样能用。

这篇内容只讨论这类场景：内网交付、老设备对接、临时文件收集点、没有管理员权限的受限机器。它不是给你做公网高并发下载站用的，也不是拿来替代对象存储的，边界先摆在这里。下面从解压后认文件开始，一路说清楚端口怎么配、权限怎么给、坏了怎么看，以及绿色版最容易导致出问题的配置丢失问题。

2. 解压之后先做什么：目录构成、14147 管理端口与两种运行形态

2.1 四个文件决定后面所有操作

把压缩包解开，目录里通常有一堆东西，但真正需要你了解清楚的只有四样。FileZilla Server.exe是主体，它既当服务端进程，又当服务控制器；FileZilla Server Interface.exe是管理界面，它自己不监听任何端口，本质上是一个客户端，连的是服务端的管理端口，默认 14147；FileZilla Server.xml是整个服务端的全部配置，用户、组、目录权限、监听端口、TLS 证书路径全在这一个文件里；Logs目录是日志写入位置，默认按天切。

汉化包改的一般是管理界面这一侧的字符串资源，所以你看到的是中文菜单，但 XML 里的键名依然是Option、Permission、Setting这些英文。这一点必须提前记住：中文界面里叫“被动模式设置”，落到 XML 里是另一套键名，两边不能凭字面猜，只能靠改一项、存一次、比对一次来对照。我见过有人照着中文界面去搜 XML 键名，搜不到就以为配置文件是加密的，其实只是没对上。

绿色版还有一个容易被忽视的差异：配置到底读哪个路径。走安装流程的版本，配置可能落在用户目录下的应用数据文件夹里；绿色版通常就在程序目录。如果你在 A 机器上配了二十个用户，只把 exe 拷到 B 机器，用户就“消失”了——不是坏了，是它读了另一个 xml。判断方法很直接：改一个明显的设置（比如欢迎语），保存，然后在磁盘上搜这个字符串落在哪个文件里。

2.2 两种运行形态：注册成服务，还是当普通进程跑

第一种是把服务端注册成系统服务，开机自启，不需要人登录：

:: 以管理员身份打开 cmd，先切到程序目录 cd /d D:\tools\ftp\FileZillaServer :: 注册为服务，服务名默认就是 FileZilla Server "FileZilla Server.exe" /install :: 启动 / 停止 / 卸载，都是对已注册服务的操作 "FileZilla Server.exe" /start "FileZilla Server.exe" /stop "FileZilla Server.exe" /uninstall :: 改完 xml 不想重启服务，热加载配置 "FileZilla Server.exe" /reload

/install写的是服务注册项，之后开机自启，服务以本地系统账户身份运行。/reload让服务端重新读一遍 XML，界面上点“重载配置”背后调的就是它。/uninstall只卸服务，不动 xml 和日志，这点设计得挺厚道，重装不用重新配。

第二种是不注册服务，直接以前台进程跑：

:: 便携形态：以当前登录用户身份运行，不写服务注册项 "FileZilla Server.exe" /compat

/compat的价值在权限上下文。服务形态跑在系统账户下，访问映射的网络盘、用户加密目录、某些外挂存储时经常读不到，日志里一句“无法访问”就没了；而/compat跑在你自己账户下，这些路径立刻就通了。代价是窗口一关服务就停，也不开机自启。

提示：以服务形态运行时，FTP 根目录的 NTFS 权限要授给系统账户，不是授给你自己登录的那个账号。这个坑在第 5 章还会出现一次。

我的习惯是：前期用/compat把路径权限、中文文件名、大文件传输全验一遍，确认没问题再/install切成服务形态，然后只验一次开机自启。

2.3 管理界面第一次连：14147 与那个空密码

打开管理界面，弹窗三个字段：服务器地址、管理端口、管理密码。本机就是127.0.0.1/14147/ 空密码。

连不上就三种情况。服务没起，去服务管理器看状态，或者命令行/start。端口被改过，看 xml 里的管理端口项，或者本机直接查谁在监听。管理密码被前任设过，这个没法“找回”，只能停服务改 xml 里对应那一项——存的是哈希，把那一行删掉就等于恢复空密码。

# Windows 下确认管理端口和 FTP 端口各自有没有在听 netstat -ano | findstr ":14147 :21 "

看到 14147 有 LISTENING 但界面还是连不上，八成是地址栏填了机器名而不是127.0.0.1，解析先走 IPv6 被拒。这个“玄学”问题排查过太多次，直接写回环地址最快。

2.4 选型：为什么停在 0.9.x 而不是装最新版

新版本改成了 Web 管理界面，安装要管理员权限，配置不再简单的存放一个 xml，便携性基本没了。0.9.x 这一代是纯 Win32 窗口加单文件配置，绿色版能成立就是因为这个结构。

兼容性上，老设备往往只支持明文 FTP 或者显式的 TLS 握手，0.9.x 的开关更粗放、更好判断：一个“强制显式 TLS”、一个“强制隐式 TLS”，勾不勾一目了然。新版的策略更细，反而容易在和老客户端握手时卡住。

代价也要说清楚：这个版本早就不更新了，不支持更新的 TLS 协议版本，日志粒度粗，没有细粒度的传输审计，多用户高并发下性能一般。所以它适合“内网、少量账号、文件量不大、要求快速上线”的场景；要对外提供服务，还是应该上仍在维护的版本，或者干脆用对象存储的临时上传凭证。

3. 用户与目录权限：0.9.x 的三层模型和一份可复用的模板

3.1 全局设置、组、用户，三层各管什么

0.9.x 的权限模型是三层。最上面是全局设置，管监听端口、超时、被动模式端口段、TLS、IP 过滤的全局规则；中间是组，把“同一批人共享的目录和权限”抽出来；最下面是用户，挂到某个组上，再叠加自己的目录。

组的意义在于减少重复。比如一个项目要开五个账号，都能读D:\ftp\proj，只有一个人能写。做法是建一个组，在组里配好D:\ftp\proj的读权限，五个用户都挂这个组，然后单独给那个人加一条写权限。用户权限和组权限是叠加关系，不是覆盖关系，所以“只读用户”不要挂到有写权限的组上，容易越权。

IP 过滤有两个层级：全局的和用户级的。用户级过滤适合“这个账号只许从产线网段登录”这种需求，写法支持192.168.10.*这类通配。全局过滤则决定谁连都不行。这两层都生效，别只配一层就以为拦住了。

3.2 权限位怎么勾：文件四件套与目录四件套

界面上一个目录对应两组勾选。文件侧是读、写、删除、追加；目录侧是创建、删除、列表、进入子目录。新手最容易犯的错是全勾，觉得“反正方便”。追加和写要分开看：追加只允许在文件末尾接内容，不允许覆盖；写允许覆盖已有文件。做日志收集点的时候，给追加不给写，能挡掉一半误覆盖。

列表和进入子目录也是分开的。只给列表不给进入子目录，客户端能看到目录名但进不去；只给进入子目录不给列表，能进但看不到内容列表。这两个组合出来的效果，很多客户端表现还不一样，所以别玩花的，按需给。

还有一个必踩的点：FTP 权限和 NTFS 权限是两道门，两道都过才通。你在界面上给了写权限，但目录的 NTFS 权限里没有服务账户的写权限，上传照样失败，而且报错信息往往很模糊。

3.3 用“样板用户”做模板，批量展开配置

直接手写 XML 节点风险高，因为权限字段的具体标记形式不同构建之间可能有差异。更稳的做法是：先在界面上手工配一个完全正确的“样板用户”，从 xml 里把它那段<User>节点整段抠出来存成模板，再用脚本做占位替换。

import pathlib import xml.etree.ElementTree as ET # tpl_user.xml 是从界面配好的样板用户里抠出来的一个 <User> 节点 tpl = pathlib.Path("tpl_user.xml").read_text(encoding="utf-8") # 需要批量开的账号：用户名、所在组、根目录 accounts = [ ("proj_a", "readers", r"D:\ftp\proj"), ("proj_b", "readers", r"D:\ftp\proj"), ("vendor_01", "uploaders", r"D:\ftp\inbox"), ] blocks = [] for name, group, root in accounts: node = tpl.replace("__NAME__", name) node = node.replace("__GROUP__", group) node = node.replace("__DIR__", root) # 结构合法性先校验一遍，别等写进主配置才发现少个闭合标签 ET.fromstring(f"<root>{node}</root>") blocks.append(node) pathlib.Path("users_snippet.xml").write_text("\n".join(blocks), encoding="utf-8") print(f"生成 {len(blocks)} 个用户节点，待人工核对后合并")

这段代码做三件事：读取模板、做字符串替换、用 XML 解析器做一次结构校验。参数上要特别注意__DIR__里如果带反斜杠，替换时不要被当成转义序列处理，最好用r"..."原始字符串。另外模板里应该预留一段权限节点，脚本不要碰它——权限是最容易配错的部分，宁可人工看一眼。

生成出来的片段不要直接覆盖主配置，先停服务、备份、粘贴、/reload、再起服务。合并之后逐条登录验证，别一次加二十个账号然后集体出问题。

注意：密码字段在 xml 里不是明文，是哈希值。脚本不要去“生成密码”，账号建好之后在界面里逐条设密码，或者先把哈希值从已有账号复制过来再让用户自己改。硬写明文会导致登录直接失败。

4. 被动模式端口规划：为什么“能登录却列不出目录”

4.1 一次传输其实是两条连接

FTP 和别的协议不一样，它是双连接：一条控制连接（默认 21）负责发命令、收状态码，一条数据连接负责传文件和目录列表。登录成功只说明控制连接通了，列目录用的是数据连接，数据连接不通的表现就是“登录上了，但一直转圈然后超时”。

主动模式（PORT）下，客户端告诉服务端“我开了某个端口，你来连我”；被动模式（PASV）下，服务端返回“我在某个端口等你，你来连我”。客户端在 NAT 后面的时候，主动模式基本不可用，因为服务端连不进客户端的内网地址。所以现代客户端默认全走被动模式。

问题就在这：被动模式下，服务端每次传输要开一个新端口，这些端口如果没在防火墙上放行，数据连接就建不起来。而控制连接是通的，所以用户看到的现象就是“能登录、不能列目录、不能传文件”。

4.2 固定被动端口段并在三处放行

0.9.x 的被动模式设置里有一段自定义端口范围，默认给的是一段高位区间（常见 50000–51000 这种量级）。默认值能用的前提是防火墙全放行，实际上很多机器只开了 21。

规划原则很简单：把范围收窄，比如 50000–50050，够几十个并发用；然后在三个地方放行——本机防火墙、宿主机上的安全软件、如果有云主机还要加安全组。三处漏一处，现象都一样。

# 放行控制端口 New-NetFirewallRule -DisplayName "FTP-Control-21" ` -Direction Inbound -Protocol TCP -LocalPort 21 -Action Allow # 放行收窄后的被动端口段，范围要和 xml 里配的完全一致 New-NetFirewallRule -DisplayName "FTP-Passive-50000-50050" ` -Direction Inbound -Protocol TCP -LocalPort 50000-50050 -Action Allow # 查一下规则有没有生效 Get-NetFirewallRule -DisplayName "FTP-Passive-*" | Select DisplayName, Enabled

这个脚本里最关键的参数是-LocalPort 50000-50050，必须和 xml 里配的起始端口、结束端口一字不差。常见的低级错误是界面里改了 50000–50050，防火墙还开着默认的 50000–51000，然后觉得“放行了怎么还不行”——其实是范围对不上，而且这种情况日志里看不出任何异常。

4.3 被动模式 IP 填错是最隐蔽的一类故障

被动模式下，服务端返回给客户端的响应里带一个 IP 和一个端口，客户端拿这个 IP 去连。这个 IP 从哪来？默认是服务端自动探测本机地址。多网卡机器上，它很可能探测到一块你不希望对外的那张网卡，于是客户端拿到一个根本连不通的地址。

现象很好认：客户端日志里能看到227 Entering Passive Mode (10,0,3,17,195,80)这类响应，括号里前四段是 IP，后两段是端口（p1×256+p2）。如果这四段 IP 不是客户端能路由到的地址，就一定卡在数据连接。

解决方式是在被动模式设置里显式指定对外 IP。纯内网就填内网地址；做了端口映射对外，就填映射后的公网地址，或者启用“从外部地址获取”的选项。我一般会先在服务端本机用ipconfig把所有网卡列一遍，确认哪张是对外的，再填死，不依赖自动探测。

4.4 用 curl 把协商过程打出来验证

图形客户端报错信息经常只有一句“连接超时”，看不到协商细节。用 curl 加-v能完整看到控制连接的每条命令和响应：

# 默认就是被动模式，-v 打印完整协商过程 curl -v "ftp://proj_a:密码@127.0.0.1:21/" # 只看目录列表，验证数据连接是否真的建起来了 curl -v --ftp-pasv "ftp://proj_a:密码@127.0.0.1:21/" --list-only # 反过来强制主动模式，用来区分是 PASV 问题还是别的 curl -v --ftp-port - "ftp://proj_a:密码@127.0.0.1:21/" --list-only

第一条命令重点看227那行返回的 IP 和端口对不对。第二条能列出目录，说明控制连接和数据连接都通。第三条如果主动模式反而成功、被动失败，那就百分之百是被动端口段或被动 IP 的问题，方向立刻收窄。

密码里如果有@、:、/这些字符，URL 里要先做百分号编码，否则 curl 会把它们当成分隔符。这个坑不大但很烦人，测试账号的密码最好用纯字母数字。

5. 排查清单：五类高频故障的现象、成因与处置

5.1 管理界面连不上，报“连接被拒绝”

现象：打开管理界面，地址填 127.0.0.1、端口 14147，点连接直接弹“无法连接服务器”。

原因：九成是服务端进程压根没在跑。绿色版不是装完就自启的，/compat形态关掉窗口就停，服务形态没执行/install也不会自己起来。

解决：先看任务管理器里有没有FileZilla Server.exe，没有就手动/start；再netstat -ano | findstr ":14147"确认监听。如果监听存在但仍被拒，检查是不是前任把管理端口改成了别的值——把 xml 里管理端口那一项翻出来对一遍。最后才怀疑管理密码，密码错是“拒绝登录”，不是“连接被拒绝”，两种提示要分清楚。

5.2 能登录，但列目录永远超时

现象：账号密码正确，登录成功，一到列目录就卡住，三十秒后客户端报数据连接超时。

原因：被动端口段没放行，或者放行的范围和配置里的不一致；也可能是被动 IP 返回了客户端路由不到的地址。

解决：按第 4 章的思路走一遍。先用 curl 看227响应，确认 IP 和端口；再核对防火墙规则和 xml 里的端口段是否完全一致；多网卡机器显式指定对外 IP。这一步不要靠猜，日志里看不出任何东西，只能靠抓响应。

5.3 小文件正常，大文件传到一半断，或者传完是 0 字节

现象：几百 KB 的文本没问题，几十 MB 的镜像传到 60%、80% 就断；或者传输显示成功但落地文件是 0 字节。

原因分三层。第一层是超时设置，无传输超时太短，大文件传输中的间隔被误判为挂死；第二层是磁盘空间或 NTFS 配额，写不进去但控制连接还活着；第三层是杀毒软件实时扫描对写入过程加锁，尤其对刚创建的文件。

解决：先把无传输超时调大，再看服务端日志里有没有磁盘写入相关的报错；然后临时关掉杀软的实时扫描做一次对照传输；最后用系统账户身份手动往目标目录写一个大文件，验证 NTFS 权限和配额。三层逐层排除，别一上来就重装。

5.4 中文文件名乱码，或者带中文的目录进不去

现象：客户端里中文文件名显示成问号或方块，重命名带中文的文件直接失败。

原因：0.9.x 有 UTF-8 相关的开关，老客户端可能还在用本地编码；两边编码协商不一致，文件名就乱。

解决：服务端把 UTF-8 支持打开，客户端强制用 UTF-8 编码（多数客户端有这个选项）。如果设备端根本不支持 UTF-8，那就别用中文文件名，改用英文加编号，这是最省事的做法。改目录名比改设备固件容易得多。

5.5 换了一台机器，用户和权限全没了

现象：把整个文件夹拷到新机器，服务能起，管理界面能连，但用户列表是空的。

原因：配置根本没跟着 exe 走，它读的是用户目录下另一份 xml；或者原机器上程序装在受保护目录里，写入被重定向到了虚拟存储位置。

解决：先确定当前进程实际读的是哪个 xml——改一个显眼的设置，然后在磁盘上全文搜索这个字符串。找到之后把这份 xml 一起迁移，而不是只拷可执行文件。迁移完停服务、覆盖、/reload、再起，顺序错了一样不生效。

6. 换机器不丢配置：把 FileZilla Server.xml 当代码管的三步回归法

这个版本最值钱的东西不是 exe，是那份 xml。exe 到处都能找到，配置丢了要一条条重建。所以我接手这类环境的第一件事，是把下面这几样东西列成一份迁移清单，每次换机照单执行。

三步回归的流程是这样。第一步，旧机器上停服务，把 xml 和证书整份拷走，同时在旧机器上跑一次icacls把根目录的权限导出成文本，新机器照着重建。第二步，新机器上解压、覆盖 xml、核对文件里所有绝对路径（尤其是目录映射和证书路径），路径不一致的按新机器改。第三步，起服务，不急着交付，先跑一轮回归验证。

# 回归验证：从登录到列目录到上传下载，一条命令走完 curl -v --ftp-pasv "ftp://proj_a:密码@127.0.0.1:21/" --list-only echo "test-$(date +%s)" > /tmp/ftp_probe.txt curl -v -T /tmp/ftp_probe.txt "ftp://proj_a:密码@127.0.0.1:21/upload/" curl -v -o /tmp/ftp_back.txt "ftp://proj_a:密码@127.0.0.1:21/upload/ftp_probe.txt"

这三条命令分别验证三件事：能否列目录（数据连接通不通）、能否上传（写权限和磁盘空间）、能否下载回来（读权限和内容完整性）。下载回来的文件要和上传的大小一致，我做这一步会顺手diff一次，字节级一致才算过。

我吃过一次亏：迁移时只拷了 xml，忘了证书文件，TLS 那边的路径指向一个不存在的文件，服务端居然正常启动、正常接受明文连接，直到有一台要求加密的客户端接进来才暴露，白白多花了一个下午。从那以后我每次迁移都强制走一遍“列目录、上传、下载、加密连接”四步验证，缺一步不算完成。希望帮到你。

本文还有配套的精品资源，点击获取