企业官网建设流程全解析

很多刚接触Linux的朋友都会遇到一个问题：Ubuntu里的文件和Windows之间的传输，到底怎么搞才最顺手？U盘拷贝太麻烦，网盘上传下载绕一圈又担心隐私和速度。这一期我直接讲一个在Ubuntu 20.04环境下最省心的方案：利用FileZilla作为SFTP客户端，配合Windows 11实现文件互传。这套方法不光解决“传文件”这个动作，更关键的是帮你建立一条安全、稳定、随时可用的传输通道。

这套组合的优势在于：FileZilla本身是开源且跨平台的图形化工具，对新手极其友好，不需要记一堆scp命令参数；而SFTP协议基于SSH加密传输，敏感数据不容易在局域网中被截获。无论你是学生做课程设计，还是开发者维护云服务器，甚至只是想在虚拟机里拷贝一份配置文档，这套流程都适用。

1. 工具与协议选型：为什么是FileZilla而不是U盘或命令行

1.1 文件互传的常见方案对比

在开始实操之前，我觉得有必要把方案比较讲清楚，这样你能理解为什么我在这么多工具里挑了FileZilla。我们自己常用的大概有三类：

第一类是U盘、移动硬盘等物理介质。简单粗暴，但频繁插拔设备既伤接口，而且文件一多，来回拷非常浪费时间。最关键的是，两台设备不在同一物理位置时，这个方案直接失效。

第二类是网盘和社交软件传输。胜在跨平台，但绕不开“上传再下载”的中间步骤，大文件要等半天，小文件又觉得没必要。如果涉及代码、配置文件这类内容，网盘还会因为同步逻辑产生版本混乱。

第三类则是网络协议传输，比如Samba共享、FTP、SFTP等。其中SFTP（SSH File Transfer Protocol）是我个人最推荐的：它走的是SSH通道，系统自带加密，不需要额外开放不安全的端口或搭建复杂服务器，Ubuntu装一个OpenSSH Server就能用，Windows端配一个FileZilla就能连。整个过程不经过任何中间服务器，纯粹的点对点，速度上限取决于局域网带宽。

1.2 SFTP协议到底解决了什么问题

很多人分不清FTP和SFTP的区别。一句话说清：FTP是明文传输，密码和文件内容都可以被局域网内的抓包工具直接看到；SFTP则是把整个传输会话封装在SSH加密隧道里，传输过程中即使有人抓包，看到的也是一堆无法还原的密文。

另外，SFTP本身就是OpenSSH套件自带的子系统，Ubuntu 20.04装好openssh-server之后，服务端和传输能力同时就绪，不用额外去安装ftpd、vsftpd这类程序，也不需要配置FTP的主动/被动模式，一个22端口走天下。Windows 11上装FileZilla只是作为客户端，本质跟你在终端里敲scp命令没区别，只是图形化之后，文件和目录结构一目了然，拖拽操作也更顺手。

提示：为什么不直接用Windows自带的远程桌面拷贝？因为Windows远程桌面需要专业版授权且有会话限制，而SFTP方案没有任何会话数限制，也不依赖图形界面，在服务器场景下更通用。

2. Ubuntu 20.04端基础准备：安装并配置SSH服务

2.1 安装OpenSSH Server

这一步是整个互传链路的地基。Ubuntu 20.04桌面版默认没有安装OpenSSH Server，只带了客户端。我们需要手动补上服务端，让Windows那一端能连进来。

打开终端（快捷键Ctrl+Alt+T），先更新软件源索引：

sudo apt update

然后安装服务端：

sudo apt install -y openssh-server

安装完成后，可以查看SSH服务的运行状态：

sudo systemctl status ssh

如果看到状态栏是Active: active (running) 就说明服务已经在跑了。如果没跑起来，执行：

sudo systemctl start ssh sudo systemctl enable ssh

第二句enable是设置开机自启，这样每次重启Ubuntu，不需要手动再点开服务，Windows那头随时能连进来。这一步我非常建议顺手做掉，不然哪天突然要拷文件发现连不上，又得跑过去开终端，特别浪费时间。

