香港服务器部署网站后，浏览器出现 403，通常表示请求已经到达了某一层 HTTP 服务，但该服务拒绝继续读取或处理资源。若首页、静态文件、图片或 PHP 页面全部返回 403，原因可能不同；其中最常见的权限问题，不是简单执行一次 chmod 777，而是网站服务进程的用户、用户组无法穿过父目录，或者无法读取目标文件。

建议按照“确认 403 来源 → 找到实际服务身份 → 检查目录链路 → 检查文件和用户组 → 排除 ACL 与安全策略 → 检查 Web 配置和应用 → 验证恢复”的顺序处理。每一步都先观察结果，再决定是否修改权限，避免把故障从“无法访问”变成“权限过宽”或“应用无法写入”。

先确认 403 的范围和返回来源

不要只在浏览器中反复刷新。先确认是所有 URL 都失败，还是某一类路径失败。

可以从响应头和状态码开始检查：

curl -sS -D - -o /dev/null https://example.com/
curl -sS -D - -o /dev/null https://example.com/index.html
curl -sS -D - -o /dev/null https://example.com/assets/logo.png
curl -sS -D - -o /dev/null https://example.com/index.php

将 example.com 替换为实际域名。重点记录以下信息：

• 根路径 / 是否 403；
• 直接访问 index.html 或其他静态文件是否 403；
• PHP 页面是否单独 403；
• 不存在的路径是否仍返回 403；
• 响应头中的 Server、重定向和自定义错误页来自哪一层。

可以先按下面的现象建立判断方向：

如果本机通过源站入口访问正常，而域名访问仍然 403，不要立即修改文件权限。先确认域名请求是否命中了同一个 server、虚拟主机和网站根目录。

按服务日志确认拒绝发生在哪里

403 的具体原因通常比浏览器页面更容易在错误日志中看到。先确定使用的是 Nginx、Apache，还是 Nginx 加 PHP-FPM。

ps -eo user,group,pid,comm,args | egrep '[n]ginx|[a]pache2|[h]ttpd|[p]hp-fpm'
systemctl list-units --type=service --state=running | egrep 'nginx|apache|httpd|php.*fpm'

查看 Nginx 日志时，常见位置是 /var/log/nginx/error.log，但实际路径应以配置为准：

sudo tail -n 100 /var/log/nginx/error.log
sudo journalctl -u nginx --since "15 minutes ago" --no-pager

Apache 的服务名可能是 apache2 或 httpd：

sudo journalctl -u apache2 --since "15 minutes ago" --no-pager
sudo journalctl -u httpd --since "15 minutes ago" --no-pager

将日志时间与刚才的请求时间对应起来。常见日志含义如下：

• Permission denied：服务进程在操作系统层面无法访问路径；
• directory index ... is forbidden：访问的是目录，但没有可用首页，且目录列表被关闭；
• access forbidden by rule：配置中的 deny、allow、location、Require 等规则拒绝了请求；
• 没有对应的 Web 服务错误日志：可能请求没有进入预期虚拟主机，或者 403 来自应用、代理或其他入口。

如果只访问 / 时出现 directory index is forbidden，而访问 /index.html 返回 200，通常不需要放宽目录权限。应检查站点配置中的首页设置，例如 Nginx 是否配置了正确的 index 文件，或者部署时首页文件是否实际位于当前文档根目录。

确认真正读取文件的服务用户

登录香港服务器的 SSH 用户、部署用户和 Web 服务用户通常不是同一个账号。即使 Nginx 的主进程由 root 启动，实际处理请求的工作进程也可能使用 www-data、nginx 或其他低权限用户。

先查看进程的实际身份：

ps -eo user,group,pid,comm,args | egrep '[n]ginx|[a]pache2|[h]ttpd|[p]hp-fpm'

Nginx 还可以查看有效配置中的 user 指令：

sudo nginx -T 2>/dev/null | grep -nE '^[[:space:]]*user[[:space:]]'

PHP-FPM 的用户和用户组一般位于池配置中，路径会因 PHP 版本和发行版不同而变化：

sudo grep -R -nE '^[[:space:]]*(user|group)[[:space:]]*=' \
  /etc/php*/fpm/pool.d /etc/php-fpm.d 2>/dev/null

如果服务由 systemd 管理，也可以查看服务单元是否显式指定了身份：

