企业官网建设流程全解析

简介：这是一份针对外网无法访问局域网FTP服务器问题的技术方案PDF，面向网络管理员、运维人员及遇到FTP外网连接故障的技术支持者。资料以FTP协议两种工作方式为主线，结合ADSL、NAT与Serv-U搭建的真实实验环境，完整复现映射21端口、20端口及10001-10004端口三种场景，逐一分析Port主动模式与Pasv被动模式在NAT环境下连接、列目录、下载文件失败的原因，并给出Serv-U启用动态DNS与指定被动端口等解决建议，帮助读者掌握从现象定位到配置修复的完整排错思路。全包仅包含1个PDF文档，体积122KB，内容紧凑可直接查阅。截至目前已有1092人学习下载，适合需要快速理解FTP主动/被动模式差异并解决内网穿透访问问题的网络技术人员。

1. 外网连不上局域网 FTP 服务器：先分清是“连不上”还是“列不出目录”

公司内网一台 Serv-U 跑得好好的，局域网里上传下载都正常；一出外网就翻车——账号密码能过，登录框也跳过去了，紧接着弹一句“打开 FTP 服务器上的文件夹时发生错误，请检查是否有权限访问该文件夹”。很多人第一反应是去调 NTFS 权限、改 Serv-U 目录权限，折腾半天一点用没有。这个报错是个经典的误导项，真正的问题往往出在 FTP 的数据通道上：控制链路通了，数据链路没通。这份文档用一组 ADSL + NAT + Serv-U 的真实实验，把外网访问局域网 FTP 服务器的完整链路拆开了——从 IE 的被动 FTP 复选框，到 21、20、10001-10004 三组端口映射，再到 Serv-U 如何把外网 IP 返回给客户端。适合正在被同类问题折磨的网络管理员和运维，也适合刚接触 FTP 服务搭建、想搞懂主动和被动模式到底差在哪的人。

2. FTP 的两种工作模式：PORT 与 PASV 到底谁连谁

很多人配 FTP 服务只关心“能登录”，不关心“数据怎么走”。一旦放到 NAT 后面，登录和数据传输就开始分家。要搞懂外网访问局域网 FTP 服务器的问题，必须先理解 FTP 和 HTTP 的本质差异：HTTP 一条通道干完所有事，FTP 必须要两条通道。

2.1 命令链路与数据链路：FTP 为什么比 HTTP 多一条通道

FTP 客户端连接服务器时，第一步永远是向服务器的 21 端口发起 TCP 连接，这条连接叫命令链路（控制信道），用来传用户名、密码、PORT、PASV、LIST、RETR 这些指令。整个 FTP 会话期间，这条命令链路一直保持不断。

但列目录、传文件这些动作要的是数据。数据走的是另一条独立的 TCP 连接，叫数据链路（数据信道）。这条链路什么时候建、由谁发起，取决于当前使用的是 PORT 模式还是 PASV 模式。数据链路是临时建立的，一次列目录建一条，传完就断；下次再列再建。

所以“能登录”只证明命令链路是通的，“能列目录”才证明数据链路也通了。排障时看到登录成功但列目录卡死或报错，第一反应就应该是数据链路问题，而不是权限问题。

2.2 PORT 主动模式：服务器用 20 端口回头连客户端

PORT 方式也叫主动方式。客户端向服务器 21 端口发连接请求，命令链路建立后，客户端通过这条链路发一个 PORT 命令，告诉服务器“我在某个空闲端口（比如 3328）等着收数据”。服务器收到后，用自己的 20 端口主动向客户端那个端口发起新连接，建起数据链路。

这里有两个关键特征：一是服务器使用固定的 20 端口作为数据源端口；二是数据连接由服务器主动发起。只要客户端在防火墙后面或者 NAT 网关后面，服务器主动发起的这条新连接基本会被拦掉——防火墙规则默认不允许外部主动连入内网客户端的临时端口。

所以在纯外网环境下，客户端的防火墙通常不愿意放行主动模式的入站连接。文档里的实验结果也验证了这一点：客户端环境有 NAT 或防火墙拦截时，PORT 方式能建立命令链路，但数据链路建立不了，表现出来就是能登录、不能列目录。

2.3 PASV 被动模式：服务器报一个高端口，客户端主动去连

PASV 方式也叫被动方式。客户端依然先连服务器的 21 端口建立命令链路，然后发 PASV 命令。服务器收到后，打开一个临时的数据端口（一般在 1024 到 5000 之间），把这个 IP 和端口通过命令链路告诉客户端，由客户端主动向这个端口发起连接。