2.2 确认IP地址与防火墙规则

服务起来之后，Windows要连的是Ubuntu的IP。我们查看一下本机IP：

ip addr show

通常找ens33或者eth0这块网卡下面的inet值，形如192.168.x.x的就是内网IP。记下这个地址，等会儿FileZilla要用。

接下来是防火墙。Ubuntu 20.04桌面版的ufw默认是不启用的，如果你自己之前打开过，需要放行22端口：

sudo ufw allow 22/tcp sudo ufw enable sudo ufw status

如果ufw本身就是inactive状态，这一步可以省略，但既然要长期做文件互传，我建议还是开个防火墙并且放行特定端口，这样安全边界更清晰，也不会每次开机弹一堆安全提示。

注意：不要为了图省事直接禁用防火墙，更不要用NFS、Telnet这类明文协议替代SFTP。安全习惯这种东西，一开始就正规，后面才省心。

2.3 创建专用传输账号还是直接用当前账号

如果你是单用户使用，直接用当前Ubuntu账号登录就行。但如果你有强迫症，希望把传输权限跟平时使用的账户隔离，可以创建一个专门的sftp用户：

sudo useradd -m sftpuser sudo passwd sftpuser

创建完之后，在sshd_config里限制该用户只能使用SFTP且只能访问自己的家目录：

sudo nano /etc/ssh/sshd_config

在文件末尾加上：

Match User sftpuser ChrootDirectory /home/sftpuser ForceCommand internal-sftp PermitTunnel no AllowAgentForwarding no

改完保存，重启SSH服务：

sudo systemctl restart ssh

这样即便账号密码泄露，攻击者也只能在这个用户的家目录里转悠，做不了更多操作。不过日常生活中，家庭局域网内直接用原名账号连接问题也不大，看你对安全边界的阈值设在哪里。

在完成第2步之后，Ubuntu端已经是一个具备加密传输能力的服务端状态。接下来重点转向Windows 11这一侧，这才是大多数人第一次上手FileZilla时最容易犯迷糊的地方。

3. Windows 11端FileZilla安装与界面拆解

3.1 下载、安装与版本选择

FileZilla官方提供Windows版本，为了不引入额外的安全风险，我们只从官方站点获取安装包。安装过程没什么玄学，一路Next就行，唯一可以留意的是安装路径，我会习惯装到非系统盘，比如D盘，避免系统重装后软件环境重新折腾一遍。

版本选择方面，日常互传用FileZilla Client即可，不需要Server包。Server是给Windows做FTP服务端用的，跟我们的方向是反的——我们现在是让Windows去连Ubuntu，不是让Ubuntu来连Windows。

安装完成后，第一次打开会看到一个警告横幅提示你“不要使用FTP协议传输敏感信息，请使用SFTP”，这是FileZilla的官方安全提醒，不用觉得奇怪。很多人第一次看到这个黄条会以为软件出问题了，其实是在告诉你：连接类型请选SFTP，而不是FTP。

3.2 FileZilla主界面各区域作用

FileZilla的界面乍一看信息量不小，实际上核心区域就五个：

顶部是“快速连接”栏，左边文本框依次输入主机（IP）、用户名、密码、端口，然后点击“快速连接”按钮。这个快速连接适合临时用一次的场景，缺点是不会保存密码，下次连接还得重新输入。中间区域是菜单栏下面的一排工具栏，包含“站点管理器”“刷新”“断开连接”等按钮。再往下分成上下两大块：上面是消息日志，所有连接过程、指令反馈都会实时滚动显示；下面则是左右并排的文件列表区域。

左侧“本地站点”显示Windows 11当前磁盘和目录，右侧“远程站点”则显示Ubuntu上的文件系统。互传的本质，就是在这两个区域之间拖拽文件。我建议从一开始就强迫自己看底部那个“传输队列”面板，它能显示文件传输的进度、速度和剩余时间，大文件传输时盯着这个面板远比盯日志靠谱。

3.3 站点管理器的正确配置方法

