企业官网建设流程全解析

简介：针对Windows 7系统下两台PC间的FTP通讯搭建，这份DOCX文档提供了一套完整且可直接落地的操作指南，面向需要借助FTP实现文件共享与远程传输的工控、自动化及IT运维工程师。文档从创建FTP用户开始，逐步讲解启用FTP功能与Web管理工具、通过IIS管理器添加FTP站点、选择内网IP地址与默认端口、设置SSL为无或允许、配置匿名访问与读写权限等详细步骤，并对“必须选中Web管理工具否则无法调用IIS管理器”这类关键点做出提醒，避免新手中途卡壳。内容还重点覆盖了TwinCAT FTP客户端的实际运用，包括上传功能块FB_FTP_FileUploadEx与下载功能块FB_FTP_FileDownload的调用方式、PLC程序中的变量声明与参数配置示例、需要引用的库文件清单以及FTP路径的相对性规则，并且给出了Win7自建FTP服务器传输超过30MB文件可能掉线的警告及应对思路。压缩包共1个文件，为DOCX格式，总大小439KB，内容组织紧凑、步骤清晰，适合边看边操作。目前已有193人学习下载，可作为刚接触TwinCAT或IIS FTP搭建者的速查手册。

1. 两台PC之间为什么还在用FTP：一个“老协议”的本地传输场景

很多办公室场景里，两台PC之间要传文件，既不想插U盘，又不方便用网盘——尤其在内网环境。FTP服务端/客户端一装，同一局域网内直接从A拖到B，千兆网线下传几个G的视频、几百个碎文件，比外网盘稳定得多。这篇文章把“两台PC间实现FTP通讯”这件事拆开：从网络准备、服务端选型，到端口放行和踩坑，目标是让你照着配置一遍就能用，不玄学。

2. 动手前的三张底牌：网络、软件与权限

2.1 先确认网络：IP、网段与物理链路

两台PC之间跑通FTP，前提是它们能互相访问。常见的物理连接有两种：要么两台PC都插在同一台交换机或同一个路由器上，要么一台PC用网线直接连另一台PC。无论哪种，都需要先确认IP地址在一个网段内。比如A机是192.168.1.10，B机是192.168.1.20，A机去访问B机就顺畅；如果一台是192.168.1.x，另一台是192.168.50.x，那就要看中间有没有路由，或者把其中一台改成同网段。

我一般会在服务端（准备装FTP服务的那台PC）上先跑一遍下面的命令，确认网络不是“黑匣子”：

ipconfig /all ping 192.168.1.20 -t arp -a | findstr 192.168.1.20

ipconfig /all用来确认本机IP、子网掩码和网关，重点看IP是不是和你打算给客户端访问的地址一致。ping -t持续ping对端，确认物理链路通。如果ping的通但ping延时忽高忽低，常见原因是网线质量差或交换机端口协商到了百兆，先换根线再说。arp -a是查ARP缓存，如果能看到对端MAC地址，说明二层通了，这时候还连不上FTP，问题多半在防火墙或服务本身。

还有一步容易忽略：把两台PC的电源计划都改成“从不睡眠”。FTP服务端一旦睡眠，客户端那边就会看到连接被重置，这问题我帮同事排查过很多次，最后发现是系统半小时后自动休眠了。屏幕可以关，系统休眠必须禁止。

2.2 服务端软件选型：Windows自带IIS FTP与FileZilla Server的取舍

FTP服务端的选择，常见的就是两个方向：Windows自带的IIS FTP功能，和第三方免费的FileZilla Server。如果对“少装软件”有执念，IIS够用；如果希望配置直观、权限清楚，FileZilla Server更省心。我两套都搭过，下面这组对比你可以直接拿去参考：

如果让我给一个结论：Windows上自己两台PC之间传文件，图省事用IIS FTP；图省心用FileZilla Server。后者最大的好处是当你把FTP账号给别人用时，不必暴露真实的Windows账号密码。我自己的习惯是长期用的服务一律用FileZilla Server，临时顶一下才开IIS。

2.3 权限模型：先想清楚“谁、能看哪个目录、能不能写”

FTP的权限设置容易踩坑，是因为“能不能访问”和“能不能写”是两件事。服务端软件里的权限勾选决定的是FTP层面的操作范围，而文件夹本身的NTFS权限又会在系统层面再做一道拦截。两层同时允许，才能正常读和写。

