必须启用security日志通道并设level为debug，检查config_dev.yml中monolog是否配置security handler，再通过tail -f var/logs/security.log查看Access denied详情及请求路径。
如何确认安全拦截是否生效并记录路径
Symfony 2 的 Web Debug Toolbar（WDT）本身不显示安全拦截详情，security.intercept_redirect 或 access_denied 事件触发后，若未显式配置日志通道，请求会被静默重定向或返回 403，而 WDT 里看不到拦截痕迹。必须主动启用 Security 日志通道，并确保其 level 至少为 debug。
检查 config_dev.yml 中的 monolog 配置是否包含 security handler：
monolog:
handlers:
security:
type: stream
path: "%kernel.logs_dir%/security.log"
level: debug
channels: ["security"]
若缺失该段，security 通道的日志会退回到 main handler，但默认 main 不捕获 security channel —— 导致你刷新页面却在 dev.log 里找不到任何 Access denied 记录。
查看被拒绝访问的路径和原因
执行 tail -f var/logs/security.log，然后手动访问一个受保护但无权限的路径（如 /admin/dashboard），你会看到类似：
[2026-08-13 16:25:12] security.DEBUG: Access denied, the user is not fully authenticated; redirecting to authentication entry point. {"exception":"[object] (Symfony\Component\Security\Core\Exception\AccessDeniedException(code: 403): Access Denied at ..."} []
关键字段是：
-
Access denied, the user is not fully authenticated：说明用户未登录，被重定向到 login 路由 -
Access denied, the token was disabled：用户已认证但角色不足（如需要ROLE_ADMIN却只有ROLE_USER） -
path字段不会直接打印，但可通过上下文中的request_uri或日志前缀推断（如 Apache/Nginx access log 对照时间戳）
快速定位哪个防火墙/规则触发了拦截
Symfony 2 使用多个 firewall，每个有独立 access_control 规则。拦截发生时，日志中不会自动标明命中哪条规则 —— 你需要结合 security.yml 顺序与请求路径人工比对：
- 规则按定义顺序从上到下匹配，**第一条匹配的 rule 决定结果**
- 检查
security.yml中access_control的path是否用了正则（如^/admin）而非完整路径（/admin） - 注意
host、methods、ips等附加条件是否意外排除了当前请求 - 临时在某条 rule 前加
path: ^/debug-trigger并访问该路径，验证是否真被该 firewall 拦截
为什么 router:match 查不到被拦截的路由
php bin/console router:match /admin/dashboard 只测试路由是否可解析，**不经过安全层**。只要路由存在且方法匹配，它就显示“matched”，哪怕后续被 access_control 拒绝。这是最常被误解的一点。
真正要验证安全逻辑，必须发起真实 HTTP 请求（浏览器或 curl），并盯住 security.log。如果日志为空：
- 确认
APP_ENV=dev且APP_DEBUG=1（否则 security channel 日志被禁用） - 确认
security.yml中启用了access_denied_url或自定义异常监听器，否则某些拦截可能跳过日志写入 - 检查
var/logs/目录权限，security.log文件是否被创建但不可写（ls -l var/logs/security.log）
安全拦截日志不像 Doctrine 或 Router 日志那样“自动可见”，它依赖显式通道绑定和 debug 级别开启——漏掉任一环，路径就被拒绝了，你却什么也看不到。