长期使用FileZilla的正确姿势是配置“站点管理器”，而不是每次都用快速连接。按Ctrl+S打开站点管理器，点击“新站点”，给这个配置起一个你认识的别名，比如“我的Ubuntu 20.04”。

然后在右侧填写关键参数：

• 主机：输入Ubuntu的IP地址，比如192.168.31.110
• 端口：输入22
• 协议：必须选择“SFTP - SSH File Transfer Protocol”
• 登录类型：选择“询问密码”或“普通”
• 用户：你的Ubuntu登录名

这里提醒一下，协议选错是新手最容易犯的错误。如果默认选的是“FTP - File Transfer Protocol”，连接大概率会报错或者直接拒绝，因为FTP走的是21端口，而我们的Ubuntu上压根没开FTP服务，开的是SSH的22端口。只有选SFTP才能正确握手。

配置好之后，建议点击界面下方的“连接”按钮测试一下。连接成功后，左侧选Windows的某个空目录，右侧进入Ubuntu的某个目录，比如家目录，接下来就可以开始愉快的文件拖拽了。

3.4 首次连接的安全确认

第一次通过SFTP连接Ubuntu服务器时，FileZilla弹窗显示一个未知主机密钥确认框，内容是“该服务器尚不为人知。无法验证该证书”。这其实是SSH协议的正常机制，目的是防止中间人攻击。Linux的OpenSSH服务端每次启动都会生成唯一的host key，客户端第一次连接时需要确认并信任这个key。

我们只需要勾选“总是信任该主机，并将其密钥加入缓存”，点击“确定”即可。只要Ubuntu系统没有重装或SSH配置重置，后续再连就不会出现这个弹窗。这里我要多说一句：这个弹窗是安全机制，不是故障提示，如果哪一天它又出现了，并且提示的密钥指纹和以前不一样，那就要警惕了，可能是有人冒充服务器或者SSH配置被改过。

4. 建立连接与文件互传实操过程

4.1 三步建立SFTP连接

配置好站点管理器之后，日常连接只需要三步。

第一步，打开FileZilla，点击工具栏最左边的“小图标下拉箭头”，选择之前配置好的“我的Ubuntu 20.04”。

第二步，如果需要输入密码，弹出框里输入Ubuntu用户的密码。

第三步，观察消息日志区域，出现类似“230 Login successful”和“Directory listing successful”的提示，说明连接成功，右边窗口会列出Ubuntu主目录下的文件和文件夹。

连接成功之后，目录列表默认按名称排序。如果你要找最近上传的文件，可以点击远程站点的“修改时间”列头，让文件按照时间从新到旧排序，这样一眼就能看到刚传过去的文件有没有到位。这个小技巧在实际操作中特别管用，尤其文件多了以后。

4.2 上传与下载的多种操作方式

文件互传核心操作就是下载（远程上传到本地）和上传（本地上传到远程）。在FileZilla里，实现方式无非这两种：

方式一是直接拖拽。在左侧本地站点选中一个或多个文件，按住鼠标左键拖到右侧远程目录，松开后就会自动开始上传。从右侧拖回左侧就是下载。这个操作直观，但新手偶尔会把文件拖进左边的某个多级子目录，然后又找不到上传到服务器哪里去了。我建议拖拽前先确认左右两侧顶部路径栏显示的是不是你要的目录。

方式二是右键菜单。选中文件后右键，有一个“上传”选项。在远程站点同理，右键文件可“下载”。这种操作方式更精准，不会出现拖错位置的问题。批量传输时，还可以配合Ctrl多选或者Ctrl+A全选。

传送开始后，底部“传输队列”页面会逐条显示文件状态，绿色对勾表示已完成，蓝色箭头表示正在传输。转录过程中尽量不要随便中断连接，如果确实需要停，等待队列处理完再断开，避免产生半截文件。

4.3 传输过程中的权限和路径问题

文件传到Ubuntu之后，默认权限取决于创建时的umask。常见的情况是，你从Windows传上去的压缩包，在Ubuntu终端里解压时提示权限不够，或者反过来在Windows上看到Ubuntu侧某些文件图标带锁，无法打开。

