Apache下禁止php文件被直接访问的解决方案

直接禁止导致的递归重定向问题

许多开发者尝试通过在 .htaccess 中添加规则来拒绝直接访问 PHP 文件。但在启用 RewriteEngine 后，简单的“禁止”逻辑往往适得其反。

假设我们有以下意图：

1. 将 /test 重写为 /test.php。
2. 禁止用户直接在浏览器中输入 /test.php。

直观的代码实现如下：

RewriteEngine On
RewriteRule ^test$ test.php [L]
RewriteRule ^test\.php$ - [F,L]

执行流程会出现严重冲突：

1. 用户访问 /test。
2. 第一条规则匹配，内部重定向到 /test.php。
3. 关键点：Apache 的内部重定向会重新触发整个重写引擎检查。
4. 在第二次检查中，URL 已经是 /test.php，触发了第二条规则。
5. 结果为 [F]（Forbidden），返回 403 错误。

这意味着，任何合法的、被内部重定向到的 PHP 请求都会被误杀。

利用 REDIRECT_URL 判断重定向状态

要解决这个问题，必须区分“用户的初始请求”和“服务器内部的二次请求”。Apache 提供了环境变量 %{REDIRECT_URL}：

• 初始请求：%{REDIRECT_URL} 为空或未定义。
• 重定向后请求：%{REDIRECT_URL} 保存的是上一次被修改前的原始 URL（例如 /test）。

因此，我们可以增加一个条件 RewriteCond，仅在未发生重定向时（即用户直接输入 php 地址时）才执行封禁操作。

修正后的 .htaccess 写法如下：

RewriteEngine On
# 1. 允许路径重写到 PHP
RewriteRule ^test$ test.php [L]

# 2. 仅在非重定向状态下（直接访问），禁止 PHP
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.+\.php)$ - [F,L]

这里使用 !-f 是一个更通用的技巧，或者直接指定规则：

# 当 URL 以 .php 结尾，且 NOT (由 rewrite 产生) 时才禁止
# 注意：Apache 2.4 后可直接用 expr，或依赖 REDIRECT_URL
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule ^test\.php$ - [F]

上述逻辑确保了：只有通过第一次规则跳转进来的请求（带有重定向状态）可以正常加载 PHP 文件；而用户直接在地址栏输入 .../test.php 的请求会被拦截。

服务端 PHP 层面的额外防御

虽然 Nginx/Apache 层的限制非常有效，但为了应对直接执行 PHP 二进制文件或配置错误的情况，可以在入口文件中加入服务端校验。这对应于草稿中提到的逻辑延伸：

<?php
// 检测是否经过重定向进入此脚本
if (isset($_SERVER['REDIRECT_URL']) && $_SERVER['REDIRECT_URL'] === '/test') {
    // 这是合法的重定向来源，允许执行
} else {
    // 如果没有 REDIRECT_URL，说明是直接访问，抛出错误或空白
    http_response_code(403);
    die('Access Forbidden'); 
}
?>

这种方法作为双保险，能确保即使绕过前端规则，PHP 脚本本身也能感知自身的调用上下文。

总结与排错建议

Apache 的 URL 重写是幂等的或基于状态的循环过程，简单粗暴的黑名单策略容易陷入死循环。

核心解决思路：

• 使用 REDIRECT_URL 或 REDIRECT_STATUS 识别请求来源。
• 确保“允许内部重写”的优先级高于或直接避开“禁止外部访问”的规则。

以上就是在 Apache 下安全隐藏 PHP 文件扩展名的详细内容，更多关于 URL 重写与安全配置的资料请关注本站其它相关文章！