简介：这是面向工业自动化及需要跨PC传输文件场景的技术文档，系统讲解在两台PC间搭建FTP通讯的完整方法。文档以Win 7为环境，从创建FTP用户、启用Windows FTP服务、配置IIS管理器与FTP站点，到使用TwinCAT FTP客户端上传和下载文件，每一步均配有清晰操作说明与参数示例，并给出上传超大文件可能掉线、必须勾选Web管理工具等关键提醒。包体为单个docx文件，共439KB，内容紧凑、针对性强，适合自动化工程师、技术支持人员及需要快速配置FTP服务的用户。文档还包含TwinCAT FTP功能块的变量声明与调用范例，帮助读者在PLC程序中实现文件上传下载，直接加速现场调试。目前已有192人学习，对常见配置细节和排错提示的整理可有效缩短实施时间。
1. 两台PC间FTP通讯：为什么都2024年了还在用这个老办法
两台电脑之间传个大文件，很多人第一反应是U盘拷贝或者微信传文件。但真到实操场景——比如给客户机器送一个2GB的数据库备份、给实验室另一台电脑同步一批传感器日志、在公司内网把构建产物从开发机丢到测试机——U盘够不着，微信压缩包又限大小，网盘走外网一圈绕得人心烦。FTP这个老协议反而成了最不出错的方案：装个服务端，开个客户端，两边都在一个局域网里，20秒连上，传输速度直接跑满网卡带宽。
两台PC间实现FTP通讯的方法，核心就三件事：一台PC当FTP服务器，一台PC当客户端去连，中间的网络端口和权限别拦路。标题里的方法落在实操上无非就是选型、配置、连调、排错四步。这篇文章写给谁？给那些不想为一次临时传输去学一堆新协议、也不想抱着移动硬盘两头跑的工程师。你能在这篇里拿到最小可用的配置步骤、参数取舍和常见的翻车点，照着做，两台电脑的FTP通道十分钟内跑通。
2. FTP协议与连接模式：先搞懂主动和被动，不然你连端口都配不明白
FTP能干活，靠的是两个独立的连接：控制连接和数据连接。控制连接走TCP 21端口，负责发指令，比如登录、列目录、切换路径；数据连接才是真正传文件的那条通道，端口不固定。问题恰恰出在数据连接上——它到底是客户端主动连进来还是服务器主动连出去，分成了主动模式（Active）和被动模式（Passive）两种，选错模式，防火墙策略全白配。
2.1 主动模式与被动模式的握手差异
主动模式的过程是：客户端先和服务器在21端口建立控制连接，然后客户端把自己的IP和一个临时端口告诉服务器，服务器用20端口主动去连客户端的这个临时端口。这个设计在公网场景下马上碰到一个问题——客户端在NAT后面的话，服务器根本连不进客户端的内网IP。
被动模式则是客户端把数据连接的主动权拿过来：客户端先连服务器的21端口发PASV指令，服务器回应一个IP和端口，客户端再去连这个端口。这样一来，服务器只需要开放21端口和一个被动端口范围，客户端不需要开放任何入站端口，NAT后面也能正常工作。
我一般给两台PC做FTP通讯，默认全用被动模式。原因很实在：Win10、Win11自带的防火墙默认放行出站连接，客户端侧几乎不用改策略，而主动模式要求客户端开临时入站端口，Windows防火墙弹窗就能烦死人。下面是两种模式的对比，方便你对号入座：
| 对比项 | 主动模式 | 被动模式 |
|---|---|---|
| 数据连接发起方 | 服务器（20端口） | 客户端 |
| 服务端需开放端口 | 21、20 | 21、被动端口范围（如5010-5100） |
| 客户端需开放端口 | 随机高位入站端口 | 无 |
| NAT/防火墙友好度 | 差，客户端在NAT后会失败 | 好 |
| 适用场景 | 服务器和客户端都在同一局域网且无入站限制 | 绝大多数场景，推荐 |
2.2 服务端软件选型：Windows自带IIS、FileZilla Server还是别的
选哪款服务端软件，取决于你的客户端是什么系统和你对配置复杂度的容忍度。标题里的两台PC，最常见的组合是Windows对Windows，其次是Windows对Linux或Linux对Linux，我按这三类分别说。
第一类是Windows自带IIS的FTP服务，系统功能里勾选「FTP服务」和「IIS管理控制台」就能装，不需要第三方包。优点是系统自带、不用装东西；缺点是配置界面藏得深，被动端口范围要在两三层菜单里翻，而且IIS FTP对用户隔离策略的默认行为在跨机器访问时经常给出乎意料的权限错误。这个方案适合临时用一下、不想装任何额外程序的场景。
第二类是FileZilla Server，我在这类场景里用得最多。它把监听IP、被动端口范围、用户权限、TLS选项都放在一个管理界面里，配置项直白，反馈的信息也够多。更重要的是，它自带主动/被动模式的可视化状态，连不上时能直接看到是哪一步断的。缺点是需要安装一个Windows服务，杀毒软件偶尔会对它的服务注入有误报。
第三类是Linux下的vsftpd。如果你的两台PC里有一台是Ubuntu或者CentOS，vsftpd是事实标准。配置比Windows方案更简单，一个/etc/vsftpd.conf文件搞定全部行为，服务端资源占用极低。代价是你得会用systemctl管理服务、会用ss或netstat看端口监听状态，对纯Windows用户来说门槛偏高。
2.3 核心参数：被动端口范围、超时时间、传输模式
不管你选哪款服务端，有三个参数是你必须显式检查的，默认值往往在生产环境里刚好不够用。
被动端口范围。这项必须设置，否则服务端会在连接时随机挑一个系统临时端口给客户端，防火墙策略根本没法写。我习惯设成5010到5100，一共90个端口，理论上支持45个并发数据连接，对两台PC之间的传输绰绰有余。如果你要在防火墙里放行，记得放行TCP的21和5010-5100，一次写进规则里。
控制连接超时。默认值一般是300秒，意思是控制连接空闲5分钟没指令，服务器就断开。这个参数容易在传大文件时坑人——如果客户端的数据连接传完一个文件后，又长时间不发起下一个指令，控制连接会被服务器掐断，第二次传输直接报错。我一般把这个值调到900秒或更大，反正是两台PC之间的专用通道，没必要省这点资源。
传输模式。ASCII模式和Binary模式的区别是换行符处理，ASCII会把文件内容里的换行做转换，Binary是原样传。两台PC之间传文本、压缩包、ISO、数据库备份这类文件，统一用Binary，省得文件传过去之后校验和都对不上。
3. 用FileZilla Server把一台PC变成FTP服务器：从安装到用户授权
服务端软件定了，接下来就是动手把其中一台PC变成FTP服务器。以下步骤基于FileZilla Server的Windows版本，这是我在两台PC间做FTP通讯时最常用的路径。你跟着把监听IP指对、被动端口配上、用户权限收好，服务端这块就算跑通了。
3.1 安装与初始配置：监听IP和被动端口怎么填
安装FileZilla Server的过程不复杂，一路Next就行，但有一个关键选项在安装向导里容易被跳过去——Server Listening IP（服务监听IP）。默认值是"所有可用IP"，这在一台有多个网卡的PC上是隐患，因为FTP服务会暴露在所有网络接口上。
我建议在安装后立即打开管理界面，进入「编辑 - 设置」做三个修改。第一，在「General settings」里把监听IP改成这台PC实际对外的局域网IP，比如192.168.1.100，而不是留空监听所有接口。第二，在「Passive settings」里勾选「Use custom port range」并填上5010-5100。第三，如果这台PC有防火墙，确认管理界面的「被动端口范围」和你后续在防火墙里放行的范围一致，差了任何一个端口都可能出现连得上但传不了的情况。
三个配置改完后，重启一下FileZilla Server服务，然后在管理界面里确认状态是「Online」。这时候你在同网段的另一台PC上执行一个telnet测试，可以看到21端口已经开放：
telnet 192.168.1.100 21正常会看到类似220-FileZilla Server的欢迎横幅。如果telnet直接提示无法连接，先查服务状态和Windows防火墙，别急着折腾用户权限。
3.2 创建用户和虚拟目录：把访问权限精确到目录级
服务端安装完了，接下来是用户授权。FileZilla Server的权限模型是「用户 + 挂载点」，每个用户添加虚拟目录，映射到服务器本地的真实路径。
我在管理界面的「用户」标签页里点「添加用户」，用户名和密码按需设。然后关键一步是「挂载虚拟目录」——我一般把FTP的根目录挂到这台PC的一个专门数据盘上，比如D:\ftproot，不挂C盘系统目录，避免日志和临时文件把系统盘塞满。
权限勾选上，「文件」里的「读取」和「写入」是基础，目录里的「列出」和「创建」按场景开。如果你只做单向推文件，客户端负责往服务器传，那就勾读取和列出，写入和创建不勾——少一个权限少一个坑。下面是用户权限的常用组合表：
| 使用场景 | 需要的权限 | 建议关闭的权限 |
|---|---|---|
| 双向文件同步 | 文件的读取+写入，目录的列出+创建 | 无 |
| 客户端单向上传备份 | 文件的写入，目录的创建 | 文件的读取、删除 |
| 客户端单向下载分发 | 文件的读取，目录的列出 | 文件的写入、删除 |
| 多人共享目录 | 文件的读取，目录的列出 | 全部写权限 |
这里有个细节很容易踩坑：FileZilla Server对「追加」权限的控制跟「写入」是分开的。如果你向服务器传的是日志文件，希望每次追加而不是覆盖，必须单独勾选「追加」。经常有人只勾了写入，结果日志文件每次都被覆盖成单行，然后跑来问为什么文件内容丢了。
3.3 防火墙入站规则怎么加：一次放行21和被动端口段
Windows防火墙默认拦入站连接，就算FileZilla Server本身跑起来了，外部的客户端还是进不来。我每次装完服务端后的固定动作，是把入站规则按端口段写进防火墙。
用管理员权限打开PowerShell，执行下面的命令，一次创建两条入站规则：
# FTP控制端口21 netsh advfirewall firewall add rule name="FTP_Control_21" dir=in action=allow protocol=TCP localport=21 # FTP被动数据端口5010-5100 netsh advfirewall firewall add rule name="FTP_Passive_5010-5100" dir=in action=allow protocol=TCP localport=5010-5100第一条规则放行21端口，保证控制连接能建立；第二条放行被动模式的数据端口段，保证实际传输能走通。命令里的dir=in指入站方向，action=allow是放行，protocol=TCP限定协议，localport指定本机端口。执行完后，可以在「Windows Defender防火墙 - 高级设置 - 入站规则」里看到这两条记录。
顺带说一个经验：如果你用了一款第三方安全软件，比如360或者火绒，它们的网络防护组件会独立于Windows防火墙做拦截，需要在软件自己的「联网控制」里放行FileZilla Server进程，不然你Windows防火墙全放行了，流量还是到不了FTP服务。
4. 客户端怎么连：cmd下的ftp命令和图形化客户端选哪个
服务端就绪，剩下就是客户端这台PC的事了。连接FTP有两条路：一条是用Windows自带的命令行ftp工具，适合写脚本和自动化；一条是装FileZilla Client或WinSCP这类图形化工具，适合手动操作和调试。两条路我都常用，分场景选。
4.1 cmd下ftp命令的最小可运行脚本：登录、切目录、传文件、退出
带参数的FTP手动操作偶尔可用，真要连续传多个文件，Windows自带的ftp.exe其实能跑批处理。我习惯把一组ftp命令写在文本文件里，然后用ftp -s让脚本逐行执行，这样能自动传一批文件。
假设服务端IP是192.168.1.100，用户名是ftpuser，密码是ftppass。新建一个upload.txt，内容如下：
open 192.168.1.100 ftpuser ftppass binary prompt off lcd D:\local_data cd /uploads mput *.bak bye然后在这个文本文件所在目录执行：
ftp -s:upload.txt这段脚本的每一行都是cmd下ftp的保留指令：open建立连接，紧接着两行是用户名和密码；binary把传输模式切成二进制，保证文件字节不被改动；prompt off关闭逐个询问，配合mput批量上传时不会每个文件都停下来让你按y确认；lcd切换本地工作目录，cd切换服务器目录，路径对不上会在屏幕上直接报550错误；mput *.bak把当前本地目录下所有.bak文件传上去。最后bye断开。
脚本里的路径要特别注意。lcd D:\local_data是客户端本机路径，cd /uploads是服务器上相对FTP根目录的路径，这个根目录对应服务端挂载的虚拟目录，比如D盘的那个目录。cmd的ftp工具没有ls之外的本地浏览能力，路径写错只能靠报错信息反推。
4.2 图形化客户端连接：FileZilla Client的站点管理器配置项怎么填
图形化工具里，FileZilla Client和WinSCP都免费且成熟。我只说FileZilla Client的站点管理器里跟两台PC通讯直接相关的四个配置项。
主机填服务器IP，比如192.168.1.100；端口默认21，如果你在服务端把监听端口改了才需要动这里；协议选「FTP - 文件传输协议」，别选成SFTP，SFTP走的是SSH端口22，跟今天搭的FTP不是一回事；登录类型选「正常」，填用户名密码。
连接前点开「传输设置」标签，确认「被动」模式是选中状态。如果不改，FileZilla Client默认就是被动模式，但如果是旧版或者配置被重置成了主动，连接后会一直卡在列目录那一步。我习惯性在这个界面看一眼——治好了我好几次「连上但啥也看不见」的毛病。
图形化客户端还有一个隐藏功能适合双机调试：传输失败时，窗口下方会显示具体的FTP响应码。比如530是认证失败，550是权限或路径问题，425是数据连接建立失败。看到425，九成是被动端口没放行，返回服务端检查防火墙规则。
4.3 Windows文件管理器直接访问FTP：另一种零安装连接方式
如果两台PC都是Windows，其实还有第三条路——资源管理器地址栏直接输入FTP地址。在另一台PC的文件夹地址栏输ftp://192.168.1.100，回车后提示输入用户名密码，连上后就是一个普通文件夹窗口，拖文件进去就等于上传。
这种方式不依赖任何第三方客户端，但两个限制你要知道。一是它默认走被动模式的，而且Windows的WebClient服务如果被停用了会提示无法访问；二是中文文件名偶尔出现乱码，因为资源管理器访问FTP默认用的编码跟FileZilla Server的UTF-8设置不一定对齐。
给个直接判断：临时传几个文件、不想装软件，用资源管理器；要传批量文件、要反复连通断、要写进自动化，用命令行脚本；要看得见传输进度和排错细节，用FileZilla Client。三种方式连的是同一个服务端，按需切就行。
5. 两台PC间FTP通讯避坑指南：连不上、传不动、传完变了
双机FTP最气人的故障不是完全连不上，而是看着连上了、目录也列出来了，一传大文件就死，或者传完了校验才发现文件缺了字节。这批问题我按「现象 → 原因 → 解决」写了四条，都是我在真实环境里反复踩过的。
5.1 现象：客户端能登录，但列目录卡死或超时
这个现象很经典：可以用ftp客户端看到登录成功的欢迎信息，但一列目录就转圈，最后超时断开。你重试几次会发现登录永远成功，目录永远出不来。
原因在被动模式的数据连接没走通。登录用的是21端口，那是控制连接；列目录需要开一条数据连接去传目录列表。服务端的被动端口5010-5100如果在防火墙里没放行，服务器发出PASV响应后，客户端去连5010端口被拦，自然卡死在列目录这步。
解决方法是回到第3.3节那两条netsh命令，确认5010-5100的入站规则存在且生效。另一个隐蔽点：云主机或虚拟机如果带了安全组，规则做在安全组层面，Windows防火墙放行了也没用，要去安全组的入站规则里把同样的端口段加上。
5.2 现象：传大文件到一半断掉，小文件正常
只传小文件时一切正常，传一个500MB以上的压缩包就中途断开，重连后从头再传。这个现象通常不是网络抖动，而是两个超时参数合谋的结果。
原因有两个走向。一个是服务端的控制连接超时设短了，FTP控制连接长时间闲置会被服务端掐掉，但数据连接还在传，断了之后客户端不知道控制连接已失效，等到传完才发现没有回执。另一个是客户端的防火墙或NAT会话老化时间太短，无状态防火墙会在长时间数据流上自动清会话。
解决方法是把服务端的控制连接超时调大到900秒以上，同时把客户端的TCP超时参数也用系统默认值，不要手动调小。如果是跨网段传输，检查中间设备的会话老化时间是否低于传输预计时长。Windows专有网络的网络配置文件改成「专用网络」，也会减少系统防火墙对长连接的中途插断概率。
5.3 现象：传上去的文件md5和源文件对不上
传输结束显示成功，文件大小也对，但接收方打开压缩包报损坏，用脚本比对md5会发现不一致。这是FTP最容易被忽略的坑：传输模式选成了ASCII。
原因在ASCII模式下，FTP客户端和服务器会对换行符做转换，Windows的CRLF和Linux的LF互相转换，任何二进制文件经过这种转换都会悄悄被改字节。压缩包、可执行文件、镜像文件、数据库文件但凡被ASCII模式传过，几乎必坏。
解决方法是客户端连接后明确执行binary指令，或者在图形客户端里把默认传输模式改成二进制。对于已经传坏的文件，没有后悔药，只能重新传输。我一般在批处理脚本里第一行就写binary，防止默认模式坑人。
5.4 现象：FTP服务正常，但另一台PC就是ping不通
连FTP之前先ping服务器IP，发现根本不通，于是怀疑FTP服务没起来。但服务端本机看FTP服务明明是正常的。
原因是两台PC不在同一网段，中间隔着交换机或路由器，网络互通本身就没解决。FTP是应用层协议，底层的IP连通性是前提条件。ping不通就不要查FTP了，先把网络弄通再说。
解决方法是检查两台PC的IP地址和子网掩码，判断是否在同一网段。不在的话，要么改IP到同一网段，要么在路由器上配静态路由，要么把其中一台PC的网关指到路由器。这里用一套命令在客户端查一下网络状态就能定位：
ipconfig /all ping 192.168.1.100 -t tracert 192.168.1.100ipconfig /all看自己IP和网关，ping -t持续探活，tracert看路由到哪里断了。定位到网络层不同，FTP的配置再正确也白搭——这是所有FTP排错里最基础也最容易被忽略的一条。
6. 把FTP传输写成自动化：批处理脚本与定时任务，附一份传输后的完整性检查办法
手动传输跑通只是第一步，真实工作中用到两台PC间FTP的场景，往往是重复的：每天下班后把日志从A机拽到B机、每周把数据库备份推到备份服务器。这类需求一旦做一次两次还可以手点，做一个月就烦了。把FTP命令封装成批处理，再用Windows任务计划程序定时跑，是成本最低的自动化路径。
6.1 用批处理封装FTP会话：自动登录上传并记录日志
延续第4.1节的脚本思路，把命令行ftp工具的指令写进脚本文件，再包一层批处理做时间戳和日志。下列代码保存为upload.bat：
@echo off set BACKUP_DIR=D:\local_data set FTP_SERVER=192.168.1.100 set FTP_USER=ftpuser set FTP_PASS=ftppass set LOG_FILE=D:\logs\ftp_upload_%date:~0,4%%date:~5,2%%date:~8,2%.log echo %date% %time% - Start FTP upload >> %LOG_FILE% echo open %FTP_SERVER% > D:\temp_ftp_cmd.txt echo %FTP_USER% >> D:\temp_ftp_cmd.txt echo %FTP_PASS% >> D:\temp_ftp_cmd.txt echo binary >> D:\temp_ftp_cmd.txt echo prompt off >> D:\temp_ftp_cmd.txt echo lcd %BACKUP_DIR% >> D:\temp_ftp_cmd.txt echo cd /uploads >> D:\temp_ftp_cmd.txt echo mput *.bak >> D:\temp_ftp_cmd.txt echo bye >> D:\temp_ftp_cmd.txt ftp -s:D:\temp_ftp_cmd.txt >> %LOG_FILE% 2>&1 echo %date% %time% - End FTP upload >> %LOG_FILE% del D:\temp_ftp_cmd.txt这个批处理做了四件事：动态生成ftp命令脚本、执行ftp会话、把屏幕输出重定向到日志文件、结束后删除临时脚本。密码明文写进临时文件，用完即删，常年在命令行混的人都这么干，但你也得知道这是一个风险项——如果在多人共用的机器上跑，这个临时文件在批处理运行期间是能被其他进程读到的。
定时执行交给Windows任务计划程序：打开「任务计划程序 - 创建基本任务」，触发器选「每天」并设定时间，操作选「启动程序」，程序填upload.bat的完整路径。关键设置「使用最高权限运行」这个选项别勾，除非你的FTP账号真的需要管理员权限访问共享目录，否则多一个权限就多一条被攻击的路。
6.2 传输完整性检查：拿文件大小和md5给结果兜底
FTP本身不校验文件完整性，传输状态码是0不代表文件内容没坏。我在自动化脚本里加了两道检查，这道工序能提前揪出第5.3节那种ASCII模式传坏文件的情况，不需要等到接收方打开压缩包才发现。
第一道是文件大小校验。在批处理脚本里ftp执行完后，用dir命令对比源文件和目标机的文件大小。严格的做法是在服务器端执行SIZE指令读取远端文件大小，和本地%zp变量比对——但cmd的批处理对FTP交互能力有限，我实际用得更粗暴：在传输开始前和结束后各拉一次远端目录列表，存入本地文件，再比对文件大小列。
# 这一步适合在另一台PC上做客户端侧校验，把远端文件名和大小拉到本地 ftp -s:list_remote.txt > remote_list.log第二道是md5或SHA256校验。FTP协议本身不带校验和，但现代服务器大多支持MFMT这类扩展命令，不会帮你算哈希。常用的做法是在目标机上单独跑一个校验脚本，或者如果两侧都是Windows，用PowerShell的Get-FileHash对刚传完的文件做比对。做进自动化的代价是多一步远程执行，但换来的确定性很强——文件对不对，用哈希说话，比「传输成功」四个字靠谱得多。
6.3 我的收尾习惯：每次配置完FTP通道，固定做两件事
一个是把被动端口范围、防火墙规则、账号权限这三样打成一个文档，放在服务器PC的桌面上。半年后你忘了当初怎么配的，翻这个文档比翻聊天记录快得多。另一个是首次连通后立刻传一个测试文件、删除、再传，确认真实路径和权限都没问题再交给方使用——我在这上面吃过亏，以为配置没问题就放手，结果别人第一次用就连不上，最后查了半小时发现是服务端临时改了监听端口没同步给对接人。
两台PC间的FTP通讯，技术上没有任何玄学，就是端口、权限、模式、防火墙四件事。把这四件事理顺，十分钟内跑通是常态；理顺不了，就是信息在某一环断掉了。希望这些配置和排查习惯能帮到你，省下那些在防火墙和端口之间反复来回的时间。
本文还有配套的精品资源，点击获取
