网站突然打不开报 403，后台提示更新成功页面却还是旧内容，或者网站被入侵后出现了可执行的恶意脚本——这三类问题很多时候根源是同一个：文件权限（即操作系统规定”谁能读、谁能写、谁能执行某个文件”的规则）设置错了。本文会把 755 和 644 这两组最常见的权限数字讲清楚：它们各自适合用在什么地方，设错了会出现什么症状，以及如何一步步找出被误设的文件，跟着排查一遍大约只需十几分钟。
755 和 644 到底是什么意思
要理解这两组数字，先要看懂 Linux 权限的三段结构。每次执行 ls -l，你会看到类似 rwxr-xr-x 的字符串，它分成三组：第一组是文件所有者（owner）的权限，第二组是所属组（group）的权限，第三组是其他用户（others）的权限。r 代表可读（值为 4），w 代表可写（值为 2），x 代表可执行（值为 1），把每组三个数字相加，就得到了我们熟悉的权限数字。
按这个算法，755 展开就是 rwxr-xr-x：所有者可以读写执行，组和其他人只能读和执行。644 展开是 rw-r--r--：所有者可以读写，组和其他人只能读。
放在网站场景里，两者的分工非常明确：
- 目录用 755：目录必须有执行位才能被进入和遍历，所以目录一律 755，否则即使文件权限正确，Web 服务进程也无法穿过目录访问到文件。
- 网站静态文件用 644：HTML、CSS、图片、JS 这类文件只需要被读取，所有者保留写权限用于更新，其他人只读，防止被篡改。
- PHP 等脚本文件也用 644：PHP 由 PHP-FPM（FastCGI 进程管理器）这类解释器进程读取执行，脚本文件本身不需要对 Web 用户开放执行位。
- 少数特殊文件才需要更高权限：比如某些 CLI 工具脚本直接通过
./script.sh执行，才需要所有者带执行位；包含数据库密码的配置文件（如wp-config.php）反而建议收紧到 640 甚至 600。
核心结论是：“755 给目录、644 给文件”是绝大多数共享主机和 LNMP 架构下的安全基线。偏离这个基线要么导致访问异常，要么打开安全缺口。
权限误设的两类典型症状
误设权限的后果分两个方向，症状完全相反，排查思路也不同。
第一类：权限过严，网站直接打不开。 最常见的是把目录设成 700 或者把文件设成 600，但运行 Web 服务的用户（例如 www-data）不是文件所有者，于是读不到文件，前台报 403 Forbidden，或者 WordPress 主题、插件样式全部丢失。还有一种隐蔽情况：迁移网站时用 root 解压，所有文件所有者都变成 root，权限数字看着是 755/644，但 Web 用户不在所有者组里，照样 403——这种情况要看所有者而不是权限数字。
第二类：权限过松，网站成为攻击跳板。 典型错误是图省事执行了 chmod -R 777，让所有用户都能写所有文件。攻击者只要找到一个可写目录（比如上传目录），就能写入 .php 结尾的 webshell（一种可以远程操控服务器的恶意脚本）并获得执行能力，安全扫描工具报告的”高危：目录可写”告警绝大多数源于此。另一种过松情况是给 PHP 文件加了组或其他人的写权限，同机的其他租户就有机会篡改你的代码。
403、样式丢失、无法上传，先怀疑”过严”；被入侵、出现陌生文件、扫描告警，先怀疑”过松”。
误设排查：从定位到修复的完整流程
排查权限问题用系统自带命令就够了。以网站根目录 /var/www/example.com 为例，按”先看方向，再定位文件，最后批量修复”的顺序走。
第一步：确认运行 Web 服务的用户是谁。 执行 ps aux | grep -E 'nginx|php-fpm|apache'，输出第一列就是用户名，常见的是 www-data 或 nginx。后面所有判断都以这个用户为基准。
第二步：找出所有者或权限不对的文件。 修复过严问题，先列出所有不属于 Web 用户的文件：
find /var/www/example.com ! -user www-data -ls | head -30
修复过松问题，把两类高危文件分别找出来：
# 找出所有 777 的目录和文件
find /var/www/example.com -perm 777 -ls
# 找出对组或其他用户开放写权限的文件
find /var/www/example.com -perm /go+w -type f -ls
如果某个具体页面 403，用 namei -l /var/www/example.com/path/file.html 逐层查看路径上每个目录的权限和所有者，很多”权限明明对却打不开”的问题都出在路径中某一层目录上。
第三步：批量修正到安全基线。 确认要修的文件范围后，两条命令把整站归位：
find /var/www/example.com -type d -exec chmod 755 {} +
find /var/www/example.com -type f -exec chmod 644 {} +
如果第二步发现所有者错乱（比如全是 root），再补一条 chown -R www-data:www-data /var/www/example.com。注意 wp-config.php 这类含敏感信息的文件要单独收紧：chmod 640 wp-config.php，并把组设为 Web 用户所属组。
第四步：验证修复效果。 前台刷新报错页面确认恢复；再用 sudo -u www-data cat /var/www/example.com/index.php 模拟 Web 用户读文件，能输出说明读取链路通畅。最后重跑第二步的 find 命令，输出为空才算清零。
这里有一个容易踩的坑：chmod -R 755 会把文件也设成 755，让所有脚本带上执行位。所以批量修正时务必像上面那样用 -type d 和 -type f 分开处理，一条命令管目录、一条管文件。
上传目录和定时任务等特殊场景的处理
基线规则之外，有几个场景需要单独对待，一刀切反而会出问题。
上传目录是矛盾最集中的地方：它必须允许 Web 用户写入（否则用户传不了图片），又绝不能允许执行。标准做法是目录给 755、所有者是 Web 用户，再在 Nginx 里对上传目录禁用 PHP 解析：
location ~* ^/wp-content/uploads/.*\.php$ {
deny all;
}
这样即使攻击者利用漏洞把 .php 文件传进上传目录，请求也会被直接拒绝，可写带来的风险就被限制在可控范围内。
多人协作或部署场景下，如果 Git 拉取代码的用户和 Web 用户不同，可以把两者加入同一个组，目录用 775、文件用 664（组可写），既保证部署顺畅，又不向”其他用户”开放写权限。前提是明确知道组里有哪些成员。
定时任务脚本容易出另一个方向的错：crontab 里以 root 跑的脚本写出了 root 所有、644 权限的缓存文件，Web 用户下次要更新这个缓存时就写不进去，表现为页面偶发报错、刷新后恢复。对比缓存文件的 ls -l 所有者和 Web 用户名，把生成任务的执行用户改成 Web 用户即可。
如果你用的是 Hostease 的虚拟主机，文件权限由 cPanel 面板的”文件管理器”图形化设置，勾选 Read/Write/Execute 复选框即可，数值同样遵循”目录 755、文件 644″的基线；独立服务器和 VPS 主机 用户则可以直接使用本文的命令行方案。相关主题的深入配置可以参考站内的 Linux 服务器安全加固：SSH、fail2ban 与防火墙实战配置 和 独立服务器的安全边界怎么补 两篇文章。
排查清单与日常维护建议
权限问题”设错一次，隐患长期存在”，与其事后排查，不如把检查纳入例行维护流程：
- 大版本上线或迁移后，跑一次
find /var/www/example.com -perm /go+w -o ! -user www-data | wc -l，结果非零就说明有文件偏离基线。 - 每月检查上传目录：确认没有
.php混入（find uploads/ -name "*.php"），权限保持 755 而非 777。 - 修改权限前用
stat 文件名记录当前状态，出问题可以立刻还原。 - 含数据库账号密码的配置文件统一收紧到 640，并列入上线检查项。
- 在部署脚本里固化
find -type d -exec chmod 755和find -type f -exec chmod 644，让每次发布自动归位。
总结一下：755 给目录、644 给文件是网站文件权限的安全基线，403 类问题沿”所有者 + 路径层级”排查，安全类问题沿”可写位 + 执行位”排查，find 加 chmod 的组合足以覆盖 90% 的场景。如果你需要一套权限之外更完整的服务器防护方案，可以考虑在现有 VPS（虚拟专用服务器）基础上叠加 Hostease 的独立服务器 方案，配合站内的 nftables 防火墙规则深度实战 一起把安全层做厚。这些投入很小，挡住的却是最常见、成本最低的一类攻击入口。