网站提示403 Forbidden怎么解决？

做站年头久了，403 Forbidden 这个提示迟早会跟你打照面。页面白底黑字就一行 Forbidden，用户截图发过来问是不是被黑了，其实多数时候服务器活得好好的，只是中间某一道门被关上了。它跟 502 那种后端崩掉不一样，403 的意思是请求确实到了，但有人明确说不给你看。麻烦的地方在于，能返回 403 的环节特别多，源站、CDN、WAF、面板防火墙都可能插一手，你光看提示根本分不清是谁干的。这篇就按我平时排查的顺序从头到尾走一遍，你照着捋，基本都能把真凶揪出来。

第一步先别改配置：用 curl -I 看清是谁在拦你

登上服务器，直接敲 curl -I 后面跟你的域名，会吐出一串响应头，重点看两样：状态码是不是 403，以及 Server 那一行写的是什么。如果 Server 显示 nginx，说明请求已经打到源站了，问题就在你自家的配置或者文件上，老老实实翻站点配置；如果 Server 是云厂商 CDN 节点的名字，或者响应头里带着 WAF 相关的标记，那多半是边缘那层拦下来的，源站说不定一点事没有，你去改 nginx 纯属白忙。这一步千万别省，我见过太多人一上来就翻 nginx.conf，折腾两个钟头才发现是防火墙误封，白熬一夜。

最常见的乌龙：站点目录下的首页文件不见了

排在第一位的原因其实特别朴素，就是 index.php 或者 index.html 被人删了、改名了，搬家的时候漏传了。服务器找不到默认首页，目录列表又是关着的，返回 403 是最标准的反应。去站点根目录 ls 一下，看首页文件在不在、权限对不对、大小写有没有写错，Linux 是认大小写的，Index.php 和 index.php 完全是两个东西。用压缩包上传站点时也容易出这事，包太大解压中断了根本不报错，文件少一两个你也不知道，最好对着本地的文件数点一遍，心里才有底。

Nginx 的 index 指令和 autoindex off，别把门焊死

接着看站点配置的 server 段里那行 index，正常写法是 index index.php index.html index.htm;，顺序代表查找优先级，写在前面的先找。这行被漏掉，或者写成了自家程序并不存在的文件名，服务器照样找不到首页。再看 location 段里有没有 autoindex off;，这个开关本身是对的，关掉目录列表属于基本安全操作，但它配合上首页文件丢失，页面就会从能看见文件列表直接变成 403。还有人手写加固时加过 return 403;，那就得翻配置历史，想清楚到底是哪一次改动留下的，别自己给自己挖坑。

location 里的 deny 和 allow，规则写反最容易中招

deny 和 allow 是 Nginx 的访问控制指令，从上往下匹配，谁先命中就按谁执行。常见翻车写法是先来一句 allow all; 再写 deny 192.168.1.0/24;，看着像只挡内网，实际上第一句已经把所有访客都放行了，后面的限制形同虚设，写的人还以为自己防住了。反过来更致命，哪次做防护时手一抖写了 deny all;，那全世界都得吃 403，包括你自己在内。还有一种是正则 location 里加了限制，专门挡某类 UA 或者某个目录，规则写宽了就会误伤正常访客。动手前先 grep 一遍 deny，把主配置和 include 进来的文件都覆盖到。

文件和目录属主不对，程序读不了文件也是 403

这种情况在搬家和换服务器之后特别集中。Nginx 和 PHP 通常以 www 用户的身份跑，如果站点目录属主是 root、权限又是 755，PHP 进程读不到文件，纯静态页面可能还正常，动态请求就会 403 和 500 混着来，看着毫无规律。稳妥做法是先切到站点目录，执行 chown -R www:www 加上一个点，表示当前目录连同子目录一起改属主；然后把目录权限设成 755、文件设成 644，别图省事直接上 chmod -R 777，那等于把安全门整个卸下来。有些环境跑的是 nginx 或者 www-data，得按机器上真实的运行身份来，用 ps aux | grep nginx 看一眼就清楚了。

面板里的防火墙，顺手看看自己的 IP 是不是进了黑名单

用面板建站的朋友注意，面板本身往往带了一层站点防火墙。进网站列表找到对应站点，点开防火墙那一栏，里面有 IP 黑名单、UA 黑名单、地区限制这些开关。我遇到过好几次 403，就是自己调试时请求太频繁，被规则自动拉黑了，连办公室的固定 IP 一起封进去，人在公司怎么刷都打不开，换成手机流量立马正常。这类问题特征很明显：换网络能开、换设备能开，只有那一条固定线路不行。找到名单把自己的 IP 删掉，或者干脆加进白名单，保存后记得让规则重新加载一次。

云厂商 WAF 和 CDN 的误封，判断有个小窍门

如果域名前面挂了 CDN 或者 WAF，就得去云厂商控制台里翻拦截日志，一般叫安全报表或者 WAF 日志。重点看两样东西：命中的规则名称，还有被拦的客户端 IP。常见触发点是请求里带了 SQL 注入的特征字符、上传目录被人扫、或者短时间高频访问触发了 CC 防护。判断窍门很简单，用 curl 直接打源站 IP 并指定 Host 头测试，源站能出页面而域名出 403，基本就能锁定是边缘那层干的。放行时别一刀切关掉整个防护，把误判的规则或 IP 加白名单更稳妥；各家控制台里规则的叫法和位置不一样，具体以厂商页面的说明为准。

逐项放行之后，用 nginx -t 和 reload 收口

改完配置别急着刷浏览器，先在命令行执行 nginx -t，它会做一次语法检查，看到 syntax is ok 和 test is successful 才算过关。有报错就按提示的行号回去改，千万不要带着语法错误去重启，服务起不来网站就真的全站打不开了，小毛病直接升级成大事故。检查通过之后执行 nginx -s reload，平滑加载新配置，不断开现有连接，访客几乎无感。用面板的话也可以点重载配置按钮，效果一样。重载完立刻 curl -I 再打一次域名，确认状态码从 403 变成 200，这一步做完才算闭环。

几句老话：收尾自查和以后怎么少踩坑

最后给个收尾清单。第一，403 消失之后把这次改动过的配置和权限记一笔，下次遇到同样的问题几分钟就能搞定；第二，检查有没有残留的临时放行规则，调试时加的白名单该撤就撤，别把口子一直开着；第三，网站错误日志和 nginx 的 error.log 都翻一眼，里面常常写着具体的拒绝原因，比坐在那儿猜快得多；第四，如果 403 只出现在某个目录或者某类文件上，那多半还是 location 规则在作怪，回头再 grep 一遍。养成动配置前先备份、改完先 nginx -t 的习惯，能省掉一大半事故。

绕一圈总结下：403 Forbidden 不是服务器坏了，而是有哪道门没开对。先用 curl -I 分清楚是源站还是 CDN 与 WAF 在拦，再按首页文件、index 指令、deny 规则、目录属主、面板防火墙这个顺序一项项查过去，最后用 nginx -t 加 reload 收口，顺手把 403 换成 200 确认一遍。这套动作走顺了，以后再看到那行 Forbidden，心里就不慌了。真正要紧的还是那句老话，配置改动留痕、权限别图省事，平时多花十分钟，出事少熬一整夜。