php文件权限应设为644（web目录下）或600（敏感配置文件），因apache仅需读取而非执行；切勿设755及以上，且须配合apache禁止上传目录解析php、正确配置php模块及open_basedir等加固措施。
PHP文件该用什么权限：644 还是 600？
Apache 运行时默认以 www-data（Debian/Ubuntu）或 apache（RHEL/CentOS）用户身份读取 PHP 文件，**不需要执行权限**。PHP 脚本由 PHP 解释器（如 mod_php 或 php-fpm）读取并执行，Apache 本身只负责传递请求、读取源码——所以 .php 文件设为 644 是安全且常见的底线；若放在 Web 目录外（如 /var/www/inc/），甚至应设为 600（仅属主可读写），防止被意外暴露。
-
644：文件所有者可读写，组和其他人仅可读 —— 适用于 Web 可访问目录下的.php（如/var/www/html/index.php） -
600：仅所有者可读写 —— 适用于配置文件、数据库凭证等敏感脚本（如/var/www/config/db.php），需确保 Apache 用户不属该文件所属组，否则组权限可能被误用 - 绝对不要设
755或更高（含执行位）：PHP 文件不是二进制，加x位无意义，反而可能在某些 CGI 模式下引发非预期执行逻辑
Apache 配置里怎么禁止直接下载 .php 源码？
核心不是靠文件权限，而是靠 Apache 的处理模块是否启用。如果 PHP 模块没加载或配置错误，.php 文件就会被当作纯文本下载——这和权限无关，而是 mod_php 或 php-fpm 是否接管了 .php 后缀。
- 检查是否启用了 PHP 处理：运行
apache2ctl -M | grep php（Debian）或httpd -M | grep php（RHEL），确认输出含php7_module或类似项 - 确认
AddHandler或SetHandler已正确配置，例如在站点配置中存在：<FilesMatch \.php$><br> SetHandler application/x-httpd-php<br></FilesMatch>
- 禁用
Options +Indexes和AllowOverride None（除非明确需要 .htaccess），避免因目录列表或覆盖规则导致源码泄露
上传目录里的 PHP 文件为什么不能执行？
这是关键防护点：Web 应用允许用户上传文件（如头像、附件），但绝不能让上传目录中的 .php 被 Apache 执行。常见做法是在虚拟主机或目录配置中**显式禁用 PHP 解析**。
- 在对应目录的 Apache 配置块中加入：
<Directory "/var/www/html/uploads"><br> php_flag engine off<br> <FilesMatch "\.(php|phtml|php3|php4|php5|php7|php8)$"><br> Require all denied<br> </FilesMatch><br></Directory>
- 若使用 php-fpm，还需确保该目录不在
php_admin_value[open_basedir]允许路径内，否则仍可能被包含执行 - 上传后的文件建议重命名（如 SHA256 + 固定扩展名），并存到 Web 根目录外；若必须放 Web 下，至少配合
LocationMatch做二次拦截
为什么改了文件权限还是被黑？重点看 owner 和 group
权限数字只是表象，真正起作用的是「谁运行 Apache」和「谁拥有文件」。比如你把 config.php 设成 600，但 Apache 进程以 www-data 用户运行，而该文件属主是 root，那 www-data 就读不了——结果不是更安全，而是应用直接报错；反过来，如果文件属主是 www-data，哪怕权限是 600，它也能读，这就失去隔离意义。
立即学习“PHP免费学习笔记（深入）”；
- 生产环境推荐分离角色：PHP 脚本由部署用户（如
deploy）拥有，Apache 以www-data运行，通过group（如加入deploy组）+640实现最小读取权 - 用
ls -l确认每类文件的实际 owner/group，比只看权限数字更重要 -
open_basedir、disable_functions、allow_url_include=Off这些 PHP 层配置，比文件权限更能堵住 include、file_get_contents 等函数导致的路径穿越或远程加载漏洞
