前几天我需要把测试服务器上的一批安装包交给同事。

文件都在 /srv/release，对方却没有服务器账号。临时开 SSH、讲一遍 scp，对非技术同事不太友好；传网盘又要先上传一遍，几十 GB 的文件等于在网络上绕一圈；为了这一次需求装一整套私有云盘，我自己都觉得重。

这类事情最别扭的地方，不是文件不存在，而是目录已经在服务器上，却缺一个人人都会用的入口。

CHFS（CuteHttpFileServer）正好解决这个小问题：下载对应平台的程序，指定一个目录和端口，它就把这个目录变成一个可以用浏览器访问的文件管理页面。Windows、Linux 和 macOS 都有对应版本，核心功能也不依赖数据库、Java 或 Node.js。

不过，“一个文件就能运行”只说明启动成本低，不代表把端口暴露到公网也可以不做设计。真正值得聊的，恰恰是它简单到什么程度，以及简单之后还要补上哪些边界。

一、CHFS 做的不是“再存一份”，而是给原目录开一扇门

很多网盘类产品会建立自己的数据目录、索引和元数据。CHFS 的思路更直接：它读取指定的文件系统目录，通过 HTTP 页面展示文件，并提供下载、上传、创建、重命名、删除等操作。客户端不需要安装专用软件，打开浏览器即可。

这意味着两件事。

第一，文件不需要先导入 CHFS。服务器上原本就有的目录，可以直接成为共享目录；你通过 SSH 放进去的新文件，浏览器刷新后就能看到。

第二，CHFS 不是新的存储层。文件仍然受操作系统权限、磁盘容量和备份策略约束。网页里删掉一个文件，本质上还是在操作服务器磁盘，而不是删掉一个无关紧要的“网页副本”。

官方页面还写明支持 WebDAV，地址是 http://主机:端口/webdav。如果你习惯把远程目录挂到文件管理器里，WebDAV 会比一直开着网页顺手。不过它与网页入口共用同一套访问规则，权限不能分开想当然。

我会把 CHFS 看成一个很薄的文件访问层：部署轻、学习成本低，适合把已有目录快速交付出去；它并不负责版本管理、多人协作审批或异地备份。

二、先跑起来：两条命令就能看到页面

截至本文整理时，CHFS 官方页面提供的是 3.1 版本，包含 Windows、Linux、macOS 以及多种 CPU 架构的下载包。

Windows 解压后，可以在 PowerShell 里运行：

.\chfs.exe -path"D:\Share"-port8080

Linux 上给程序执行权限，再指定目录：

chmod +x ./chfs
 
./chfs -path "/srv/share" -port 8080

随后在同一网络的电脑或手机上打开：

http://服务器IP:8080

如果服务器地址是 192.168.1.20，实际地址就是 http://192.168.1.20:8080。看不到页面时，先检查 CHFS 进程是否仍在运行，再检查系统防火墙或云安全组是否放行了这个端口。

CHFS 3.1 支持一次指定多个共享目录，用 | 分隔：

./chfs -path "/srv/release|/srv/inbox" -port 8080

路径带空格时要把整个参数值放在引号里。Windows 直接双击也能启动，但默认共享程序所在目录、监听 80 端口，真正使用时不够明确。我更习惯把目录与端口写出来，免得“运行成功了，却分享错了地方”。

这里还有一个版本差异值得提醒：网上不少旧教程使用 --rule、--allow 等命令行参数。3.1 官方帮助里只列出 -file、-path、-port 和 -version。账号、地址过滤、HTTPS 等设置应写进配置文件。复制旧命令前，先以自己下载版本的 -h 或官方模板为准。

三、临时试用靠命令，长期运行靠配置文件

只在局域网临时传一次文件，前面的命令够用了。准备长期使用时，我建议下载官方的 chfs.ini 模板，把端口、目录、日志和账号都放进去：