sudo systemctl show nginx -p User -p Group -p FragmentPath
sudo systemctl show php8.2-fpm -p User -p Group -p FragmentPath

User= 为空并不一定代表异常，可能表示使用服务默认身份。此时应以实际工作进程和 Nginx、PHP-FPM 配置为准，而不是凭服务名猜测用户。

需要特别区分两类访问：

• Nginx 或 Apache 直接读取图片、CSS、HTML 时，使用的是 Web 服务工作进程身份；
• Nginx 将 PHP 请求转发给 PHP-FPM 时，PHP 脚本和应用目录可能由 PHP-FPM 池用户读取。

因此，静态文件正常而 PHP 页面 403 时，不能只检查 Nginx 用户。

检查文档根目录的每一级路径

Linux 文件权限中，目录的 x 权限表示“允许穿过该目录”，并不等同于执行程序。服务用户即使拥有目标文件的读取权限，只要 /srv、/srv/www、站点目录或 public 目录中的任一级缺少 x，仍然无法访问最终文件。

先确认 Web 配置实际指向的根目录。Nginx 可查看：

sudo nginx -T 2>/dev/null | grep -nE 'server_name|root|location|index|deny|allow'

Apache 可查看虚拟主机和目录配置：

sudo apachectl -S
sudo apachectl -t -D DUMP_RUN_CFG

如果系统使用的是 httpd，对应命令可能是：

sudo httpd -S
sudo httpd -t -D DUMP_RUN_CFG

确认路径后，使用 namei 查看从根目录到目标文件的每一级权限：

sudo namei -l /srv/www/example.com/public/index.html

再查看目标文件和目录的属主、属组及权限：

sudo stat -c '%A %a %U %G %n' \
  /srv/www/example.com \
  /srv/www/example.com/public \
  /srv/www/example.com/public/index.html

重点检查：

• 每一级父目录是否允许服务用户执行或穿过；
• 目标目录是否允许服务用户读取和穿过；
• 目标文件是否允许服务用户读取；
• 符号链接最终指向的位置是否仍在允许访问的路径中；
• 实际配置的根目录是否与部署文件所在目录一致。

常见错误包括把目录设置为 644。目录没有 x 权限时，服务进程无法进入目录，即使目录本身对用户显示为可读，也可能返回 403。

用服务身份做最小化访问测试

确定服务用户后，不要用自己的 SSH 账号测试。应使用与 Web 服务相同的用户执行只读检查。下面以 www-data 和实际站点路径为例，使用前请替换为已经确认的值：

WEB_USER=www-data
WEB_ROOT=/srv/www/example.com/public

sudo -u "$WEB_USER" -- test -x "$WEB_ROOT" \
  && echo "目录可穿过" \
  || echo "目录不可穿过"

sudo -u "$WEB_USER" -- test -r "$WEB_ROOT/index.html" \
  && echo "文件可读取" \
  || echo "文件不可读取"

如果要检查多级目录，可以逐级测试：

sudo -u "$WEB_USER" -- test -x /srv
sudo -u "$WEB_USER" -- test -x /srv/www
sudo -u "$WEB_USER" -- test -x /srv/www/example.com
sudo -u "$WEB_USER" -- test -x "$WEB_ROOT"

这些测试返回失败时，根因基本位于文件属主、用户组、目录权限或 ACL。返回成功但浏览器仍然 403，则应重点检查 Web 配置、SELinux、AppArmor 或应用自身逻辑。

不要直接用 sudo -u "$WEB_USER" cat 输出包含密钥、配置密码或用户数据的文件。排查读取能力时，test -r 通常已经足够。

修复属主、用户组和目录权限

权限修复应尽量只覆盖站点文档根目录，不要对整个 /var、/srv 或系统目录执行递归修改。修改前先保存权限和 ACL 信息，便于回滚：

SITE_ROOT=/srv/www/example.com

sudo getfacl -R -p "$SITE_ROOT" \
  > "/root/example.com.acl.$(date +%Y%m%d%H%M%S).bak"

如果 getfacl 不存在，应先安装对应的 ACL 工具，或至少使用 stat 保存目标目录和文件的当前属主、属组及权限。

对于只读网站代码，一个常见的最小权限模型是：

