简介：这份汉化绿色版 FileZilla Server 0.9.39 面向需要在 Windows 环境下快速搭建 FTP 服务的个人站长、网络管理员和软件学习者，免安装解压即可使用，适合局域网文件共享、小型站点资料上传下载及 FTP 服务端功能演练。压缩包仅 1.4MB，共 11 个文件，主要包括服务端与界面程序两个 exe、支撑运行与 SSL 的 3 个 dll，以及记录服务配置的 xml、说明文档和许可页面等 htm/txt 文件，结构紧凑，便于携带与备份。已有 535 人学习下载，说明其在轻量 FTP 服务端场景中具有一定参考价值。功能上覆盖多用户与用户组实时管理、MD5 密码存储、上传下载速度限制、空闲用户自动断开、运行时修改设置无需重启，并支持 MODE Z 压缩传输和 FXP/反弹攻击防护，方便读者快速理解并实践 FTP 服务配置与基础安全控制。
1. 内网文件交换的临时方案：0.9.39 汉化绿色版能解决什么问题
给一台不能联外网的内网机器做文件收发，最省事的办法往往不是部署新服务，而是找一个能在 Windows 上直接跑的 FTP 服务端。FileZilla Server 0.9.39 汉化绿色版就属于这类常备工具：解压即用、配置跟着目录走、整包拷到另一台机器不用重装，管理界面还是中文，交给不熟命令行的同事，也不容易卡在菜单上。
它适合内网临时收发文、老设备固件与日志的落地目录、给只认 FTP 的旧系统当一块共享盘。至于公网裸奔、多租户隔离、需要 SFTP 的场景，请不要让它承担这些任务：0.9.x 这条线早已停止维护，它的适用范围就是内网。
2. 从解压到开机自启：绿色版如何注册成 Windows 服务
绿色版最容易出问题的地方，不是配置项有多复杂，而是“双击了但不生效”。原因很简单：FileZilla Server.exe有两种运行身份——一种是普通前台程序，一种是注册到系统里的服务。前者关掉窗口就没了，后者才是开机自启、后台常驻的形态。很多人把 exe 双击打开，看到托盘图标，以为已经装好，重启机器后才发现什么都没了。
正确的路径是先用命令行把服务注册进去，再用管理端连上去配置。整个过程要求一个管理员权限的 cmd，普通权限下/install会静默失败或者报一个看不懂的 5 号错误。
2.1 解压后的几个文件各自负责什么
先别急着双击，把目录里的东西分清楚，后面排错能省一半时间。绿色版通常不会改动服务端本体，汉化一般只替换管理端的界面资源，所以“汉化包版本对不上”这类问题的症状，基本都出现在管理端而不是传输侧。
| 文件 | 作用 | 绿色版里要不要改动 |
|---|---|---|
FileZilla Server.exe | 服务端本体，同时是服务安装器 | 不动，汉化一般不改它 |
FileZilla Server Interface.exe | 管理端 GUI | 汉化主要动这里 |
FileZilla Server.xml | 用户、组、共享目录、端口、TLS 全在这里 | 备份它就等于备份了整个服务器配置 |
FileZilla Server Interface.xml | 管理端上次连接的地址与端口 | 换机后连不上，先看它 |
doc、readme之类 | 说明文档 | 删掉不影响运行 |
FileZilla Server.xml和服务端 exe 在同一个目录，这一点决定绿色版的可迁移性：整个文件夹复制走，配置跟着走。反过来说，如果你用快捷方式或者计划任务从别的路径拉起 exe，它就会去那个路径下找 xml，找不到就生成一份空配置——这就是“配置莫名其妙丢了”的常见成因。
提示：迁移前先停服务再复制目录。运行中的服务会周期性回写 xml，边跑边拷很容易拷到半截配置。
2.2 注册服务并确认它真的起来了
下面这一段是整套部署的骨架，建议原样抄下来改路径。
:: 必须以管理员身份运行 cmd，否则注册服务会失败 cd /d D:\tools\FileZillaServer :: 注册为 Windows 服务（默认服务名 FileZilla Server） "FileZilla Server.exe" /install :: 启动服务 "FileZilla Server.exe" /start :: 确认服务状态，SERVICE_NAME 与 STATE 两行是重点 sc query "FileZilla Server" :: 端口监听情况，正常应能看到 21 和 14147 netstat -ano | findstr ":21 " netstat -ano | findstr ":14147"参数逐个说明：/install把 exe 注册成系统服务，注册信息写进注册表，所以这一步之后删掉目录，服务仍然存在但起不来；/start与/stop控制服务启停，等价于在服务管理器里点按钮；/uninstall摘掉服务，卸载前建议先/stop；/reload-config让服务重新读取 xml，改完配置不想重启服务时用它；/compat是不注册服务、直接以前台程序方式运行，排错时非常有用，因为报错会直接弹出来而不是只写进事件日志。
sc query那一步不要省。服务状态是STOPPED而netstat里 21 端口没有任何监听，说明服务压根没起来，这时候去调客户端参数是白费工夫。真正的原因通常在事件查看器的应用程序日志里，比如端口被占用、配置文件损坏、xml 权限不足。
顺带提一句卸载姿势，避免留下一个起来了但删不掉的服务：
"FileZilla Server.exe" /stop "FileZilla Server.exe" /uninstall2.3 管理端口和初始口令，第一件事就改掉
服务起来之后，管理端连的是127.0.0.1:14147，不是 21。21 是给 FTP 客户端用的数据/控制端口，14147 是给管理员用的配置通道，两个完全独立。绿色包为了省事，管理口令经常留空或者设成一个固定值，这个必须在上线前处理掉。
操作顺序是：打开管理端，连接窗口里地址填127.0.0.1、端口14147、口令按包内说明填，连上后进Edit → Settings → Administration，把管理口令改成一个像样的值，管理端口建议保持 14147 但确认它只监听回环地址。管理口一旦被映射到公网，等于把服务器的配置权限交出去了，用户、目录、权限全部可改。
FileZilla Server Interface.xml记录的就是上次连的地址和端口。换了机器或者改过管理端口之后，管理端可能一直弹连接失败，先看这个文件里存的还是不是旧值，比反复重装服务快得多。
3. 用户、组、共享目录：三层权限模型与一份可复用的配置
FileZilla Server 的权限不是“给个目录加个读写”这么简单，它有三层：用户、组、共享目录。用户挂在组下面继承设置，共享目录则是一个“别名 + 物理路径 + 一组权限位”的绑定关系。搞不清这三层，最常见的后果是“我明明给了写权限，为什么还是 550”。
先说结论性的经验：能用组就别用用户级配置。设备对接、外包上传、内部只读，这三类需求各建一个组，用户往里塞，后面加人减人只是勾选，不用逐条复刻权限。用户级设置会覆盖组级，一旦有人在用户级别乱勾，排查时你得同时看两处。
3.1 共享目录的“别名”和“主目录”
共享目录列表里每一行包含三样东西：物理路径、客户端看到的别名、权限位。别名这栏经常被忽略——它决定了客户端LIST出来叫什么名字，跟磁盘上的真实目录名可以完全无关。做对接时这个很有用：磁盘上是D:\ftp\device_log，别名设成log，对方系统里写死的路径就不用改。
列表里必须有一个被标记为H（Home）的目录，客户端登录后默认落在那里。没有主目录的账号能登录成功，但一PWD就报错，表现得很像“登录成功但什么都干不了”，容易被误判成权限问题。
共享目录还支持子目录继承。勾上目录项的Subdirs，权限会往下传递；不勾，子目录就得单独授权。做只允许访问某个子目录、不允许往上翻的场景时，靠的就是这个开关配合别名。
3.2 权限位与实际操作的对应关系
这张表建议打印出来贴在显示器边上，550、553 这类报错九成能在这张表里找到答案。
| 权限位 | 放行的操作 | 典型用途 |
|---|---|---|
| Read | RETR 下载 | 对外发布 |
| Write | STOR 上传、覆盖已有文件 | 收集上传 |
| Append | APPE 追加、部分客户端的续传 | 日志追加、断点续传 |
| Delete | DELE 删文件、RMD 删目录 | 覆盖式同步时必须给 |
| Files → Create | 新建文件 | 上传的前置条件 |
| Files → Delete | 删除文件 | 同上 |
| Directories → Create | MKD 建目录 | 按日期分目录上传 |
| Directories → Delete | 删除目录 | 同上 |
| Directories → List | LIST/NLST 列目录 | 关掉之后多数客户端put会先失败 |
最后一行是个真实的坑：想做“只能上传不能查看”的投递箱，把Read和List全关掉，结果对方的客户端上传前习惯性先CWD再LIST，直接失败，日志里看到的是 550 而不是 425，很容易误判成权限没配对。可行的做法是保留List但去掉Read——能看见文件名，下载不了；或者干脆让对方用绝对路径STOR，不列目录。
Delete这个权限值得单独强调。很多人只勾Write，发现覆盖上传失败，因为客户端覆盖已有文件时走的是“先删后传”或“临时文件改名”，没有Delete就卡住。要允许覆盖，Write + Delete + Files/Create + Files/Delete基本得一起给。
3.3 NTFS 权限是第二道验证，别只查 FTP 这一层
FTP 权限位放行了，文件系统不放行，一样是 550。服务默认以LocalSystem身份运行，共享目录的 NTFS ACL 里如果没有SYSTEM的写权限，表现出来就是“配置全对但传不上去”。
:: 给服务账户授读写，OI/CI 表示继承到文件和子目录 icacls "D:\ftp\data" /grant "NT AUTHORITY\SYSTEM:(OI)(CI)M" /T :: 查看当前 ACL，确认 SYSTEM 那行确实存在 icacls "D:\ftp\data"(OI)(CI)是对象继承与容器继承，M是修改权限（读写删都有）。/T递归应用到已有子项，不加的话老文件仍然是旧 ACL。这一步之后不需要重启服务。
网络盘是另一个高频翻车点。服务以LocalSystem跑的时候看不到当前用户映射的网络驱动器，Z:\share这种路径在服务里等于不存在。要用网络存储就把共享目录写成 UNC 路径\\nas\share，并且把服务登录账户改成有网络访问权限的域账户或本地账户，否则连接会一直挂在“正在打开目录”。
4. 被动模式与显式 FTPS：让客户端真的连得上
FTP 是双连接协议，这一点在 2024 年依然是最大的摩擦来源。控制连接一条，数据连接一条，而数据连接的方向在被动模式下是服务器反过来连客户端——准确说是客户端告诉服务器“我在这个端口等你”，服务器主动发起。中间隔一层防火墙或者 NAT，这条反向连接就断了，客户端看到的是425 Can't open data connection。
0.9.39 的被动模式默认从系统临时端口里随机取，这在纯内网同网段还能凑合，一跨网段必翻车。正确做法是显式指定一个端口范围，然后把这个范围在防火墙和映射上一起放行。
4.1 端口规划：三个端口各管什么
| 端口 | 用途 | 是否建议修改 |
|---|---|---|
| 21/TCP | 控制连接，登录、命令 | 可改，改完客户端要跟着改 |
| 14147/TCP | 管理端连接 | 可改，确认只监听 127.0.0.1 |
| 50000-50100/TCP | 被动模式数据连接 | 强烈建议显式指定 |
进Edit → Settings → Passive mode settings，勾上Use custom port range，填50000-50100。这个范围给多大？一条传输占一个端口，端口在传输结束后释放，所以范围大小约等于并发传输数。给 100 个端口，同时传 30 个小文件、每个文件单独开连接，理论上够用；但客户端开多线程、加上 TIME_WAIT 残留，实际能用的会少一些。做设备批量上传的场景，我给到 200 个端口起步。
同一个页面里还有两个 IP 相关的设置，容易互相打架：
Use the following IP：服务器告诉客户端“来连这个地址”。跨 NAT 时必须填映射后的公网地址，否则客户端拿到的是内网 IP，连不上。Don't use external IP for local connections：内网客户端访问时不返回外部 IP。这个要勾上，否则内网用户会被指到一个绕远甚至不可达的地址。
4.2 防火墙和端口映射的落地顺序
顺序错了会浪费很多时间。先把本机防火墙放开，再验证内网能通，最后才做映射验证外网。
# 控制连接 New-NetFirewallRule -DisplayName "FZServer-CTRL" -Direction Inbound ` -Protocol TCP -LocalPort 21 -Action Allow # 被动模式数据连接，范围必须和软件里填的一致 New-NetFirewallRule -DisplayName "FZServer-PASV" -Direction Inbound ` -Protocol TCP -LocalPort 50000-50100 -Action Allow # 管理口只允许本机，不要对外开放 New-NetFirewallRule -DisplayName "FZServer-ADMIN" -Direction Inbound ` -Protocol TCP -LocalPort 14147 -RemoteAddress 127.0.0.1 -Action Allow参数说明：-LocalPort支持范围写法，中间用减号；-RemoteAddress 127.0.0.1这条规则是给自己加一道限制，即使有人误做了映射，管理口也不会响应外部请求。做完之后用Get-NetFirewallRule -DisplayName "FZServer-*"确认规则已启用。
端口映射侧的逻辑一样：21 映射到 21，50000-50100 一对一映射到 50000-50100，不要做端口转换，否则被动模式返回的端口和实际映射端口对不上，客户端会连到一个不存在的端口。
4.3 显式 FTPS：0.9.x 只认 AUTH TLS
这一条能省掉大量无谓的调试：0.9.x 这条线只支持显式FTPS（客户端先连 21，发AUTH TLS升级加密），不支持隐式 FTPS 的 990 端口那套。客户端里如果你选了 “FTPS (隐式)”，握手阶段就会挂，报的是超时或连接被重置，看起来像防火墙问题，其实是模式选错了。要选的是FTPES或显式 FTP over TLS。
证书用自签的就够，内网场景没必要折腾 CA。
# 生成自签证书和私钥，CN 填客户端连接时用的地址 openssl req -x509 -newkey rsa:2048 -nodes -days 3650 \ -keyout fzserver.key -out fzserver.crt \ -subj "/CN=192.168.1.20"-nodes表示私钥不加密，这一点很关键：0.9.x 的服务在启动时没法交互输入私钥口令，加密私钥会导致 TLS 初始化失败，日志里只有一句含糊的证书加载错误。生成后把.crt和.key的路径分别填进Edit → Settings → SSL/TLS settings，勾上Enable FTP over TLS support，再按需勾Disallow plain unencrypted FTP和Force PROT P to encrypt file transfers。
老版本内置的加密库对现代客户端不太友好，TLS 1.3 是不用想的，某些新客户端甚至会因为加密套件不匹配直接拒绝握手。表现出来的现象是“同一台机器，命令行能连，图形客户端连不上”。内网封闭环境里，一个务实的选择是保留明文、只在跨网段时开 FTPS；另一个是把客户端降级到允许 TLS 1.0/1.1 的版本。这两种都是在兼容性和安全性之间做交换，心里要有数。
5. 避坑排查：五条实际踩过的记录
下面五条按“现象 → 原因 → 解决”写，都是我在实际部署里反复遇到的，顺序大致按出现频率排。
5.1 能登录、能列目录，一传文件就 425
现象：客户端登录成功，LIST也正常，一开始上传就停在 “Opening data connection”，十几秒后报425 Can't open data connection，日志里没有任何拒绝记录。
原因：被动模式端口没指定范围，服务器随机给了一个高位端口，防火墙没放行；或者跨了 NAT，服务器把内网 IP 塞进了227 Entering Passive Mode的响应里，客户端拿着内网地址去连，自然连不上。
解决：先把被动端口范围固定下来（比如 50000-50100），防火墙同步放行，跨网段时在Passive mode settings里填外部 IP，并勾上本地连接不使用外部 IP。验证方法很简单，用curl -v看227那一行返回的 IP 和端口，落在预期范围就对了。
5.2 服务明明在跑，管理端连不上
现象：sc query显示RUNNING，netstat里 21 端口也在监听，但管理端一直弹 “Connection to server lost” 或者干脆卡在连接中。
原因：三种可能——管理端口不是 14147（被前一个使用者改过）、管理口令不对、14147 只绑了 127.0.0.1 而你在另一台机器上连。
解决：先在服务器本机netstat -ano | findstr 14147确认监听地址；再看FileZilla Server.xml里 administration 段的端口和口令配置；远程管理的话，用 SSH 或远程桌面过去操作，不要为了方便把管理口开放到网络上。
5.3 上传报 550，配置看着全对
现象：客户端上传报550 Permission denied，检查用户权限，Write明明勾了。
原因：权限位和 NTFS 是两套验证。要么漏了Files → Create，要么Delete没给导致覆盖失败，要么共享目录的 NTFS ACL 里没有服务账户的写权限。
解决：按顺序查。先看客户端是在“新建”还是“覆盖”，新建看Files → Create，覆盖看Delete；再用icacls确认SYSTEM有修改权限；最后检查目录是否被设成只读属性。三步都过还不行，把服务日志的Log commands打开，看服务器收到的到底是STOR还是APPE还是DELE，答案就在命令里。
5.4 中文文件名在部分客户端里是乱码
现象：用文件资源管理器（Windows 自带那个）打开 FTP 地址，中文文件名全变成方块或者问号；换 FileZilla Client 或 WinSCP 就正常。
原因：FTP 本身没有规定文件名编码，UTF-8 是靠OPTS UTF8 ON协商出来的。系统自带的 FTP 客户端走的是本地 ANSI 代码页，对 UTF-8 支持很差。这跟汉化包没有关系，汉化改的是管理界面文字，不动传输编码。
解决：对接方如果是程序，强制它发OPTS UTF8 ON；如果是人操作，换一个支持 UTF-8 的客户端。另外尽量别在共享目录路径里用中文和空格，虽然 0.9.x 支持，但一旦出问题，排查成本远高于改个目录名。
5.5 重启或换机器后，配置“自己没了”
现象：在一台机器上调好的用户和目录，整包复制到另一台机器后打开管理端，用户列表是空的，或者还是上一次的旧配置。
原因：服务读的是它自己所在目录下的FileZilla Server.xml。用快捷方式、计划任务、或者别的路径拉起 exe，它就去找那个路径下的 xml，找不到就新建一份空的。另一种情况是复制的时候服务还在运行，xml 处于半写入状态。
解决：停服务，整个目录一起复制，启动时用cd /d切到目录里再执行 exe，不要用快捷方式的工作目录碰运气。迁移完成后在管理端随便改一个无害的配置项（比如欢迎语），确认它能写回同一个 xml，说明路径是对的。
6. 上线前先跑一遍回归：三条命令验完再交付
配置调完不要直接交给使用方，先用命令行客户端跑一遍最小验证集。图形客户端会做很多自动重试和降级，把问题盖住；命令行不掩盖，失败点直接摊在你面前。
# 1. 登录 + 列目录，验证控制连接和被动端口 curl -v --ftp-pasv --user "devuser:Passw0rd" ftp://192.168.1.20/ --list-only # 2. 上传一个真实大小的文件，验证写权限与实际带宽 curl -T ./fw.bin --ftp-pasv --user "devuser:Passw0rd" ftp://192.168.1.20/upload/fw.bin # 3. 显式 FTPS，验证证书加载与 PROT P 是否生效 curl -v --ftp-pasv --ssl-reqd --insecure --user "devuser:Passw0rd" ftp://192.168.1.20/ --list-only-v的输出里重点看两行：227 Entering Passive Mode返回的地址端口是否在设定范围内，以及AUTH TLS之后是否成功切到加密通道。--ssl-reqd是强制走显式 TLS，失败就说明服务端证书没加载好，而不是客户端问题；--insecure只是跳过自签证书的校验，不影响加密本身。第三条失败而前两条通过，问题一定在 TLS 配置上，排查范围直接缩小。
限速和自动封禁是交付前顺手要做的两件事。Edit → Settings → Speed limits里可以设全局上下行，也可以在用户级单独限，单位是 KB/s，做设备批量上传时把上行压到 2000 左右，能防止一个客户端把整条链路吃满。Autoban页打开后，同一 IP 连续登录失败若干次就自动封禁，默认值对内部环境够用，别把次数设成 1，否则密码输错一次就被锁在门外，反而增加运维量。
日志建议开成写文件而不是只看屏幕，Log commands打开后每一条 FTP 命令都有记录，出问题时这是唯一的黑匣子。日志体积增长很快，配合定期清理或者按天切割。
那次给一个车间做文件投递箱，我把权限配好、防火墙放开、curl三条全过，就以为完事了。结果第二天对方说“传上去了但文件是 0 字节”，查下来是他们客户端先STOR建立连接再写数据，中途网络抖动，连接断了但文件句柄留了个空壳，而我没开Append，续传直接失败。从那以后我每次交付 FTP 服务，都会强制走一遍“上传中断再续传”的用例，并且把Append默认打开——这个权限平时看不出价值，出问题时它是唯一能救回半截文件的东西。希望帮到你。
本文还有配套的精品资源，点击获取