如果只是个人使用，最简单的解决办法是：连接FileZilla时直接使用Ubuntu当前用户账号，不要用root。这样你传到Ubuntu家目录下的文件，当前用户都有完整权限。如果非要传一些系统级目录，比如/opt或/usr/local，FileZilla登录为普通用户是没权限写入的，这时候可以临时用sudo调整目录属主，或者把目标文件先传到主目录再通过终端sudo移动，而不是真去用root登录FileZilla。

经验之谈：我见过不少人图省事，直接把OpenSSH的PermitRootLogin改成yes，用root账户连接FileZilla。这在暴露于公网的服务器上是巨大风险。哪怕在局域网里，也强烈不建议。权限不够就多走两步，安全账不能算得太糊涂。

4.4 大文件传输的稳定性与断点续传

大文件传输是文件互传场景里的硬骨头。FileZilla的SFTP协议本身支持断点续传，但前提是传输中断后，你重新开始任务时FileZilla能检测到目标位置已有部分文件，并提出三种选择：覆盖、续传、跳过。此时如果你选了“续传”，就能接着上次的进度继续。

不过更靠谱的兜底办法是：重大传输开始前，把Windows端“设置”里的“确认文件存在”改为“继续传输”，这样在中断重新连接后，默认动作就是续传而不是弹出对话框傻等。

另外，如果传的是很多小文件，比如几万个碎图或代码文件，SFTP的逐个传输效率会比较低。我测试过，一个包含五万个小文件的目录，用FileZilla默认传输方式，耗时和直接打包压缩传一个包再解压，差距有两三倍。所以传大量小文件前，先在Windows端用压缩工具打成zip包，几MB的压缩包秒传，到Ubuntu里用unzip解压几分钟就搞定。很多人做代码项目同步时会遇到文件数量对不上的问题，很多时候就是没有用打包的方式。

4.5 断连与重连的日常维护

连接时间长了，可能出现“断开连接，重试中”的日志提示，这往往是因为长时间无操作，SSH会话被服务端保活踢掉了。解决办法不复杂，在FileZilla菜单栏选择“编辑—设置—连接”，找到“发送保持活动状态的FTP保持连接数据包”，勾选并设置间隔为50秒。这个配置会让客户端每隔一段时间发送一个保活包，让服务端认为连接仍处于活跃状态，从而降低被踢掉线的概率。

如果网络本身不稳定，比如Wi-Fi信号波动导致断连，FileZilla日志里会看到连接重置的报错。这种情况唯一的办法是调整网络环境或者改用网线连接。别指望软件层面完全解决物理链路的问题。

5. 进阶用法：密钥登录与一行命令传输

5.1 配置SSH密钥实现免密登录

如果你每天要反复跟Ubuntu互传文件，每次都输密码会有点烦。更优雅的方案是配置SSH密钥认证，让FileZilla连接时自动完成身份验证，不需要手动输入密码。

密钥认证的原理我没有办法讲得更简化但准确：Windows端生成一对“公钥+私钥”，公钥放到Ubuntu的authorized_keys文件里，私钥留在Windows本地。每次连接时，Ubuntu用公钥验证私钥签名的信息，验证通过就放行。

实际操作步骤如下：

在Windows 11的命令提示符或PowerShell中执行：

ssh-keygen -t ed25519 -C "filezilla-key"

一路回车即可生成默认路径下的密钥文件（一般在用户目录下的.ssh文件夹里）。生成的私钥文件名为id_ed25519，公钥文件名为id_ed25519.pub。

然后把公钥安装到Ubuntu上，最简单的办法是直接用FileZilla，把本地的id_ed25519.pub文件上传到Ubuntu主目录的.ssh目录下，然后在终端里执行：

mkdir -p ~/.ssh chmod 700 ~/.ssh cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys sudo systemctl restart ssh