• 部署用户拥有文件，负责发布和更新；
• Web 服务用户通过专用用户组读取网站文件；
• 网站目录对该用户组提供必要的 r-x；
• 普通文件对该用户组提供必要的 r--；
• 上传、缓存、日志等需要写入的目录单独授权，不让整个代码目录可写。

假设已经确认服务用户属于 websvc 组，可以先对明确的目录和首页文件进行小范围修复：

SITE_ROOT=/srv/www/example.com/public
WEB_GROUP=websvc

sudo chgrp "$WEB_GROUP" "$SITE_ROOT"
sudo chmod g+rx "$SITE_ROOT"

sudo chgrp "$WEB_GROUP" "$SITE_ROOT/index.html"
sudo chmod g+r "$SITE_ROOT/index.html"

这组命令只适用于首页确实是 index.html、用户组已经存在且服务用户确实属于该组的情况。修改后验证：

id www-data
sudo -u www-data -- test -x "$SITE_ROOT"
sudo -u www-data -- test -r "$SITE_ROOT/index.html"

如果是嵌套的静态站点，所有父目录和需要访问的子目录都必须具备组的 x 权限，文件则通常需要组的 r 权限。下面的递归操作影响范围较大，只有在确认整个目录树都属于同一类网站静态内容、并已保存权限备份后才使用：

sudo find "$SITE_ROOT" -type d -exec chmod g+rx {} +
sudo find "$SITE_ROOT" -type f -exec chmod g+r {} +

这不会自动修正文件的属组，也可能让服务组读取原本不应暴露给 Web 服务的文件。因此，包含 .env、备份文件、私钥或部署凭据的目录不应直接套用此命令。敏感文件应移出文档根目录，或通过更精确的属主、属组和 ACL 单独处理。

如果需要把服务用户加入专用组，应使用追加方式，避免覆盖该用户原有的其他组：

sudo usermod -aG websvc www-data

用户组变化通常不会自动反映到已经运行的服务进程，可能需要在确认配置无误后重启对应服务。重启会影响正在处理的请求，应安排在合适的维护窗口，并先完成配置检查。

不要把 chmod -R 777 作为修复方案。它不仅可能解决不了父目录、ACL、SELinux 或 Web 配置造成的 403，还会让代码、上传文件和配置文件获得不必要的写权限。

权限看似正常时检查 ACL

传统 ls -l 只展示基本的属主、属组权限，不能完整反映 POSIX ACL。若服务用户的 test -r 或 test -x 失败，而基本权限看上去正常，应检查 ACL：

sudo getfacl -p /srv/www/example.com
sudo getfacl -p /srv/www/example.com/public
sudo getfacl -p /srv/www/example.com/public/index.html

重点看以下内容：

• 是否存在针对其他用户的额外拒绝或授权；
• mask:: 是否限制了组和命名用户的有效权限；
• 父目录是否缺少服务用户的遍历权限；
• 文件和目录的 ACL 是否与发布流程中的新文件不一致。

如果确定需要只给某个服务用户增加访问权，可以对明确路径进行精确授权。例如：

WEB_USER=www-data
SITE_ROOT=/srv/www/example.com/public

sudo setfacl -m u:"$WEB_USER":x /srv
sudo setfacl -m u:"$WEB_USER":x /srv/www
sudo setfacl -m u:"$WEB_USER":x /srv/www/example.com
sudo setfacl -m u:"$WEB_USER":rx "$SITE_ROOT"
sudo setfacl -m u:"$WEB_USER":r "$SITE_ROOT/index.html"

这类修改的前提是路径确实需要由该服务用户访问，并且已经保存了 getfacl 备份。回滚时使用对应备份：

sudo setfacl --restore=/root/example.com.acl.YYYYMMDDHHMMSS.bak

实际回滚文件名应替换为之前生成的备份文件。ACL 可能影响现有部署工具和权限继承，恢复后仍需重新执行服务身份测试。

排除 SELinux、AppArmor 和符号链接限制

在启用 SELinux 的系统上，Unix 权限和 ACL 都正确，并不代表 Web 服务一定可以读取文件。先查看状态和安全上下文：

getenforce
ls -Zd /srv/www/example.com/public
ls -Z /srv/www/example.com/public/index.html

如果错误日志或审计日志中出现 AVC 拒绝记录，可以查看最近事件：

sudo ausearch -m AVC -ts recent | tail -n 30

