Workerman本身不提供HTTP文件下载防护，风险源于部署配置错误：Web服务器未禁止PHP脚本直接执行、入口文件置于Web可访问路径、vendor/src目录暴露、错误页面泄露路径等，需通过Nginx/Apache严格限制、移除可访问路径、清理冗余文件及关闭错误显示来防范。
Workerman常驻内存服务本身不提供HTTP文件下载防护，index.php 或 start.php 被直接访问时，PHP源码可能裸露——这不是框架漏洞，而是部署配置错误导致的典型风险。
Web服务器未禁止PHP脚本直接执行
Workerman启动的是独立监听进程（如 websocket://0.0.0.0:2828），但如果你同时用 Nginx/Apache 暴露了项目根目录（比如把 /var/www/workerman 设为网站根目录），且未禁用 PHP 脚本解析，攻击者就能通过 GET /start.php 直接触发 PHP 解析并输出源码（或报错泄露路径）。
- Nginx 必须显式拒绝所有非入口脚本的 PHP 执行：在 server 块中加
location ~ \.php$ { deny all; }，只允许index.php（如有）走 FastCGI，其他一律 403 - Apache 需禁用
AllowOverride All，并在.htaccess中写Deny from all，或在主配置中用<filesmatch>Require denied</filesmatch> - 切勿把 Workerman 入口文件（如
start.php）放在 Web 可访问路径下；应移至/opt/workerman/或/var/run/workerman/等非 Web 根目录
workerman/src/ 目录被意外暴露
Workerman 的核心类库（如 src/Worker.php）若被 Web 服务器当作静态文件返回，会直接泄露框架结构甚至版本号。这通常发生在开发者误将 vendor/workerman/workerman 整个软链进 Web 根目录，或使用 composer install --no-dev 后未清理 vendor 中的测试/文档文件。
- 生产环境部署前，运行
find vendor/ -name "*.md" -o -name "tests" -o -name "examples" | xargs rm -rf清理冗余内容 - 确认
vendor/workerman/workerman/src/不在任何 Web 可达路径中；建议用composer install --no-dev --optimize-autoloader安装，并设置vendor/权限为750、属主为运行 Web 服务的非特权用户（如www-data） - 在 Nginx 中添加全局拦截：
location ^~ /vendor/ { return 403; }
错误页面泄露绝对路径和源码片段
当 Workerman 进程崩溃或 PHP 报错（如未捕获异常、require 失败），若 PHP 配置了 display_errors = On 且 Web 服务器未接管错误页，浏览器可能看到带完整路径的堆栈，甚至部分源码高亮（尤其在开发环境误推到线上）。
- 线上环境必须设
display_errors = Off、log_errors = On，错误日志写入独立文件（如/var/log/workerman/error.log），权限设为640 - 在 Workerman 入口文件顶部加全局异常处理器：
set_exception_handler(function($e) { error_log($e); });，避免未捕获异常穿透到 Web 层 - 检查
php.ini中error_reporting是否为E_ALL & ~E_DEPRECATED & ~E_STRICT，禁用html_errors
真正危险的不是 Workerman 本身，而是它常驻内存后，一个配置疏漏会让整个项目结构长期暴露——而这种暴露往往持续数月无人察觉，直到被扫描器批量抓取。