这个模式下数据链路是客户端发起的，所以客户端在防火墙或 NAT 后面也能正常工作——出站连接一般不会被拦。但这带来一个新问题：服务器必须保证自己返回的 IP 和端口，客户端真的能连到。

这恰恰是局域网 FTP 被外网访问时最大的坑：服务器在 NAT 后面，它不知道自己对外是公网 IP，PASV 响应里直接把内网 IP 报给客户端。客户端拿着 10.x.x.x 这种地址去连，当然连不上。这是文档第四部分重点解决的问题。

2.4 IE 的两个复选框联动：文件夹视图不清掉，被动 FTP 勾了也白勾

IE 访问 FTP 有个非常隐蔽的坑：工具 → Internet 选项 → 高级里有两个选项，一个叫“为 FTP 站点启用文件夹视图”，一个叫“使用被动 FTP（为防火墙和 DSL 调制解调器兼容性）”。这两个选项不是独立的。

如果“为 FTP 站点启用文件夹视图”处于选中状态，IE 的行为会像标准模式 FTP 客户端一样——即使你同时勾选了“使用被动 FTP”，它依然按主动模式跑。文档原话是：需要清除“为 FTP 站点启用文件夹视图”，再选中“使用被动 FTP”，IE 才会真正以被动模式客户端的方式工作。

我一般会这样设置：把“为 FTP 站点启用文件夹视图”前面的勾去掉，把“使用被动 FTP”前面的勾打上，确定后重开 IE。这样可以避免 IE 把主动模式的行为和被动模式的选项混在一起，产生“明明设置了却没用”的错觉。IE 6.0 以上版本才支持被动 FTP 选项，老系统上如果找不到这个复选框，优先检查 IE 版本。

3. NAT 下的三组映射实验：21、20、10001-10004 各解决哪一层

文档里最有价值的部分是一组对照实验。实验环境是 ADSL 公网地址 219.154.214.150，NAT 网关内网地址 10.41.221.2，FTP 服务器 PC 地址 10.41.221.6，跑 Serv-U。外网客户端发起连接，逐步调整 NAT 端口映射，观察 PORT 和 PASV 两种模式分别表现如何。这组实验把数据链路的问题拆成了三层：命令链路、主动数据链路、被动数据链路。

3.1 实验拓扑与第一轮：只映射 21 端口，两个模式都只能登录不能列目录

第一轮实验只把公网的 21 端口映射到内网 PC 的 21 端口，Serv-U 默认配置不动。测试结果是：PORT 方式能连接、不能列目录；PASV 方式能连接、不能列目录。

这个结果很容易解释。21 端口映射到位了，命令链路就通了，所以两种模式都能登录。但数据链路还没有任何映射：PORT 模式需要服务器从 20 端口主动连客户端，NAT 网关根本没有对 20 端口做映射，外网侧的连接无法正确转发到内网服务器；PASV 模式需要客户端去连服务器的被动数据端口，而 Serv-U 此时使用的是随机高端口，NAT 网关不知道要把这些端口转发到哪里。数据链路不通，自然列不出目录。

这里的排查要点是：能登录说明 NAT 对 21 的映射已经生效，不需要再怀疑 Serv-U 的域名配置或共享权限，问题收敛在“数据链路没有对应映射”这一个方向上。

3.2 第二轮：补上 20 端口，PORT 立刻恢复读写

第二轮实验在原有 21 端口映射的基础上，再增加一条 20 端口到内网 PC 的映射。结果：PORT 方式能连接、能列目录、能下载文件；PASV 方式能连接、不能列目录、不能下载文件。

PORT 方式恢复正常的原理很直接：PORT 模式服务器使用固定源端口 20 向客户端发起数据连接，NAT 把公网 20 端口映射到内网 PC 的 20 端口后，这条数据链路就能正确建立。也就是说，主动模式需要映射两个端口：命令端口 21 和数据端口 20，缺一个都不行。

PASV 方式依然失败也在预期内：被动模式需要的是服务器动态开放的端口段，而不是固定的 20。NAT 没有为被动端口段做映射，客户端即便收到服务器返回的端口号，连接请求也到不了内网。这个现象进一步证明，两种模式的数据链路规则完全不同，映射方案不能一概而论。

3.3 第三轮：切到 10001-10004 端口段，PASV 依然列不出目录

第三轮实验关掉了 20 端口的映射，把 10001-10004 这 4 个端口映射到内网 PC 的相同端口。同时 Serv-U 中启用被动模式，并将被动端口段设置为 10001-10004。结果是：PORT 方式能连接、不能列目录、不能下载文件；PASV 方式能连接、不能列目录、不能下载文件。