port=8080
path=/srv/chfs/share
log=/var/log/chfs
file.remove=2 
 
[guest]
rule.default= 
 
[reader]
password=请替换为随机长密码
rule.default=r 
 
[operator]
password=请替换为另一组随机长密码
rule.default=r
rule.d=/srv/chfs/share/inbox

然后用配置文件启动：

./chfs -file /etc/chfs/chfs.ini

这个示例表达的是一种思路，不是让大家原样复制到生产环境：

• guest

   默认不给权限，避免匿名访问；

• reader

   只读，适合下载资料；

• operator

   默认只读，但对 inbox 目录给最高权限；

• log

   指定操作日志目录，方便事后核对；

• file.remove=2

   使用 CHFS 自己的回收站，官方说明其中超过一个月的文件会被清理。

3.1 的权限字母里，r 表示读，w 表示写，d 表示最高权限，另外还能用 rule.none 屏蔽指定目录。对子目录单独配置的规则会覆盖默认权限。由于官方模板特别提醒了“目录本身”和“目录内文件”的差别，上线前最好真的用测试账号把下载、上传、重命名、删除逐项点一遍，不要只看配置觉得理所当然。

还有一个容易忽略的事实：密码就写在配置文件里。Linux 上至少应把配置文件收紧为仅服务账号可读，例如：

sudochown chfs:chfs /etc/chfs/chfs.ini 
sudochmod 600 /etc/chfs/chfs.ini

CHFS 里的账号规则并不能突破操作系统权限。反过来说，如果 CHFS 进程用 root 或管理员身份运行，误配置时能碰到的文件也更多。比较稳妥的做法是创建一个专用系统账号，只给它共享目录所需的读写权限。

四、要让它一直运行，还得交给系统托管

终端一关，前台进程就停了。长期使用时，不要靠一个永远不关的 SSH 窗口维持服务。

Windows 可以按官方说明用 NSSM 把 chfs.exe 包装成系统服务。安装时把程序路径指向固定位置，参数写成 -file D:\chfs\chfs.ini，再设置开机启动。也可以用任务计划程序，但无论哪种方式，都要确认它使用哪个 Windows 账号运行，以及这个账号到底能访问哪些目录。

Linux 上可以交给 systemd。下面是一份我会拿来起步的服务文件：

[Unit]
Description=CuteHttpFileServer
After=network-online.target 
 
[Service]
Type=simple
User=chfs
Group=chfs
ExecStart=/opt/chfs/chfs -file /etc/chfs/chfs.ini
Restart=on-failure
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ReadWritePaths=/srv/chfs/share /var/log/chfs 
 
[Install]
WantedBy=multi-user.target

这里刻意没有让它使用 root，也没有让整个文件系统都可写。ReadWritePaths 只放真实需要写入的共享目录和日志目录。如果你的 CHFS 只提供下载，还可以进一步把共享目录设成只读。

服务启动后，至少检查三件事：进程是否由预期账号运行、重启机器后是否自动恢复、日志目录是否真的产生记录。能开机自启不等于能稳定维护，失败后有没有线索同样重要。

五、局域网很好用，直接暴露公网要慢一步

CHFS 的便利来自“浏览器能直接操作服务器文件”。这也是它最大的风险来源。

如果只是家庭局域网、办公室内网，或者已经通过 Tailscale、WireGuard、企业 VPN 进入可信网络，我会优先让 CHFS 只在这层网络里可达。这样既保留浏览器访问的便利，也不用把文件管理入口直接交给互联网扫描器。

如果确实需要公网访问，我至少会补上下面几层：

1. 缩小暴露面。

    防火墙只放行必要来源，能通过 VPN 访问就不开放公共端口。

2. 关闭访客权限。

    每个人使用独立账号和随机长密码，不共用一个 admin/admin。

