应禁止直接访问.php.ini等配置文件，通过filesmatch正则匹配并require all denied；正确做法是将php.ini置于/etc/php/等非web路径，config.php等应移出documentroot或加die()防护。
Apache如何阻止直接访问 .php.ini 或其他 PHP 配置文件
默认情况下，Apache 不会主动屏蔽对 .php.ini、php.ini、.env、config.php 等配置类文件的 HTTP 请求。一旦这些文件被放在 Web 根目录下且未做限制，攻击者可通过浏览器直接请求（如 https://example.com/.php.ini）获取敏感内容——包括数据库密码、密钥、调试开关等。
最稳妥的做法是：**不让这类文件出现在 Web 可访问路径中**。但若因历史原因必须共存，需通过 Apache 配置显式禁止访问：
- 在站点配置（
VirtualHost）或.htaccess中添加：<FilesMatch "\.(php\.ini|env|ini|inc|dist|sample|bak|swp|log)$"> Require all denied </FilesMatch> -
FilesMatch比Files更灵活，支持正则；注意 Apache 2.4+ 使用Require all denied，2.2 则用Order deny,allow+Deny from all - 不要只拦
.php.ini—— 开发中常见的config.php若含mysql_connect()或硬编码密码，同样危险
为什么把 php.ini 放进 DocumentRoot 是个坏主意
php.ini 本不该被 Web 服务器读取或提供服务——它是 PHP 解释器启动时加载的全局配置文件，由 PHP-CGI/FPM 进程读取，和 Apache 的 DocumentRoot 完全无关。把它放进 /var/www/html/ 唯一结果就是：增大被误暴露的风险。
正确路径应为：
立即学习“PHP免费学习笔记（深入）”；
- Debian/Ubuntu：
/etc/php/*/apache2/php.ini（* 为版本号，如 8.1） - CentOS/RHEL：
/etc/php.ini或/etc/php.d/*.ini - 确认位置可执行：
php --ini（CLI）或phpinfo()页面中的 “Loaded Configuration File”
如果项目需要自定义配置（如上传限制、错误报告），应使用 php_admin_value 在 Apache 的 VirtualHost 中设置，而非复制一份 php.ini 到网站目录。
防止 config.php 被直接下载的最小安全配置
很多 PHP 应用（如 Laravel、CodeIgniter）依赖 config.php 或类似文件存放数据库凭证。即使文件后缀是 .php，Apache 默认仍会执行它；但若因语法错误、MIME 类型误配或模块未启用，可能退化为“下载源码”——导致代码与密码一起泄露。
防御手段不是靠“文件名隐藏”，而是双重保险：
- 确保 PHP 模块已启用：
a2enmod php8.1（以实际版本为准），并确认AddType application/x-httpd-php .php存在于配置中 - 在
config.php开头强制退出（防御执行失败场景）：<?php die('Access denied.'); ?> - 更彻底的方式：把
config.php移出 DocumentRoot，例如放到/var/www/app/config/，再在入口脚本中require '/var/www/app/config/database.php';
常见错误：.htaccess 失效或被覆盖的排查点
加了 FilesMatch 却仍能下载 .env？可能是以下任一原因：
- Apache 主配置中
AllowOverride设为None，导致.htaccess完全不生效；应设为All或至少Limit - PHP 运行模式为 FPM（非 mod_php），此时
.htaccess对 PHP 相关行为无控制力——需改用 Nginx 的location ~ \.env$或在 Apache 中用LocationMatch - 拼写错误：写成
.envi或漏掉转义点号，正则变成.env$→ 匹配任意字符+env，极危险 - SELinux 启用时，即使 Apache 配置正确，也可能因上下文限制拒绝读取某些路径，可用
ausearch -m avc -ts recent查看拦截日志
真实环境中，最易被忽略的是「配置生效范围」：VirtualHost 内的规则不会自动继承到子目录，alias 路径或符号链接也常绕过预期限制。