PORT 方式表现倒退是正常的，因为 20 端口映射被移除了，服务器没法再用固定端口主动连客户端。PASV 方式有了端口段映射，为什么还是列不出目录？这是整个实验最关键的一处转折：端口已经映射了，命令链路也通，客户端也确实拿着服务器返回的端口去连了，但服务器在 PASV 响应里返回的是内网 IP 10.41.221.6。

外网客户端收到这个 PASV 响应后，尝试连接的是 10.41.221.6:10001。这个地址是私网地址，在公网上不可路由，连接根本到不了 NAT 网关，更不可能被转发到内网服务器。端口映射做了，IP 返回错了，整个链路还是断的。这就引出了第四部分的核心：Serv-U 必须把公网 IP 返回给客户端。

三组实验的完整对比如下：

3.4 症状定位：登录成功是分水岭，问题全在数据链路

三组实验看起来步骤多，但归纳下来就是一条判断链。第一步看能不能登录：登录失败，说明 21 端口映射没生效，或者 Serv-U 服务没起来；登录成功但列目录失败，说明命令链路没问题，接下来只查数据链路。

数据链路再分两条路：PORT 方式出问题，查服务器 20 端口到客户端的出站链路，以及客户端防火墙是否拦截入站连接；PASV 方式出问题，查两件事——NAT 是否映射了被动端口段，以及 Serv-U 返回给客户端的 IP 是不是外网可达地址。大多数外网访问局域网 FTP 服务器的案例，最后都卡在这两个检查项上。

这个定位思路不限于 Serv-U，换到 vsftpd、FileZilla Server 同样适用。区别只是被动端口段和返回外网 IP 的配置入口不一样，排查顺序完全一致。

4. Serv-U 被动模式落地配置：端口段、外网 IP 返回与 NAT 联动

实验证明了一个结论：被动模式下，仅仅在 NAT 上映射端口还远远不够，Serv-U 必须向客户端返回一个外网可达的 IP 和端口。这一章把 Serv-U 的配置步骤和参数讲透，照着做就能让外网客户端用 PASV 方式正常列目录、下载文件。

4.1 在 Serv-U 中启用被动模式并绑定端口段

Serv-U 的被动端口段配置在域名级别的设置里，不是全局选项。打开 Serv-U 管理控制台，选中对应的 FTP 域名，进入 Settings（设置）→ Advanced（高级）选项卡。在这里找到“Allow passive mode data transfer”（允许被动模式数据传送）的选项，勾选启用，然后在旁边的端口范围框里填入计划使用的端口段。

常见做法是填 10001-10004，也就是文档实验里用的范围。这个范围要跟 NAT 映射保持一致，否则客户端连不进来。填完保存后，Serv-U 会立即把这几个端口置为监听状态，可以用 netstat 验证——这是判断配置是否生效最快的办法。

关于这个配置，文档特别指出：这些端口在设置后马上进入监听状态，而不是等客户端发 PASV 命令时才临时打开。端口段一旦被占用，别的程序就不要再使用相同端口。另外，Serv-U 还允许指定被动模式使用的网卡 IP，在只有一个内网 IP 的服务器上不需要额外配置，多网卡环境建议显式指定，避免返回错误的网卡地址。

4.2 让 PASV 返回外网 IP：固定地址与动态域名两条路

端口段配好后，还有一个必须先解决的问题：Serv-U 在 PASV 响应里返回的 IP。默认情况下，Serv-U 会把服务器本机网卡的 IP——也就是内网地址——告诉客户端。必须改成外网可达的地址。

Serv-U 的响应流程是：客户端发 PASV 命令，Serv-U 在允许被动模式数据传送的配置项里，会指定一个 IP 地址框。文档给的操作路径是：在域名属性里勾选“Enable dynamic DNS”，会出现第二个标签 Dynamic DNS，到 tz0.com 申请动态域名，拿到 key 后填入。这样 Serv-U 在返回 IP 和端口前，会先查询到外网地址再发送给客户端。

如果你的出口有固定公网 IP，更省事的做法是直接在 Advanced 设置里那个 IP 地址框填入固定公网地址。文档特别提醒：拨号用户这个框不用填，只有出口使用固定地址才需要填。动态域名方案适合 ADSL 拨号这类公网 IP 会变的场景，固定 IP 方案适合专线或静态公网 IP 的场景。

无论哪种方案，目标都是同一个：保证 PASV 响应里的 IP 是客户端能连到的公网地址，而不是 10.41.221.6 这种内网地址。这一步不做，前面端口段映射全白费。

