简介：FileZilla Server 0.9.39 汉化绿色版面向需要在 Windows 环境中快速搭建 FTP 服务的个人站长、运维人员、开发测试者及局域网文件共享用户，以免安装、界面汉化的方式降低部署与使用门槛，可用于临时传输、服务测试、教学演示等场景。压缩包共 11 个文件，以 exe 可执行程序、dll 运行库为主，辅以 xml 配置文件和 htm/txt 说明文档，整体约 1.4MB，体积轻巧，解压后即可按说明完成服务端与界面端的初始化配置。已有 535 人学习下载，说明其在同类轻量 FTP 工具中具备一定参考价值。资源保留多用户管理、多线程引擎、Windows 服务运行、实时用户/组管理、运行时动态改设置、空闲断开、基于规则的限速及 MODE Z 传输压缩等能力，并采用 MD5 安全密码存储；读者可据此搭建稳定的文件传输服务，也可用于功能验证、权限与速度策略测试及网络实验环境构建。
1. 一个 0.9.39 的绿色版，救的是哪类现场
上周帮一个做设备集成的朋友收拾现场：一台跑着老系统的工控机要临时收日志，装新服务端卡在运行时依赖上，翻了半天，最后用的是 FileZilla Server 0.9.39 的绿色版——解压、双击、加一个账户，二十分钟后数据就开始往里落了。这个绿色版的价值不在功能新，而在于它把整包拆成可搬运的文件集合：不写注册表、不默认注册系统服务、整个目录拷走能在另一台机器原地复活，断网环境也能部署。
它适合的场景很具体：内网临时传文件、老旧 Windows 机器上开一个收发点、给自动化设备做日志落地、不方便在客户机上留安装痕迹的场合。不适合的场景同样具体：直接暴露在公网、几十个并发用户的正式业务、需要细粒度审计的环境——这个分支早就停止更新了。下面按我实际排错的顺序，从解压到被动模式、从建账户到开 TLS，把这个绿色版拆一遍。
2. 绿色版跑起来：解压、首次启动与汉化加载
2.1 先看清目录里有什么，再决定怎么启动
绿色版本质是“安装完的目录打包”，所以它保留了安装版的两套程序：一个是服务端本体，负责监听端口、处理 FTP 会话；另一个是管理界面，单独运行、通过管理端口连服务端。配置也分成两份，服务端的账户、共享目录、被动端口全在一个 XML 里，界面的窗口位置、语言、上次连接的地址在另一个 XML 里。很多人把整包拷到新机器后“账户全没了”，其实是把服务端 XML 覆盖掉或者路径写死了。
上手第一件事不是双击，是列一遍目录，确认几个关键文件都在、大小不为零。
# 列出解压目录下的所有文件，重点看 exe 和 xml 是否齐全 Get-ChildItem -Path "D:\tools\ftp-server" -Recurse -File | Select-Object FullName, Length, LastWriteTime | Sort-Object FullName | Format-Table -AutoSize这段命令做的是“清点”，逻辑很直白：-Recurse递归进子目录，因为汉化资源经常单独放一层；Length用来判断是不是 0 字节的占位文件，有些压缩包解压中断会留下空壳；LastWriteTime能看出这个包最后一次被打包的时间，绿色版经常是几年前的目录直接压的，配置里可能还留着原作者的账户名和共享路径，第一次用之前必须清干净。参数上没什么可调的，如果目录特别大、只想看 exe 和 xml，把-File后面接-Include *.exe,*.xml更省事。
提示：拷到新机器后先别急着改 XML，把整个目录复制一份做基线，后面任何配置改坏了都能靠它回滚，比重装快得多。
2.2 首次启动：端口占用与运行库是两个高频拦路虎
服务端默认监听 21 端口。Windows 上装了 IIS 的 FTP 角色、或者之前跑过别的 FTP 服务，21 就已经被占了，绿色版双击后界面能开、服务端起不来，或者客户端连上去提示握手失败。排查顺序是先看端口再去看日志，别一上来就怀疑配置。
# 查 21 端口被哪个进程占了，最后一列是 PID netstat -ano | findstr ":21 " # 拿 PID 反查进程名，确认是不是已知服务 tasklist /FI "PID eq 4820" # 顺便看一眼 14147（管理端口）有没有被占 netstat -ano | findstr ":14147 "netstat -ano里-a是连监听带已建立连接全列，-n是不做 DNS 反解、直接出 IP 和端口、速度快，-o是关键，输出 PID 才能往下查。findstr ":21 "后面那个空格是必须的，否则 2100、2121 这类端口也会被匹配出来，白白浪费半小时。查到 PID 后用tasklist的/FI过滤器定位进程名，如果发现是系统自带的 FTP 服务，去服务管理器停掉并设为手动，比改端口更省心——端口一改，所有客户端都得跟着改，现场设备往往改不动。
另一个坑是运行库。这个年代的 Windows 程序多数依赖 VC++ 运行库，缺了会直接弹“应用程序无法正常启动 0xc000007b”，或者双击一闪而过。绿色版为了体积通常不带运行库，需要目标机器自己装。判断方法很简单：把服务端 exe 拿到命令行里跑，报错信息比双击弹窗详细得多。
启动方式有两种，选哪种取决于你要不要“开机自启”。直接双击exe是前台进程，关掉窗口服务就停，适合临时用；注册成系统服务则是后台常驻，命令带参数执行即可。
# 注册为系统服务（需要管理员权限的终端） "FileZilla Server.exe" /install # 启动 / 停止 / 重载配置 "FileZilla Server.exe" /start "FileZilla Server.exe" /stop "FileZilla Server.exe" /reload-config/install会把程序路径写进服务表，所以先确定目录最终位置再注册，否则以后挪目录服务就指向空路径，表现是“服务启动失败、错误 1053”。/reload-config是这套命令里最实用的一个：改完账户和共享目录不用重启服务，重载一下配置就生效，已经连着的会话不受影响。绿色版如果不想污染系统，就别执行/install，直接用/compat参数在当前会话里跑，退出即干净，代价是没有开机自启。
2.3 管理界面连不上服务端：多半是管理端口和绑定地址
服务端起来了，管理界面却提示连不上，这在实际操作里出现频率比想象中高。管理界面连的是服务端的管理端口，默认 14147，跟 FTP 的 21 完全是两回事。绿色版换机器后，如果之前有人在设置里把管理端口改过、或者把它绑定到了某个具体网卡地址，新机器上网卡 IP 变了，界面就连不上。
连接对话框里三个字段：地址填127.0.0.1（管理界面和服务端在同一台机器时）、端口填实际的管理端口、口令填当初设置的。口令如果丢了，不要急着删配置重来——服务端的 XML 里存着管理口令，把对应节点清掉后重启服务，会回到“未设置口令”的状态，重新进界面设一个就行。改之前记得停服务，运行中的服务会周期性地把内存里的配置写回文件，你改完它一覆盖，白干。
如果管理界面和服务端不在同一台机器，还要在服务端设置里显式允许远程管理，并确认防火墙放行了管理端口。我的习惯是：除非确实需要远程管，否则管理端口只监听本地，少开一个口子少一份风险。
2.4 汉化不生效，通常是加载顺序的问题
绿色汉化版一般有两种做法：替换界面程序本身，或者把语言资源文件放进指定目录、由界面启动时加载。两种做法对应两类故障。
一类是“界面还是英文”。先确认语言资源文件的位置对不对——多数汉化包要求文件放在界面程序同级或固定的子目录里，具体看包里自带的说明，不同汉化者的约定不一样，别想当然。再确认界面配置文件里记录的语言项是不是被改回去了，这个文件在界面程序旁边，用文本编辑器打开能看到类似语言的键值，改完保存再启动。还有一类更隐蔽：文件放对了，但文件名大小写或后缀跟程序预期的差一点，Windows 文件系统不区分大小写，程序里是硬编码字符串，就差这一个字母。
另一类是“界面是中文了，但菜单里全是问号”。这是编码问题，不是汉化问题。汉化资源如果是按 GBK 存的，而系统区域设置或者程序内部按 UTF-8 解析，就会出乱码。解决办法是把系统区域设置里的“非 Unicode 程序的语言”调成中文（简体），重启后大概率正常；实在不行就换一个汉化包，不要在这上面耗时间——界面看不懂顶多是配置效率低，账户和权限的配置项就那么几个，英文界面配两遍也就熟了。
3. 账户、组与目录权限：把“谁能看什么”落到路径上
3.1 权限是四层叠加的，只勾一半必然出问题
“明明给了写权限，上传还是失败”——这类问题九成出在只考虑了其中一层。这个服务端的权限链路其实是四层：FTP 账户本身（是否禁用、最大连接数、IP 限制）→ 所属组（组上挂的共享目录和权限）→ 用户自己的共享目录条目（路径、别名、读写删除追加）→ 文件系统层的 NTFS 权限。
前两层是服务端软件内部判断，第三层决定这个路径能不能被这个账户看见，第四层由服务进程运行的身份决定。服务注册成系统服务时默认以 LocalSystem 运行，它对本地磁盘几乎畅通无阻，所以你勾了写就能写；如果服务被人改成用某个受限账户启动，那即使 FTP 层全勾上，落盘时照样被 NTFS 拒绝，表现是“权限被拒绝”但配置看不出任何毛病。排查这类问题，先看服务以什么身份运行，再看目标目录的安全选项卡里这个身份有没有写权限。
还有一个容易忽略的点：权限是按目录条目生效的，不是按账户全局生效的。同一个账户可以有多个共享目录，A 目录只读、B 目录可写，这是完全正常的配置，也是它比“给个账户就全盘可读”更值得用的原因。
3.2 建第一个受限账户：只读、只能看一个目录
先把最常见的需求做出来：一个只能下载、只能看到一个目录的账户。进管理界面的用户页，添加用户、设口令，然后在共享目录里加一条，路径指向真实目录，勾上“设为根目录”，文件权限只勾读，目录权限勾列表和进入子目录，其余全部不勾。
配置落到 XML 里大概是这个结构（字段顺序和命名在不同汉化包里可能略有差异，改之前务必备份）：
<User Name="loguser"> <!-- 口令字段，界面上设置后由服务端写入 --> <Option Name="Pass">替换为实际口令</Option> <!-- 所属组，留空表示不继承任何组权限 --> <Option Name="Group"></Option> <!-- 是否绕过全局连接数限制，0 表示受限 --> <Option Name="Bypass server userlimit">0</Option> <Permissions> <Permission Dir="D:\ftp\pub"> <!-- 文件权限：读开，写/删除/追加全关 --> <Option Name="FileRead">1</Option> <Option Name="FileWrite">0</Option> <Option Name="FileDelete">0</Option> <Option Name="FileAppend">0</Option> <!-- 目录权限：只允许列表和进入子目录 --> <Option Name="DirCreate">0</Option> <Option Name="DirDelete">0</Option> <Option Name="DirList">1</Option> <Option Name="DirSubdirs">1</Option> <!-- 1 表示这条就是该用户的根目录 --> <Option Name="IsHome">1</Option> </Permission> </Permissions> </User>逐项说一下为什么要这么设。FileRead是下载，只读账户必须开；FileWrite是上传覆盖，FileAppend是断点续传追加，这两个分开是有道理的——有些场景允许续传但不允许新建覆盖，比如给设备回传日志的目录，开 Append 不开 Write，能续传但改不了已有文件。DirList不开的话客户端连目录都列不出来，表现是登录成功、一片空白；DirSubdirs不开则只能停在根目录，进不去子文件夹，这两个是最容易被漏勾的。IsHome只在用户有多条目录、需要指定哪条是根的时候才有意义，单目录账户勾不勾都一样。
口令字段的存储方式跟版本有关，不要手动去改它，界面上设最稳。真要批量建账户，正确做法是关掉服务、改 XML、再启动，服务运行期间改文件会被内存里的配置覆盖回去。
3.3 别名映射：把另一块盘挂到用户根目录下
现场经常遇到这种情况：用户根目录在 D 盘，但设备日志落在 E 盘，又不想给用户开两个独立路径。这时候用别名。在共享目录里再添加一条，目录名填一个不存在的名字（比如logs），路径指向真实的E:\device\logs，权限单独设。关键点在于：文件系统里不需要真的建一个叫logs的文件夹，服务端会在会话里把这个名字映射到真实路径。
<Permission Dir="logs"> <!-- 别名条目：Dir 是会话里显示的名字，不是磁盘路径 --> <Option Name="FileRead">1</Option> <Option Name="FileWrite">1</Option> <Option Name="FileAppend">1</Option> <Option Name="DirCreate">1</Option> <Option Name="DirList">1</Option> <Option Name="DirSubdirs">1</Option> <Option Name="IsHome">0</Option> </Permission>这里Dir="logs"和上一条的Dir="D:\ftp\pub"形成对比：带盘符的是物理路径，不带盘符的是别名。IsHome设 0 很重要，一个用户只能有一个根。这套机制的好处是权限可以按别名单独收放，logs目录给读写、根目录给只读，互不干扰；坏处是排查时容易懵，客户端看到的路径和磁盘上的路径对不上，看到logs就去找文件夹，找不到就以为配置错了。
注意：别名指向的真实路径如果不存在，客户端表现为“能进目录、但列表失败”，不会给出明确提示，这是排查时最费时间的形态之一。
3.4 组：一次配置，多账户复用
设备多的时候，一台设备一个账户，十几个账户的共享目录一模一样，逐个配是体力活。正确做法是建一个组，把共享目录和权限挂在组上，用户只填组名和口令。用户的权限是“组权限 + 用户自己的权限”叠加，所以组上给了只读、用户上再补一条可写，是可行的。
组的典型用法有两种。一种是按角色分：只读组、回传组、管理组，账户按需入组。另一种是按目录分：一个目录一个组，新设备来了直接入组，不用碰路径配置。我倾向于后者，因为现场加设备的频率远高于改角色，加设备时只需要在用户列表里加一行、填组名、设口令，三步完事，改错面的概率也低。
组配置同样落在服务端 XML 里，结构跟用户节点平行。改完记得用/reload-config重载，不要重启服务——重载只影响新会话，已经连着的设备不会掉线。这一条在现场很重要，设备断线重连往往要等好几分钟，能不断就别断。
4. 被动模式、防火墙与传输加密：外网能连的三道关
4.1 主动和被动：为什么“能登录、能列目录、就是传不动”
FTP 是双连接协议：一条控制连接走 21 端口，负责命令和应答；一条数据连接走另外的端口，负责文件内容。主动模式下，数据连接是服务端主动连客户端，客户端在 NAT 或防火墙后面时，服务端根本连不进去，表现就是登录正常、LIST卡住、传文件超时。被动模式反过来，服务端开一个端口等客户端来连，客户端在 NAT 后面也能工作。
问题在于，被动模式需要服务端告诉客户端“来连我这个 IP 和这个端口”。这个 IP 是服务端自己填的，如果服务端在内网、客户端在外网，服务端报给客户端的会是一个内网地址，客户端当然连不上。所以被动模式出问题，永远是这两个方向：报出去的 IP 对不对，报出去的端口通不通。
4.2 被动端口范围与外部 IP：两个必填项
服务端设置里有一个被动模式的页面，核心就三样：启用自定义端口范围、填起止端口、填外部 IP。
端口范围怎么定？按最大并发会话数估。一个会话传输时至少占一个被动端口，留出重连和并发的余量，一般给 50 到 200 个端口。范围别开太散，防火墙规则是按范围写的，开个 50000–60000 一万个端口，规则好写但排查困难；我一般用 50000–50100，够用且一眼能记住。
外部 IP 分两种情况。服务端和客户端在同一内网，填服务端自己的内网 IP。服务端通过路由器端口映射对外提供服务，就填映射后的公网 IP，同时把被动端口段一起映射出去。界面上还有一个“自动获取外部 IP”的选项，内网机器访问不到外网时这个选项会让服务端在建立数据连接前卡住几秒甚至超时，表现是“每次传文件前都愣一下”，内网环境一律选手动填。
4.3 防火墙放行：控制端口和被动端口要分开写
Windows 防火墙默认拦入站，21 端口和被动端口段都得放行。命令行比界面点选可靠，也方便复制到别的机器上复用。
# 放行 FTP 控制连接（21 端口） netsh advfirewall firewall add rule name="FTP-Control" dir=in action=allow protocol=TCP localport=21 # 放行被动模式端口段，必须跟服务端设置里的范围完全一致 netsh advfirewall firewall add rule name="FTP-Passive" dir=in action=allow protocol=TCP localport=50000-50100 # 只允许指定网段访问，比全放行安全得多 netsh advfirewall firewall add rule name="FTP-Passive-LAN" dir=in action=allow protocol=TCP localport=50000-50100 remoteip=192.168.1.0/24dir=in是入站方向，action=allow放行，protocol=TCP别写成 UDP，localport的范围写法是起-止，中间不要加空格。remoteip这个参数值得单独说：它把规则限制在指定网段，即使服务端不小心暴露到更大范围，未授权来源也连不进来。同一台机器上如果有多个网卡、多个网段，不加remoteip就等于对所有可达网络开放，现场的“临时用一下”最后变成长期敞开，多半就是从这来的。
提示：改完防火墙规则，用另一台机器上的客户端实际连一次、传一个文件、再列一次目录，三个动作都过才算通。只测登录会漏掉数据连接的问题。
如果服务端前面还有一层硬件防火墙或路由器，被动端口段要在那一层也做映射，且映射后的内外端口保持一致，改端口映射比改服务端配置更容易出错。
4.4 开 TLS：自签证书十分钟搞定，老客户端要留后路
明文 FTP 的口令是裸奔的，哪怕是内网，能开加密就开。这个版本支持显式的 FTP over TLS，需要一对 PEM 格式的私钥和证书。没有证书就自签一个，十年有效期，够用到这台机器退休。
# 生成 2048 位私钥和自签证书，一条命令出两个文件 openssl req -x509 -nodes -newkey rsa:2048 -days 3650 \ -keyout ftp-key.pem -out ftp-cert.pem \ -subj "/C=CN/O=Internal/CN=192.168.1.10"-x509表示直接出自签证书而不是证书请求，-nodes是不给私钥加口令——加了口令服务端启动时要人工输入，做服务的场景不能这么干。-days 3650是有效期，-subj里的CN填客户端连接时使用的地址，填 IP 就写 IP，写主机名就写主机名，填错了客户端会报证书名称不匹配。生成出来两个文件，在服务端加密设置里分别指定私钥和证书，勾上启用，再决定要不要强制。
强制加密这条要谨慎。开了“强制显式 TLS”和“强制 PROT P”之后，只支持明文的老客户端、老设备会直接连不上，而现场设备往往改不了固件。我的做法是：先开加密但不强制，观察一段时间日志里有多少会话走了 TLS；确认所有客户端都支持之后，再用 IP 过滤把不支持的那几台单独限制或者放到一个例外账户上，最后才全局强制。一步到位听着痛快，现场掉线的时候没有后悔药。
5. 避坑与排查：五条血泪记录
5.1 连接类：登录成功但用不了
现象一：客户端能登录，目录列表一片空白，日志里LIST之后没有下文。
原因基本锁定在数据连接上：要么是被动端口没放行，要么是服务端报给客户端的外部 IP 是内网地址。前者的特征是内网客户端正常、外网客户端空白；后者的特征是所有跨网段客户端都空白。
解决：先在内网用同一账户测一次，内网通、外网不通就查外部 IP 配置；内外网都不通就查防火墙端口段，注意端口段要跟服务端设置里逐位一致，差一个数就会出现“大部分时候能用、偶尔失败”的玄学现象。
现象二：连续几次登录失败后，账户彻底登不上，重启服务才恢复。
原因通常是触发了防暴力破解的自动封禁，或者是全局连接数、单账户连接数被打满。设备端重连逻辑写得粗糙时，断线后会在一秒内重试十几次，很容易触发。
解决：看服务端日志里有没有来源 IP 被临时封禁的记录，有的话在 IP 过滤里把它加白；再看全局最大连接数和单账户最大连接数，把设备账户的限制调宽一点。根治办法是让设备端的重连间隔带退避，但现场改不了设备，只能在服务端放宽。
5.2 传输类：文件传上去了，但不对
现象三：中文文件名上传后变成一堆问号，或者干脆传不上去。
原因在字符集协商，不在权限。FTP 协议早期没有统一编码，双方各按本地代码页解释文件名，客户端和服务端的代码页一旦不一致就乱码。
解决：客户端侧优先处理，把站点的字符集显式设成 UTF-8，或者在登录后手动发一条启用 UTF-8 的命令；服务端这边对 UTF-8 的支持是默认的，界面里能找到的兼容开关主要是给老客户端留的后路，别乱关。如果客户端是固件写死的老设备，最省事的办法是把上传目录和文件名全改成 ASCII，用“设备编号+日期”命名，比跟编码较劲划算。
现象四：大文件传到 99% 失败，重试续传后文件尾部损坏。
原因是传输中途连接被中断，而续传时的偏移量是按客户端本地文件大小算的，服务端那边的半截文件如果比客户端记录的还长，追加就会写错位置。
解决：先确认服务端对这个目录开了追加权限而没开覆盖权限，这样最坏情况是续传失败而不是文件被写坏；再排查中断原因，多数是空闲超时设置太短，设备传大文件时中间有停顿，连接被判死。把超时调大、把 TCP 保活打开，两个动作一起做。已经损坏的文件不要试图修复，删掉重传，这是唯一可靠的做法。
5.3 配置与迁移类：换台机器就全乱
现象五：整个目录拷到新机器，账户、共享目录全在，但客户端连上后看到的是空目录，或者直接权限拒绝。
原因有两个层面。一是配置里写的是绝对路径，新机器上盘符或目录结构不一样，路径指向了不存在的位置；二是服务在新机器上以不同的身份运行，NTFS 权限对不上。
解决：迁移前先在旧机器上把服务停掉，确保 XML 是最新的；拷过去之后逐条核对共享目录的物理路径，盘符变了就改；再检查服务运行身份，如果旧机器上用的是专用账户、新机器上退回了系统默认身份，要么把账户建出来，要么统一用默认身份并把目录权限放开到对应级别。迁移完必须实际连一次、传一个文件、删一个文件，三个动作覆盖读、写、删三层权限，光看配置看不出问题。
现象六（顺带记一笔）：日志里的时间和客户端看到的差了八小时。
不是服务端的时区问题，是部分客户端在显示文件时间时会按本地时区换算，而服务端存的是 UTC。排查时间戳问题时以日志里的时间为准，别拿客户端的显示时间去对。
6. 上线前跑一遍这套自检：老版本也能用得不难受
6.1 六项自检，十分钟过一遍
配置完不要直接交给业务方，按下面这张表跑一遍，问题基本能在交付前暴露。
| 自检项 | 怎么查 | 期望结果 |
|---|---|---|
| 端口监听 | netstat -ano | findstr ":21 :14147" | 两条都在监听，PID 指向服务端 |
| 服务身份 | 服务管理器看登录身份 | 与目录 NTFS 权限匹配 |
| 被动端口 | 防火墙规则与服务端设置对比 | 范围逐位一致 |
| 加密状态 | 客户端连接后看会话是否走 TLS | 支持的客户端全走加密 |
| 权限矩阵 | 用只读账户试写、用回传账户试读 | 越权操作全部被拒 |
| 配置备份 | 复制服务端 XML 到备份目录 | 文件时间是最新的 |
倒数第二项最容易被跳过，但它恰恰是最该做的：拿只读账户去试一次上传，拿回传账户去试一次下载别人的目录，两个都失败才算权限配对了。只看配置文件永远看不出叠加后的实际效果。
6.2 这个版本的边界，得说清楚
这个分支停了很久，公开渠道能查到它的历史问题记录，官方也早就不再为它出补丁。所以我的用法很克制：只在受控内网跑，出口用 IP 过滤锁死来源网段，管理端口只监听本地，匿名访问一律不开，账户口令按设备编号单独设、不用一套密码走天下。真要对外提供服务，换仍在维护的版本，别在这一版上赌。
日常维护上，我给自己定了两条硬规矩。第一，任何配置改动前先复制一份服务端 XML，命名带上日期，改坏了三十秒回滚。第二，加完账户或改完目录，用/reload-config重载而不是重启服务，重载完立刻用一个真实客户端连一次——只看界面显示“已保存”不算数，得让会话真的建起来、文件真的传过去。
从那以后我每次交付这类绿色版，都会在目录里留一个自检清单和一个配置备份文件夹，接手的人照着跑一遍就能确认状态，不用靠猜。这套习惯救过我两次，一次是迁移后路径写错、一次是被动端口少开了一个，都是自检表里一眼能看出来的问题，硬拖到业务方那边就是半夜的电话。希望帮到你。
本文还有配套的精品资源，点击获取