标准网站目录通常已有正确上下文；自定义路径可能需要按系统安全策略设置文件上下文。不要为了快速恢复而关闭 SELinux。若确认自定义路径属于 Web 内容，应先按照当前发行版的策略和已有站点规则配置，再执行上下文恢复。对于需要写入的上传或缓存目录，也不要把整个代码目录标记为可写，只给确实需要写入的目录授权。

使用 AppArmor 的系统可以查看内核日志中的拒绝信息：

sudo journalctl -k --since "15 minutes ago" --no-pager | grep -i apparmor

如果访问路径包含符号链接，检查最终目标：

readlink -f /srv/www/example.com/public/index.html
sudo namei -l "$(readlink -f /srv/www/example.com/public/index.html)"

最终目标位于文档根目录之外时，还要同时满足父目录权限、Web 服务的符号链接策略和安全模块规则。

排除 Nginx、Apache 和应用层规则

如果使用服务用户测试能够读取文件，但 HTTP 仍返回 403，问题很可能不是 Linux 基本权限。

Nginx 重点检查：

• 是否命中了错误的 server；
• location 是否存在 deny all、allow、internal 等规则；
• 是否配置了错误的 root 或 alias；
• alias 与请求路径拼接是否正确；
• 是否启用了禁止访问隐藏文件或特定扩展名的规则。

Apache 重点检查：

• 是否包含 Require all denied；
• .htaccess 是否拒绝了请求；
• 虚拟主机的 DocumentRoot 是否指向正确目录；
• 是否有按文件名、来源地址或请求方法限制访问的规则。

修改配置前先备份文件，修改后必须先做语法检查：

sudo nginx -t
sudo apachectl configtest

确认检查通过后，再根据实际服务名平滑加载配置：

sudo systemctl reload nginx
sudo systemctl reload apache2

如果服务名是 httpd，应使用对应的服务单元。配置修改只针对出现问题的站点或路径，不要为了绕过 403 删除全部访问控制。

还要区分 Web 服务返回的 403 与应用返回的 403。可以分别访问一个已知存在的静态文件和动态页面：

curl -sS -D - -o /dev/null https://example.com/known-static.html
curl -sS -D - -o /dev/null https://example.com/index.php

如果静态文件正常，只有 PHP 页面返回 403，应检查 PHP-FPM 池用户、应用日志、框架权限判断、登录状态和路由规则。此时盲目修改网站目录权限，通常无法解决应用主动返回的拒绝。

修复后的验证顺序

权限修改或配置修改完成后，至少完成以下验证：

1. 用服务身份重新执行目录穿越和文件读取测试。

sudo -u www-data -- test -x /srv/www/example.com/public
sudo -u www-data -- test -r /srv/www/example.com/public/index.html

1. 访问根路径、明确首页、静态资源和动态页面，确认不是只恢复了单个 URL。

curl -sS -D - -o /dev/null https://example.com/
curl -sS -D - -o /dev/null https://example.com/index.html
curl -sS -D - -o /dev/null https://example.com/assets/logo.png
curl -sS -D - -o /dev/null https://example.com/index.php

1. 重新查看错误日志，确认没有新的 permission denied、directory index is forbidden 或配置拒绝记录。
2. 如果刚修改了用户组、ACL 或安全上下文，重新启动或重新加载相关服务后再次测试，确认权限没有只存在于当前进程或当前终端环境中。
3. 通过一次正常发布或文件更新流程进行回归测试，确认新文件继承了正确的属组和权限，且上传、缓存、日志目录仍按预期可写。

让同类 403 更容易定位

网站恢复后，建议记录以下信息，避免下次重新猜测：

• 实际文档根目录；
• Nginx、Apache 和 PHP-FPM 的有效服务用户；
• 网站代码目录的属主、属组和权限模型；
• 哪些目录允许 Web 服务写入；
• 是否使用 ACL、SELinux 或 AppArmor；
• 静态文件、动态文件和上传目录分别如何验证。

部署流程中可以加入一个低风险的发布后检查：使用服务用户测试首页、静态资源和必要的运行目录，并在发现权限变化时停止发布。监控方面，除了关注 HTTP 403 数量，还应关联 Web 错误日志中的 permission denied、配置拒绝和应用拒绝。这样可以区分“文件不可读”“规则主动拒绝”和“应用业务判断”，避免每次出现 403 都扩大目录权限。