建议新建一个专用账号，而不是直接把Administrator给出去。在FileZilla Server里创建一个用户，挂载目录指向D盘的某个文件夹，比如D:\FTPServer，权限先只勾“读”和“写”，等确认一切正常再按需打开“删除”和“追加”。删除权限慎开，避免客户端误删文件找不回来。

匿名模式我在生产环境里从来不推荐。虽然“匿名访问”勾一下就免密了，但你会失去留存访问记录的依据，也容易被人顺手搞乱目录。两台PC之间传输，对方大概率是熟人，但该有的账号密码还是要有，这个习惯能帮你避免很多事后解释。

3. 搭一个能跑的服务端：从匿名开放到带密码控制

3.1 用Windows自带IIS建FTP站点的最小步骤

如果你选择IIS，第一步是启用功能。进入“控制面板→程序→启用或关闭Windows功能”，在“Internet Information Services”下勾选“FTP服务器”和“IIS管理控制台”，等待安装完成后重启一次IIS管理器。

新建FTP站点的路径是：打开IIS管理器，右键“网站”节点，选择“添加FTP站点”。给站点起个名字，物理路径选一个准备好放共享文件的目录，比如D:\FTPServer。接下来是绑定设置：IP地址填这台服务端的固定IP，端口保持默认的21，SSL选项选“无”。到了身份验证这一步，建议勾选“基本”，然后在“授权”里填写刚才准备的Windows账号，权限选“读取”和“写入”。

这里有一个非常关键的细节：IIS里的“基本身份验证”默认可能没有启用。你需要在站点主页找到“FTP认证”功能，确认“基本身份验证”状态是“已启用”。不然客户端登录时会一直报530，你会怀疑是密码打错了，其实是服务端压根没允许这种登录方式。

配置完成后，在服务端本地验证一下端口状态：

netstat -an | findstr :21

看到LISTENING说明FTP端口已经起来了。再用ftp 127.0.0.1本地登录一次，如果能正常进入，说明服务端自身没问题。注意IIS的FTP站点默认还会受“FTP防火墙支持”设置影响，这个问题放到第5章避坑里细说。

3.2 用FileZilla Server做精细控制：端口、用户与目录权限

FileZilla Server安装完成后，管理界面会要求你连接本机的管理服务，默认管理端口是14147，这个端口只服务于管理界面，不参与FTP数据传输，不用对客户端开放。FTP数据端口才是客户端要访问的21端口，或者你自定义的其它端口。

在FileZilla Server里添加用户的流程：打开“编辑→用户”，点击“添加”输入用户名，勾选“密码保护”并设置密码。然后进入“共享文件夹”页签，把D:\FTPServer添加进去，右侧权限勾选“读取”“写入”。这里比IIS更直观，勾了就能写，不勾就不能写，没有第二层NTFS权限来坑你。用户添加完，如果客户端连不上，回来看一下服务状态是不是“Online”。

服务端全局设置里有几个参数建议直接按下表配：

被动端口范围这个参数很多人不知道它的存在。客户端一旦使用被动模式，服务端就需要开放一段连续的端口供数据链路使用。如果这里留空，FileZilla Server会随机挑选系统端口，你在防火墙里根本没法精确放行，这就是很多“能登录但传不了文件”问题的真正根源。先把50000-50100这个范围设好，后面防火墙规则才有据可依。

3.3 防火墙放行：21号端口和高端口都要处理

Windows自带的防火墙默认会拦截外部对21端口的访问，同时也会拦被动模式下的高端口。这一步需要两条入站规则：一条针对TCP 21，一条针对TCP 50000-50100。如果你的服务端也启用FileZilla Server监听21端口，那防火墙规则里放行这两个范围就足够。

命令行的添加方式如下，管理员身份打开CMD：

netsh advfirewall firewall add rule name="FTP-21" 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

第一条放行控制端口，第二条放行被动数据端口。如果你改了服务端监听端口，比如改成2100，第一条命令里的localport=21也要同步改成2100。这两条规则是入站规则，只影响别人访问你，不影响你主动访问别人。

