不能用 mod_proxy_ftp 实现 Web 协议访问内网 FTP 资源——该模块在 Apache 2.4.12 及之后版本中已被完全删除，不是配置问题，而是代码级移除；即使降级至 2.4.11，也仅支持明文 FTP、不兼容被动模式及非标准 LIST 响应，易报 503 错误；推荐改用后端脚本桥接、3proxy 或 HAProxy 代理，或迁移到 FTPS/S3。
不能用 mod_proxy_ftp 实现 Web 协议访问内网 FTP 资源——该模块在 Apache 2.4.12 及之后版本中已被完全删除，不是配置问题，而是代码级移除。
Apache 版本决定是否可行
执行 httpd -v 或 apache2 -v 查看当前版本：
- 若显示 2.4.12 或更高（如 2.4.59、2.4.62），mod_proxy_ftp 已不存在，LoadModule 会报错 Cannot load modules/mod_proxy_ftp.so，任何启用操作都无效
- 即使降级到 2.4.11，也仅支持明文 FTP（不支持 FTPS）、无法处理被动模式（PASV）端口协商、对 Windows IIS/ProFTPD 等返回的非标准 LIST 响应兼容性差，极易触发 503 错误
- 运行 httpd -M | grep ftp 在 2.4.12+ 中必然无输出，这是最直接的验证方式
替代方案：轻量桥接（推荐用于只读场景）
若目标只是让浏览器通过 HTTP 访问内网 FTP 的文件列表或下载静态资源（如软件包、文档），可用后端脚本做内容拉取与封装：
- 用 PHP/Python/Node.js 编写脚本，通过 FTP 客户端库连接内网 FTP 服务器，获取目录结构或文件内容
- Apache 将 /ftp/example.com/ 这类路径通过 ProxyPass 或直接托管指向该脚本输出（如 /ftp/ → /var/www/ftp-proxy.php）
- PHP 需开启 allow_url_fopen，或改用 cURL 显式控制超时、认证与编码；注意设置足够长的 Timeout 和 ProxyTimeout，避免 FTP 响应慢导致中断
- 脚本可缓存结果（如 Redis 或本地 JSON 文件），减少重复连接开销
替代方案：专用代理工具（适用于透明代理需求）
若业务要求客户端必须直输 ftp:// URL 并保持协议语义（例如旧系统集成、命令行工具调用），应放弃 Apache 内置方案：
- 3proxy 或 tinyproxy：原生支持 FTP 协议解析，能自动处理 PASV 模式端口映射，部署简单，适合内网网关场景
- HAProxy：在 TCP 层转发 FTP 控制连接（端口 21）和动态数据端口，需配合 iptables 规则或健康检查机制，稳定性高
- 启动示例（3proxy）：./src/ftp.proxy -D 12306 192.168.1.100:21，之后访问 ftp://gateway-ip:12306 即等效于访问内网 FTP
长期建议：淘汰 FTP，转向更现代的架构
FTP 协议本身缺乏标准化响应格式，且存在 NAT 穿透、防火墙策略、明文传输等固有缺陷。企业级实践已普遍迁移：
- 启用 FTPS（vsftpd/proftpd + TLS），保留 FTP 接口但加密传输
- 迁移到 S3 兼容存储（如 MinIO）+ Web 前端，提供 HTTPS 文件浏览、上传、权限控制，彻底规避 FTP 协议层限制
- 若仍需统一网关，可用 Apache 的 mod_proxy_http 对接上述服务，配合 mod_auth_openidc 或自建鉴权服务实现统一认证与权限注入