之后在FileZilla站点管理器里，登录类型改为“使用密钥文件”，并选择Windows端私钥文件id_ed25519。再连接时，整个过程不用输密码，直达Ubuntu目录。如果连接时提示私钥文件权限过宽被拒绝，需要在Windows端给私钥文件设置更严格的访问权限，右键属性—安全—删除Everyone用户的读取权限。

这几年我实测下来，ed25519算法在性能上比传统的RSA快不少，而且密钥长度更短，OpenSSH 8.x天然支持，Ubuntu 20.04自带的OpenSSH版本完全没问题。你还在用RSA 2048也仍然可行，只是新配置我建议直接用ed25519，少走弯路。

注意：私钥文件就是你的“虚拟身份”，谁拿到它，谁就能在没有密码的情况下登录你的Ubuntu。妥善保管私钥文件，不要放在U盘里到处带着走，也不要在微信里发送给别人。

5.2 不依赖图形界面的命令行互传方式

FileZilla是图形化工具中的优等生，但如果你已经体会到命令行的简洁效率，这里顺带补一个scp命令的用法。在Windows PowerShell里执行：

scp localfile.txt user@192.168.x.x:/home/user/

把本地文件推送到Ubuntu，反向传回则是：

scp user@192.168.x.x:/home/user/remotefile.txt .

scp本身走的同样是SSH通道，和FileZilla的SFTP是同一种加密隧道。当你想快速拖一个文件又不方便打开界面时，一行命令比你点鼠标来得快得多。我建议对于稍大型的目录，用带-r参数的scp递归拷贝：

scp -r folder1 user@192.168.x.x:/home/user/folder1

这条命令会把整个目录连同内部结构全部传过去。平时用图形化工具管理，批量或自动化操作时用命令行，这才是老手该有的搭配意识。

5.3 不同网段下的连接与穿透问题

有时候我们不只是同一台路由器下两台机器互传，还可能遇到Ubuntu在有线网络，Windows在无线网络，甚至跨网段的情况。FileZilla连接的前提是两台设备路由可达。如果你在Windows端用ping测一下Ubuntu的IP，能通就能连，如果ping不通，请检查两端是否处于同一子网。

跨网段的场景，比如Ubuntu接在路由器A后面，Windows接在路由器B后面，两个路由器又互联，这种情况就得在路由器上配置静态路由，让数据包能找到来回的路径。这个场景涉及网络规划，对于大多数家庭用户来说不常见，知道有这个知识点即可。如果传输目标是公网上的云服务器，那就直接用服务器的公网IP，协议依然是SFTP，FileZilla这边不用改任何逻辑。

6. 常见报错与排查经验

6.1 连接被拒绝：ECONNREFUSED

错误信息一般是“Could not connect to server: ECONNREFUSED”。这个报错说明Windows端发出的连接请求，在目标IP的22端口被人拒了，也就是说Ubuntu的SSH服务可能没跑起来。

排查步骤：

• 在Ubuntu终端执行 sudo systemctl status ssh
• 如果SSH服务是死的，执行 sudo systemctl start ssh
• 再执行 sudo systemctl enable ssh 设置开机自启

如果服务状态已经是active但仍无法连接，检查一下22号端口是否真的在监听：

sudo ss -tlnp | grep 22

如果输出结果里看不到LISTEN状态的22端口，可能是配置文件错误导致sshd没有正确加载。用sudo sshd -t检查一下配置文件的语法是否正确。经验看下来，十次里九次都是忘记启动服务或者之前手动改了sshd_config把端口改停了。

6.2 密码正确却登录失败

这又是一个常见的坑。密码输入正确，但日志里提示“Access denied”。先说一个最容易忽略的问题：Windows 11的键盘输入法如果还开着中文状态，输密码时会出现半角全角混乱的现象，尤其是密码里包含字母和数字时，看着正确其实并不是。换上英文输入法再试一次，大概能解决三分之一的案例。

排除了输入法，再检查密码是否包含特殊字符，比如$、!、&等。这涉及到密码解析机制：在快速连接里手输密码，如果密码包含特殊字符，建议改到站点管理器的“常规”登录类型里填，避免客户端在解析URL逻辑时把特殊字符当作参数分隔符处理。更稳妥的方案是用密钥登录，彻底绕开密码解析问题。