验证放行是否生效，可以回到客户端那台PC上（也可在同一台PC上验证），用telnet 192.168.1.10 21看到220开头的欢迎消息，说明控制通道已经通了。如果telnet不通，检查服务端服务是否在运行、防火墙规则是否创建成功。不要急着怀疑路由器或交换机，两台PC在同一个交换机下时，这些中间设备一般不会拦截内网流量。

4. 客户端连接与传输：图形界面和命令行两条路

4.1 资源管理器、FileZilla Client与命令行三种方式的连接参数

服务端准备好了，客户端这边有三条路可以走。第一条是直接在Windows资源管理器地址栏输入ftp://192.168.1.10并回车，系统会弹出登录框，填账号密码就能浏览文件。这种方式的优点是零安装，缺点是传输大量碎文件时速度不稳定，而且不太方便脚本化。

第二条是安装FileZilla Client。它在连接时让你显式填写主机、端口、用户和密码，右下角还可以切换主动/被动模式。遇到目录列表超时，界面上把“被动模式”勾上，多半能救回来。这个客户端也是排查问题时最有用的工具，因为它的日志窗口会直接显示服务器返回的响应码，比猜测强得多。

第三条是命令行ftp.exe，Windows自带。虽然界面老旧，但它能做的最重要的事情是脚本化。下面第4.2节就是讲怎么把它写成批处理，让定时同步成为可能。

连接参数的对应关系建议记成一句话：主机填服务端IP，端口填服务端监听的端口，用户填服务端创建的用户名，密码填对应用户的密码。不要拿Windows登录密码去猜FTP密码，除非你在IIS里明确使用了某个Windows账号。

4.2 用ftp.exe写一个可复用的批处理传输脚本

当文件需要反复从客户端上传到服务端，比如每天备份日志、同步配置文件，手动拖拽太浪费。常见的做法是写一个脚本文件，把ftp命令按顺序放进去，用-s参数让ftp.exe逐行执行。先准备upload.txt：

open 192.168.1.10 ftpuser ftppassword bin prompt off mput D:\backup\*.bak bye

open指定服务端IP；第二行和第三行分别是用户名和密码，按严格顺序放好，不可颠倒；bin切换为二进制模式，传图片、压缩包时不要漏了这一步，否则文件会因ASCII模式转换而损坏；prompt off关闭批量传输时的逐个确认，配合mput把整个D:\backup下的.bak文件一股脑传上去；bye结束会话。

然后写一个批处理来调用它：

@echo off ftp -i -n -s:D:\scripts\upload.txt echo Upload finished with exit code %errorlevel%

-i关闭交互式确认，-n禁止ftp.exe自动登录，关键作用是不让它在启动时尝试用当前Windows账号自动登录远端。-s:D:\scripts\upload.txt指定命令脚本路径。这样双击批处理就能完成一次上传。errorlevel可以用来在计划任务里判断上次传输是否成功。

这个脚本的局限在于FTP是明文传输，不适合用于办公网之外的真实服务器，但在一对一的两台内网PC之间，简单可靠就够每天跑了。

5. 两台PC联调避坑：5个最容易翻车的FTP故障现场

5.1 现象：连接报“530”，登录始终失败

现象：客户端用账号密码登录，刚输入完就弹出530错误，提示无法登录。检查密码绝对没错，甚至换了好几个账号都一样。

原因：多数情况下不是密码错，而是服务端身份验证配置不一致。IIS里勾了“匿名身份验证”但没启用“基本身份验证”，客户端明明是在输账号密码，服务端却等的是匿名。还有一种情况是FileZilla Server里用户已创建但未设置密码，而客户端填了密码。

解决：IIS用户到“FTP认证”里确认“基本身份验证”为“已启用”；FileZilla Server用户设置里确保密码保护勾选。我这个判断顺序已经形成习惯了：先看服务端身份验证方式，再看账号是否有效，最后才怀疑密码。

5.2 现象：能登录但“列目录超时”或一直转圈

现象：客户端可以登录，但刷新目录列表时卡住，最后超时，日志里能看到列表命令发送成功但等不到响应。

原因：主动/被动模式没对齐。客户端的主动模式要求服务端回连客户端的20端口，而客户端本机防火墙或所在网络未经允许会拦掉这个回调连接。两台PC都是默认Windows防火墙时，这种问题特别常见。