4.3 NAT 映射与防火墙放行的完整参数表

配置完 Serv-U 之后，NAT 网关和防火墙的参数需要和 Serv-U 侧完全对齐。下面这张参数表可以直接抄作业，适用于 ADSL 路由器或企业 NAT 网关做端口映射的场景：

实际操作中我一般会把每一项在 NAT 网关和 Serv-U 两侧各核对一遍，列个清单：公网端口范围、内网 IP 端口、协议、Serv-U 端口段、Serv-U 返回 IP。两边任何一项对不上，都会出现“能登录但列不了目录”的复现。

服务器侧的系统防火墙同样要放行。Windows 防火墙需要新建两条入站规则：一条放行 TCP 21，一条放行 TCP 10001-10004。只放行 21 不放行数据端口段，外网客户端一样会卡在列目录这一步。

4.4 端口段要按并发数规划：10001-10004 只够四个会话

10001-10004 这个范围来自原文档的实验配置，但它只是一个验证用的最小集合。每个被动模式的数据传输会话会占用被动端口段中的一个端口，如果有 4 个用户同时列目录、传文件，4 个端口刚好用完；第 5 个用户发起 PASV 请求时，Serv-U 无端口可用，客户端就会卡在“正在连接数据端口”上。

所以生产环境规划端口段时，我一般按预期并发数乘以一个余量系数来定。预期 20 个并发，就开 10001-10040；预期 50 个并发，就开 10001-10080。端口段的上下限在 Serv-U 和 NAT 映射两侧都要同步修改，并保证这一段端口没有被其他服务占用。

文档也提示了另一个现实约束：被动端口段不要超过 5000。原文的说法是“端口在 1024-5000 之间，不要大于 5000，我设置 5000 以上就不能建立 TCP 连接”。这个现象的具体机制文档没有展开，但实际测试结论如此。这属于经验型约束，不必纠结原理，规划端口段时直接把上限压在 5000 以内即可。另外，端口段越宽，防火墙需要放行的范围越大，安全性越差。把端口段控制在满足并发需求的最小范围内，是更稳妥的做法。

5. 外网 FTP 排障避坑：五个高频坑的现象、原因与对策

这一章是从实际踩坑记录里整理出来的。每一个坑都真实出现过，而且症状相似、原因各异，最容易让人反复试错。

5.1 坑一：IE 勾了“使用被动 FTP”却还是主动行为

现象：IE 里已经勾选了“使用被动 FTP（为防火墙和 DSL 调制解调器兼容性）”，访问外网 FTP 依然报错，行为表现和主动模式完全一致。

原因：IE 的“为 FTP 站点启用文件夹视图”选项没有清除。只要这个选项处于选中状态，IE 就会像标准模式 FTP 客户端一样工作，即使被动 FTP 复选框已勾选，也不会真正使用 PASV。文档明确指出了这个联动关系：必须同时清除“文件夹视图”并选中“使用被动 FTP”，IE 才表现为被动模式客户端。

解决：工具 → Internet 选项 → 高级 → 浏览节点下，把“为 FTP 站点启用文件夹视图”前面的勾去掉，再确认“使用被动 FTP”已勾选，确定后重启 IE。之后再次访问 FTP 地址验证。

5.2 坑二：报“检查是否有权限访问”不是权限问题

现象：外网客户端登录 FTP 成功后，列目录时报“打开 FTP 服务器上的文件夹时发生错误，请检查是否有权限访问该文件夹”。运维第一反应是改 Serv-U 目录权限、改 NTFS 权限，改完依然报错。

原因：这个报错是权限提示的假象。登录成功证明命令链路通了，列目录走的是数据链路。数据链路没建立，客户端无法获取目录列表，IE 就把错误呈现为“无法访问文件夹”——它用 NTFS 的权限错误文案来描述数据通道故障。

解决：不要碰权限配置。按第 3 章的排查顺序检查数据链路：先确认 NAT 是否映射了被动端口段，再确认 Serv-U 返回的 IP 是否为公网地址。多数情况下问题出在 Serv-U 返回内网 IP，或 NAT 只映射了 21 端口。

5.3 坑三：被动端口段设在 5000 以上，TCP 连接建立不了

现象：Serv-U 把被动端口段设置为 10001-10004 以外的更大端口，比如 20000-20010，NAT 映射同步修改后，外网客户端依然无法列目录，且抓包能看到客户端 SYN 包发出后没有响应。

原因：原文档实测表明，Serv-U 的被动端口段超过 5000 时无法建立 TCP 连接。文档没有给出理论解释，原话是“为什么呀，我也不知道”，但这属于可复现的实测结果。在 1024-5000 之间选端口段，连接就能正常建立。