3. 在入口处理 HTTPS。

    CHFS 配置支持 ssl.cert 和 ssl.key，但证书续期、旧协议禁用、限速和访问日志通常由 Caddy、Nginx 等成熟反向代理统一处理更省心。

4. 只共享专用目录。

    不要把 /、C:\、用户主目录或应用配置目录直接作为根目录。

5. 限制写和删。

    能只读就不给写，能上传就未必需要删除；权限应围绕任务发放，而不是围绕“以后可能用到”。

6. 保留真正的备份。

    回收站只能降低误删概率，不能代替离线或异地备份。勒索、磁盘损坏和账号泄漏都不会尊重回收站。

官方文档写明内置 HTTPS 最低支持 TLS 1.0。我的理解是，这说明它提供加密能力，但不能据此把它等同于一套完整的公网安全网关。对外服务时，我更愿意在反向代理上只启用现代 TLS 协议，并把证书续期、访问限制和异常流量处理集中在入口。

另外，上传功能不仅是“多一个按钮”。磁盘写满、超大文件占满带宽、同名文件覆盖、恶意文件落盘，都需要提前考虑。用于收件的目录最好和系统、备份、媒体库分开，并设置容量监控。

六、哪些场景我会选 CHFS，哪些不会

我会在这些场景里优先想到 CHFS：

• 临时把服务器上的构建产物、日志包或资料交给别人下载；

• 家里 NAS 或小主机上，需要一个比命令行友好的局域网入口；

• 测试环境里快速搭一个上传、下载目录；

• 需要通过 WebDAV 访问一小批文件，又不想维护完整网盘系统；

• 老设备或资源有限的机器上，希望部署尽量轻。

但遇到下面这些要求，我会换工具：

• 需要文档在线编辑、分享链接到期、审批流和团队空间；

• 需要细粒度审计、单点登录、多因素认证或多租户隔离；

• 需要文件历史版本、跨地域复制、对象存储兼容接口；

• 要承受大量公开下载，或者对可用性有明确 SLA；

• 把它当成备份系统，期望误删、硬盘损坏后还能恢复。

CHFS 官方称它为免费软件，但免费不等于开源。官方页面提供的是各平台二进制包和配置模板，没有给出 CHFS 本体的源代码仓库或开源许可证。GitHub 上能找到的 chfsgui 是 Windows 图形界面包装器，不是 CHFS 服务端源码。对个人和临时场景这未必是问题；对有供应链审计、二次开发或合规要求的团队，就应该把它列入选型条件。

七、我自己的上线检查表

如果明天要把一个目录交给同事访问，我会按这个顺序做：

1. 单独创建共享目录，不直接分享现有业务目录；

2. 用专用系统账号运行 CHFS，先收紧操作系统权限；

3. 在 chfs.ini 里关闭访客权限，为下载和操作人员分账号；

4. 只开放确实需要的读、写、删能力；

5. 优先放在局域网或 VPN 内，公网场景增加反向代理与 HTTPS；

6. 开启日志，模拟一次上传、覆盖、删除和重启；

7. 确认重要文件另有备份，并设置磁盘容量告警。

这些步骤做完，CHFS 仍然是一个很轻的工具。轻量不等于草率，它只是把复杂度从“安装一大堆组件”变成了“认真划清一个目录的边界”。

写在最后

CHFS 最吸引我的地方，不是功能有多少，而是它把一件很具体的事做短了：一个已经存在的服务器目录，几分钟后就能被浏览器访问。

需要临时共享、内网传文件、给非技术同事一个入口时，这种短路径很有价值。但只要页面能写、能删，安全边界就不能跟着安装包一起被“精简”掉。

所以我的判断标准也很简单：如果你要的是“给一个受控目录加个入口”，CHFS 值得试；如果你要的是“建设一套文件平台”，那就别让一个单文件程序背上它本来没打算解决的问题。

参考资料：

• CHFS 官方说明与下载：http://iscute.cn/chfs

阅读原文：点击这里