解决：把客户端改成被动模式。FileZilla Client在站点管理器中选择“被动”即可。服务端也要在FTP防火墙支持里设置被动端口范围。注意IIS的被动端口范围是在“FTP防火墙支持”功能里配置的，和FileZilla Server设置位置不同，别找错地方。

5.3 现象：小文件能传，大文件传到一半卡死

现象：传一个几KB的配置没问题，传几百MB的压缩包时进度条走到一半就停住，最后连接被重置。

原因：被动模式下防火墙只放行了21端口，没有放行数据端口。小文件传输时数据量少，可能在某个短连接里侥幸完成，但大文件持续占用数据连接，一旦服务端选择的新端口未被防火墙放行，立即断掉。如果偏巧你的服务端还没固定被动端口范围，这个问题更难复现，因为每次端口都不一样，很容易被误判为“玄学”。

解决：把服务端被动端口范围固定下来，比如FileZilla Server的50000-50100，然后在防火墙里放行这个段。IIS则在IIS管理器中的FTP防火墙支持页面设置数据端口范围。改完一定要重启FTP服务再测。

5.4 现象：中文文件名乱码

现象：客户端看到的文件名是乱码，或者上传中文名文件后，服务端保存的名字变成了问号。

原因：FTP协议早期没有规定字符集，老服务端默认ANSI编码，新客户端默认UTF-8，两边编码不一致就会出现乱码。Windows自带FTP客户端和IIS组合尤其容易触发。

解决：服务端开强制UTF-8。FileZilla Server在设置里勾选“强制使用UTF-8”；IIS需要在“FTP Unicode支持”里开启。如果服务端不给改，客户端侧在FileZilla Client里把字符集改为“强制UTF-8”或“自定义编码”临时绕一次。

5.5 现象：重启电脑后FTP服务消失了

现象：头一天还在传文件，第二天服务端重启后客户端连不上，服务也没了。

原因：两种常见情况。一是服务启动类型是手动，系统重启后服务没自动拉起；二是服务端绑定了固定的IP地址，但开机后IP变了（比如原本的静态IP被DHCP重新分配），服务在起，但监听地址不对。

解决：将FTP服务设为“自动”启动。FileZilla Server在Windows服务管理器里找到“FileZilla Server”，把启动类型改为“自动”。IIS服务对应的“Microsoft FTP Service”同样设为自动。IP方面，给服务端设置一个固定的内网IP，避免DHCP变动把配置打乱。这属于一次配好、一劳永逸的工程，不建议偷懒。

6. 收尾：把FTP链路从“能传”做到“不折腾”

服务端跑通、客户端能连之后，很多人的项目就到此为止了。但真正用得顺的人，往往会把最后的“手动传文件”升级成“定时同步+校验结果”。我习惯把上一章那个批处理脚本挂到Windows任务计划里，每天凌晨自动把客户端指定目录的备份文件推送到服务端。计划任务的触发条件选“每日”，执行操作填D:\scripts\ftp_sync.bat，运行用户改成有权限的账号即可。

传输完要判断有没有丢数据，最直接的方法是对比MD5。Windows自带certutil -hashfile命令，可在服务端和客户端分别对同一个文件计算哈希值后比对。脚本化校验的做法是在批处理里外加一段：

certutil -hashfile D:\backup\test.bak MD5

把结果输出到日志文件，第二天抽查日志确认哈希一致。FTP本身不带完整性校验，这一步能补上它的短板，尤其在传输压缩包或数据库备份文件时，丢失一个字节都麻烦。

如果之后的数据从“内部互传”变成需要跨越更大范围的传输，或者有更敏感的合规要求，可以考虑把方案升级为FTPS或SFTP。前者是FTP加了隐式加密，后者走SSH通道，两者都能解决FTP明文传输的暴露问题。但在两台PC本身处于可靠内网、且目标只是快速传文件的场景里，标准的FTP并没有过时，它是把“文件从A到B”这件事做到最简单的方式之一。

我给同事搭这类链路时吃过亏：一台机器用的FileZilla，一台用的IIS，两边被动端口范围都设了不同段，最后对不上，排查了一整天才发现是端口段不一致。后来我养成了一个习惯——把服务端IP、端口、账号、被动端口范围、防火墙规则名称写进一张本地方档，命名就叫“FTP参数卡”，每次配完立刻归档。这点参数看起来不起眼，但下次需要重建或迁移时，它能帮你省下至少半小时，希望帮到你。

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