6.3 目录列表加载失败

连接成功了，但右侧远程目录一直转圈，最后提示“Failed to retrieve directory listing”。这种情况通常跟权限有关系，也可能与会话环境有关。如果你在sshd_config里做了ChrootDirectory限制，必须清楚该目录的属主要设置为root，且其他用户不能写，否则SFTP会话无法chroot进入根目录，干脆登录后就无法列出目录。

还有一种可能是OpenSSH的sftp子系统配置被误导。检查sshd_config里是否有一行：

Subsystem sftp internal-sftp

如果这行被注释掉了或者指向了错误的路径，SFTP登录后就没法正常工作。保存配置后重启sshd再试。

6.4 传输中断或中断后文件损坏

传输大文件时突然网络断开，或者电脑休眠导致连接中断，剩下的问题就是怎么保证传过去的文件还能用。如果是压缩包或视频这类整体文件，中断后完整度大概率不行，重新传一次。如果你在传文件之前，双方系统时间不同步，也可能导致SFTP校验异常，传输中断后重新续传还会出现文件名冲突问题。建议无论如何，传输完大型文件后，在Ubuntu端用md5sum命令校验一下文件指纹：

md5sum 文件名

Windows端可以用PowerShell的Get-FileHash命令：

Get-FileHash .\文件名 -Algorithm MD5

两边结果一致就说明传输过程没有数据损坏。这个校验动作，比依赖任何传输工具的可靠性承诺都要扎实。

6.5 远程站点文件列表中文乱码

Ubuntu的文件名如果是中文，Windows端FileZilla默认编码是UTF-8，正常情况下可以正常显示。如果出现乱码，在站点管理器的“字符集”标签页中，把编码从“自动检测”改成“强制UTF-8”。如果是连接老式的FTP服务器，可能需要选择“自定义”并填入cp936或gbk。SFTP连接基本不会遇到乱码，因为UTF-8就是默认字符集，前提是两端系统语言环境正常。

7. 我的一点实操心得

这套方案从配置完成到现在，我大概稳定用了一年半，传输总量超过200GB，包括虚拟机镜像、项目代码、视频素材。中间踩过的坑主要有三个，在这里分享出来，希望你能避开。

第一个是有关开始配置时的系统用户权限。当时为了图方便，直接把Windows下的用户目录整个拖到了Ubuntu家目录下，结果传了两万多个小文件，传输耗时极长，客户端界面卡到几乎无法操作。后来我把大目录先在Windows端压缩成zip，传过去再解压，时间从40分钟锐减到5分钟。这个差距在小文件密集型场景下非常惊人。

第二个是虚拟机环境下的网络模式选择。如果Ubuntu安装在虚拟机上，务必把虚拟机的网络模式设置为“桥接模式”，而不是NAT模式。NAT模式下Ubuntu虽然能上外网，但虚拟机对局域网其他设备是不可见的，Windows用FileZilla无论如何都连不上它。这个坑在VMware和VirtualBox里都很常见。

第三个是文件权限问题。从Windows传过去的文件，默认权限一般是644，如果目标目录需要被Web服务或其他服务写入，就需要在Ubuntu终端里chmod一下。与其传完再改权限，不如在Windows端就把需要长期共享的目录规划好，然后直接把整个目录共享给同一个组，省掉后续反复调整的麻烦。

FileZilla配上SFTP这套组合，属于那种“配置一次，长期受益”的工具链。每次打开它连接Ubuntu，那种即时可见的目录列表和拖拽操作，确实比命令行直观很多。而且这个路径后续还可以扩展，比如通过第三方工具把FileZilla的站点配置同步到其他电脑上，或者结合任务计划在Windows上定时执行批量传输。文件互传的核心不在于工具多炫，而在于稳定可靠、随时能用。用这套方案，遇到再急的拷贝需求我都不慌，打开FileZilla拖两下就完事，这就是工具顺手带来的底气。