为什么做这页
即便站点不是 Symfony 或 Laravel，扫描器仍会探测 app_dev.php、_profiler、Laravel .env 等路径。建议把这些路径当作防御需求信号：阻断、记录、脱敏、检查生产模式。
Symfony / Laravel debug profiler 路径加固清单
针对 /app_dev.php/_profiler/phpinfo、Laravel .env、框架 debug 路径探测的防御清单，适合小型 AI API 网关和自动交付站点。
合规边界：只做站点防御、日志脱敏、入口层加固和模板交付；不提供攻击脚本、撞库、扫描自动化或收益保证。
模板包含
- 框架调试路径 deny 规则与生产模式检查表
- Laravel/Symfony 常见误暴露路径的防御说明
- API 网关场景下的安全响应头与最小暴露原则
- 事件记录与责任披露页面文案
- 上线后 sitemap/IndexNow/JSON-LD 检查步骤
适合谁
小型 OpenAI-compatible API 网关、Cloudflare Pages/Worker 静态商店、Nginx/OpenResty 站点、自动交付 ZIP 产品页和 1C/1G VPS 运维者。
推荐动作
- 先确认敏感文件不在 public webroot：
.env、docker-compose.yml、私有 ZIP、API Key。 - 在 Nginx/OpenResty 或 Cloudflare Worker 层阻断明显调试/敏感路径。
- 日志只保留路径、状态码和低敏上下文，不把 token、地址、密码写入日志。
- 用 HEAD/GET 做无害验证，再提交 sitemap/IndexNow 让防御型页面被发现。
常见问题
如果我的站不是 PHP 框架，还需要吗？
需要参考入口层阻断思路。很多扫描不会先判断技术栈，静态站和 API 网关也会收到这些请求。
付费包是代码审计服务吗？
不是人工服务，是自动交付的模板 ZIP，适合自己按步骤加固。
会影响正常 API 用户吗？
规则设计目标是只处理明显的调试/敏感路径；上线前仍应在自己的域名上验证。