解决：把 Serv-U 被动端口段控制在 1024-5000 以内。常见做法是用 4001-4050 这类未被其他服务占用的范围，再同步修改 NAT 映射和防火墙放行规则。端口段上限压到 5000 以内，规避这个玄学问题。

5.4 坑四：PASV 返回的是内网 IP，客户端拿着内网地址去连

现象：NAT 已映射端口段，Serv-U 已设置被动端口段，客户端依然列不出目录。抓包查看 PASV 响应，发现服务器返回的 IP 是 10.41.221.6，客户端正尝试连接这个私网地址。

原因：Serv-U 默认返回服务器本机网卡 IP。服务器在 NAT 内网时，这个 IP 是私网地址，公网客户端无法路由到它。NAT 映射解决的是端口转发问题，PASV 响应里的 IP 字段必须单独处理。

解决：按第 4 章的配置，在 Serv-U 高级设置里填写固定公网 IP，或启用动态域名功能，让 Serv-U 在返回 PASV 响应前先查询外网地址。配置后重新抓包，确认 PASV 响应里的 IP 已变成公网地址。

5.5 坑五：端口范围放太宽，把被动模式变成安全隐患

现象：有些运维嫌端口段不够用，直接在防火墙里放行全部 1024-5000 端口。FTP 服务持续运行一段时间后，服务器出现被扫描、被爆破的迹象。

原因：被动模式要求服务器开放一段数据端口，但这段端口本质上是额外暴露的攻击面。文档提到，防火墙管理员通常不希望使用 PASV，因为服务器可以打开任何短暂端口号，如果防火墙配置允许未经请求的连接完全访问所有短暂端口，可能会不安全。

解决：按实际并发数规划最小端口段，而不是对半开。NAT 映射和防火墙放行只针对这一段端口，其余端口保持关闭。FTP 服务设置强账号密码，避免使用 admin、ftp 这类弱口令——FTP 弱口令爆破是服务器被入侵的高发入口。端口段收敛到 10001-10020 这类固定范围，比全段放行要安全得多。

6. 配置完怎么看是否生效：抓包、netstat 与三种客户端交叉验证

配置完 Serv-U 和 NAT 映射后，不能只看客户端“能下载了”就收工。完整的验证流程需要覆盖三层：端口监听、PASV 响应内容、真实数据传输。

第一步验证服务器端口监听状态。在 Serv-U 服务器上执行 netstat，确认被动端口段已进入监听状态。Windows 下可以用：

# Windows 下查看 Serv-U 是否监听被动端口段 netstat -an | findstr 10001

如果输出里有 0.0.0.0:10001 的 LISTENING 记录，说明 Serv-U 已经按配置打开了被动端口。如果看不到任何记录，说明 Serv-U 的被动模式没有真正启用，检查高级设置里的勾选和端口段。Linux 上的 vsftpd 等 FTP 服务器可以用 ss 命令验证同样的内容：

# Linux 下验证 FTP 被动端口段监听状态 ss -ltnp | grep -E '10001|10002|10003|10004'

第二步抓包验证 PASV 响应。在客户端侧抓取与服务器 21 端口交互的报文，重点关注 PASV 命令后的响应内容：

# 抓取 FTP 控制链路报文，观察 PASV 响应中的 IP 和端口 tcpdump -i eth0 -nn port 21 or portrange 10001-10004

抓包结果中，PASV 响应应该形如“227 Entering Passive Mode (x,x,x,x,p1,p2)”，其中 x.x.x.x 必须是外网可达的公网地址，p1、p2 计算出的端口必须在 10001-10004 范围内。如果响应里是内网 IP，说明 Serv-U 的外网 IP 返回配置没生效，直接检查动态域名或固定 IP 设置。

第三步用三种客户端做交叉验证。IE 需要先按 2.4 清理“文件夹视图”复选框，再勾选“使用被动 FTP”；FileZilla 在传输设置里选“被动”；命令行 ftp 客户端用于快速验证端口映射连通性。三种客户端同时通过，才能确认配置对多数场景有效；只有其中一种能通，往往是客户端自身设置问题，而不是服务器配置问题。

从那以后我每次配完 FTP 服务，都强制走一遍这套流程：netstat 确认监听端口段、抓包确认 PASV 响应是公网 IP、三种客户端交叉测试，再顺手检查一遍账号口令强度。这套习惯帮我挡掉了太多“看似通了但换个网络就断”的返工。希望这份从实验到排障的完整记录，也能帮你少踩几个同样的坑。

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