IIS 403无权使用凭据查看目录？6步排查修复指南

保哥这条笔记最早是 2017 年从息壤搬站到阿里云的时候记录的。那一年我买了一台 Windows Server 2008 的 ECS 实例，把两个 ASP 站点搬上去，结果一打开就是熟悉的 403 红字提示：“访问被拒绝，您无权使用所提供的凭据查看此目录或页面。”

这个错误信息看上去像是权限问题，让人第一反应去查文件系统权限、应用程序池身份、用户账户密码，结果折腾半天才发现根本是另一回事。这些年我陆陆续续帮朋友处理过类似情况，从老版本的 IIS 6 到现代的 IIS 10 都遇到过，触发原因不止一种。今天把这些场景一次性整理出来，按概率从高到低排序，方便你快速定位并修复。读完这篇文章，你大概能省下两到三个小时的搜索和试错时间。

第一时间确认错误的子状态码到底是什么

微软的 IIS 在返回 403 错误时其实有十几个细分子代码，单看“您无权使用所提供的凭据”这句话不够准确。先在浏览器地址栏访问网站，把页面拉到最底部或者按 F12 看网络面板，找到具体的 HTTP 状态码。

常见的 403 子代码含义如下：

403.14 “Web 服务器配置为不列出此目录的内容”。这是出现频率最高的，本质是默认文档没设对。

403.1 “执行访问被拒绝”。一般是脚本权限问题，应用程序池没启用对应的运行时（比如 ASP 或 PHP 没装）。

403.2 “读取访问被拒绝”。物理目录的文件系统权限不够，匿名用户读不到文件。

403.4 “要求安全连接”。明文请求被强制跳到加密通道但证书没装好。

403.6 “客户端 IP 被拒绝”。IIS 的 IP 限制规则把客户端拦了。

403.7 “要求客户端证书”。常见于政府、银行、医院的内部系统。

403.8 “站点访问被拒绝”。一般是 hosts 文件和站点绑定不一致。

403.16 “客户端证书不受信任或无效”。客户端证书过期或来自不受信任的 CA。

403.18 “在当前应用程序池中不能执行所请求的 URL”。多站点共享应用程序池时的常见错误。

403.19 “不能为这个应用程序池中的客户端执行 CGI”。应用程序池标识权限不够。

保哥当年遇到的就是 403.14，原因是从息壤迁过来的站点入口文件叫小写的 index.asp，但新装的 IIS 默认文档列表里只有几个常见名字，唯独没有这个小写的入口文件。浏览器请求根路径，IIS 找不到默认文档，又因为目录浏览功能默认关闭，就直接抛 403 了。

搞清楚子状态码这一步特别关键，可以让你少走至少一半的弯路。如果你看到的子状态码是 403.14，直接跳到下面的步骤一；如果是 403.2，跳到步骤二；如果是 403.6 或 403.8，跳到步骤五；如果是 403.1，跳到步骤三的处理程序映射部分。

排查步骤一：检查并添加默认文档

这是出现频率最高的原因，先从这里下手。

第一步，在服务器上打开 IIS 管理器。可以在“运行”框里输入inetmgr命令直接打开，或者从“开始 → 管理工具”里找。

第二步，在左侧导航树里展开“网站”节点，点选你的目标站点。

第三步，在右侧功能视图里双击“默认文档”图标。

第四步，看列表里有没有你的入口文件名。常见的入口文件包括小写的index.asp、index.html、index.htm、index.php，也包括大写开头的Default.asp、Default.aspx。注意 Windows 文件系统不区分大小写，但 IIS 的默认文档列表会按列表顺序匹配，第一个能找到对应文件的会被使用。

第五步，如果列表里没有你的入口文件，点右侧的“添加”按钮，输入入口文件名比如index.asp，确定。

第六步，添加后默认排在列表最下面，需要选中它，点右侧的“上移”按钮，挪到列表最上方，让 IIS 优先匹配你的入口文件。

这一步做完，刷新浏览器，绝大多数 403.14 错误都能解决。

如果想用配置文件批量处理，也可以直接编辑站点目录下的 web.config 文件：

<configuration>
    <system.webServer>
        <defaultDocument>
            <files>
                <clear />
                <add value="index.asp" />
                <add value="index.html" />
                <add value="index.aspx" />
            </files>
        </defaultDocument>
    </system.webServer>
</configuration>

保哥习惯把 clear 标签写在最前面，这样可以清空继承自父配置的默认文档列表，完全按当前站点的需求来排序，避免出现“我已经把入口文件放最上面了，但 IIS 还是先找别的”这种诡异情况。这个写法在 IIS 7 及以上版本都有效。

排查步骤二：检查匿名身份验证和文件系统权限

如果默认文档已经设好了还是 403，第二个怀疑对象是身份验证配置。子状态码通常是 403.2。

打开 IIS 管理器，选中站点，双击“身份验证”图标，确认两件事。

第一，匿名身份验证必须是“已启用”状态。如果显示“已禁用”，右键启用。绝大部分公开访问的网站都需要启用匿名访问。

第二，匿名身份验证使用的用户。右键“编辑”，确认使用的是 IUSR 或者“应用程序池标识”。一般推荐选“应用程序池标识”，权限管理更现代，每个站点独立一个身份，相互之间不会越权访问。

然后回到服务器文件系统，找到站点的物理目录，比如典型路径下的网站文件夹，右键属性，安全选项卡，确认以下三个用户或组至少有“读取和执行”权限：

IIS_IUSRS 用户组（IIS 工作进程所在的组）；IUSR 用户（经典匿名用户）；应用程序池标识（格式是IIS AppPool\加上你的应用池名）。

保哥踩过一个坑：从其他服务器复制过来的网站文件夹，文件系统权限是空的，只有系统账户和管理员组能访问。当时反复检查 IIS 配置都没问题，结果是文件夹权限没继承。解决办法是右键文件夹，属性，安全，高级，启用继承，应用到所有子对象。这一步在迁移服务器时几乎是必须做的，建议写到部署清单里。

除了 GUI 操作，也可以用命令行批量修复权限。在管理员 PowerShell 里执行：

$path = "C:\inetpub\wwwroot\mysite"
icacls $path /grant "IIS_IUSRS:(OI)(CI)RX" /T
icacls $path /grant "IUSR:(OI)(CI)RX" /T
icacls $path /grant "IIS AppPool\DefaultAppPool:(OI)(CI)RX" /T

这段命令会递归地给三个核心账号添加读取和执行权限。(OI)(CI)表示对象继承和容器继承，RX是读取加执行权限，/T是递归处理所有子目录和文件。

排查步骤三：检查目录浏览和处理程序映射

如果你的站点根目录确实没有放任何默认文档，比如纯下载站、API 接口站、静态资源服务器，那就需要明确启用“目录浏览”功能：打开 IIS 管理器选中目标站点，双击“目录浏览”图标，右侧操作面板点“启用”。

但要注意，目录浏览启用后整个目录的文件结构都会暴露在前台，安全性较差，生产环境一般不建议这么做。更好的方案是写一个空的占位首页文件，让用户访问根路径时看到一个友好的提示页或重定向。

另一个容易被忽略的点是处理程序映射。新装的 IIS 如果没有勾选 ASP 或 ASP.NET 角色服务，就算放了入口文件也无法解析，会回退到目录浏览，进而报 403 错误。修复步骤：

第一，打开服务器管理器，添加角色和功能。

第二，找到“Web 服务器（IIS） → 应用程序开发”分支。

第三，勾选 ASP、ASP.NET 各版本、ISAPI 扩展、ISAPI 筛选器。如果是 ASP 站点，还要额外勾选 ASP 模块。

第四，安装完成后重启 IIS 服务，可以用以下命令一键完成：

iisreset /restart

这个命令会停止再启动所有 IIS 相关服务，整个过程通常只需要几秒钟。如果服务器上有多个站点都在运行，重启会让所有站点短暂不可用，最好选在凌晨低峰时段做。

如果你的站点是 PHP 站点，还需要确认 PHP 处理器已经映射到.php扩展名。在“处理程序映射”界面看有没有一行 FastCGI 模块指向.php且模块路径是 PHP-CGI.exe。如果没有，需要手动添加。

排查步骤四：日志才是最终答案

上面三步覆盖了 95% 的场景，剩下 5% 的疑难杂症必须靠日志。IIS 默认日志路径在系统盘的 inetpub 目录下的 logs 子目录里。

C:\inetpub\logs\LogFiles\W3SVC{站点ID}\

站点编号可以在 IIS 管理器里选中站点后，右下角的“高级设置”里看到。日志文件按日期命名，类似u_ex251201.log这种格式（u_ex 加 yymmdd）。用记事本或者更专业的工具打开最新一个，搜索 403 关键字，找到刚才出错的那一行，重点看末尾几个字段：

sc-status sc-substatus sc-win32-status
403       14           0

sc-status 是 HTTP 主状态码，sc-substatus 是子状态码（前面提到的 403.14 就是这里来的），sc-win32-status 是 Windows 错误代码（零表示无附加错误，非零数字代表特定的系统错误）。

如果 Windows 错误代码不是零，可以用命令查含义：

net helpmsg 5

保哥之前遇到过 Windows 错误代码是 5 的情况，命令显示“拒绝访问”，这就明确指向文件系统权限问题，跟 IIS 配置无关。这种思路比盲目改配置高效得多，能直接锁定问题根源。读日志的能力是运维水平拉开差距的关键，强烈建议多花时间练习。

除了 IIS 自身的日志，Windows 系统事件日志也是排查 403 的重要信息源。在“事件查看器 → Windows 日志 → 应用程序”里搜索 ASP.NET 或 W3SVC 相关的错误事件，能看到应用层抛出的详细异常堆栈，有时候比 IIS 日志更具体。

排查步骤五：IP 限制、URL 重写、hosts 配置问题

如果子状态码是 403.6 或 403.8，问题在网络访问层面。这种情况下默认文档和文件权限都不是问题，需要换思路。

403.6 IP 限制：检查 IIS 的“IP 地址和域限制”模块，看有没有黑白名单规则把你的客户端 IP 拦截了。常见场景是：从客户机访问正常但从办公室访问 403，因为办公室 IP 段被加到了黑名单。或者反过来：白名单只放了几个固定 IP，所有其他 IP 都被拒绝。

403.8 站点访问被拒绝：检查站点绑定是否和访问 URL 匹配。比如绑定的是example.com:80，但用户访问的是www.example.com:80，IIS 会拒绝。需要在“绑定”里同时加上带 www 和不带 www 的绑定。或者使用 URL 重写规则做 301 跳转统一域名。

另一个常见的 403.8 来源是 hosts 文件和站点绑定不一致。如果服务器自己的 hosts 文件指定example.com解析到127.0.0.1，而站点绑定是192.168.1.100，本机访问会失败。检查 C:\Windows\System32\drivers\etc\hosts 文件，确认本地映射正确。

排查步骤六：现代化迁移建议与运维总结

2017 年那会儿用 Windows Server 2008 加 IIS 7.5 加 ASP 还能凑合，2026 年再这么搞就是给自己挖坑。微软已经停止 Windows Server 2008 的扩展支持，安全更新也基本没有了。如果你现在还在用类似环境，保哥的建议是分四步走。

第一，ASP 站点尽快迁移到现代后端框架。经典 ASP 用的脚本语言已经超过 20 年没更新过，安全漏洞多，开发效率也低。可以考虑迁移到现代.NET 框架（ASP.NET Core）或者 PHP 8。.NET 8 的 LTS 版本会一直支持到 2026 年 11 月，是安全可控的长期选择。

第二，服务器系统升级到 Windows Server 2019 或 2022，或者直接转 Linux。新版 IIS 10 默认配置就比 7.5 好很多，很多权限坑直接消失。Linux 加 Nginx 加 PHP 的组合维护成本更低，且开源社区更活跃。

第三，静态站点考虑搬到内容分发网络加对象存储。比如阿里云对象存储 OSS 加 CDN 组合，比维护一台 IIS 服务器省心十倍，还便宜。完全静态的网站月费可能只有几块钱。

第四，必须保留经典 ASP 的话，至少把站点放到反向代理后面。前面用 Nginx 做安全连接卸载和 Web 应用防火墙，IIS 只跑业务逻辑，安全性提升一个量级。

保哥这些年的总结是，运维问题大部分时候都不是单点故障，而是配置组合的问题。今天这台服务器没事，明天换个客户端浏览器或者换个网络环境就可能复现。建立完整的部署清单和巡检脚本，比临时救火重要得多。

给一份保哥常用的部署清单作为参考：新站点上线时检查的 12 项是——默认文档配置正确、应用程序池标识权限正确、文件系统权限继承启用、防火墙端口放行、安全组规则配置、ISP 80 端口是否封禁、SSL 证书安装且未过期、HTTP 到 HTTPS 跳转配置、www 和非 www 域名统一处理、自定义错误页面配置、Server 头信息隐藏、IIS 日志开启且定期归档。每一项都过一遍能避免绝大部分上线后的 403 和其他错误。这份清单可以做成 Markdown 模板贴到团队 Wiki 里，每次部署照着勾选。

常见问题解答

默认文档加了，重启 IIS 也还是 403 怎么办

按顺序检查：第一，入口文件名拼写是否完全一致，虽然 Windows 不区分大小写但建议保持和实际文件名一致；第二，入口文件是否真的存在于站点根目录，是不是被部署脚本漏掉了或者文件名带了隐藏的.txt扩展（在文件夹选项里勾选“显示已知扩展名”确认）；第三，应用程序池是否启动状态，可以在 IIS 管理器里看应用池列表；第四，应用程序池的.NET CLR 版本和托管管道模式是否匹配你的代码，经典 ASP 应该选“无托管代码”。

浏览器一直显示 403，但其他人访问正常

大概率是 IIS 的 IP 限制规则、URL 重写规则或者你本地的主机映射文件出了问题。先用手机的移动数据网络访问试试是不是稳定，再看 IIS 的“IP 地址和域限制”里有没有黑白名单。也可以临时清空浏览器缓存和 Cookie 试试。如果还是不行，用tracert example.com看网络链路有没有问题，可能是中间路由器拦截了。

本地能访问外网访问就 403 怎么办

检查站点绑定。IIS 管理器里选中站点，右侧“绑定”，看主机名和端口是不是配对。然后检查防火墙，Windows 防火墙的“入站规则”要放行 80 和 443 端口。云服务器还要在控制台的安全组规则里开放对应端口，公网能不能进来要看安全组的最外层规则。最后还要看一下 ISP 是否封禁了 80 端口（国内宽带运营商有时候会封 80 端口要求备案，需要换成 8080 或者完成 ICP 备案）。

升级到 IIS 10 之后还会不会遇到这种 403

会，但概率显著降低。IIS 10 默认启用了更多文档名，权限继承也更智能。最常见的剩余坑是.NET Core 的进程内部署模式下应用没启动起来，这时候 403 信息会变成 502.5，跟旧版的 403.14 完全不一样。看到 502.5 直接去查应用日志，多半是新版运行时没装或者版本不对。

从经典 ASP 迁移到现代框架时还需要保留这套排查思路吗

部分需要保留。默认文档、文件系统权限、应用程序池身份这些概念在新一代框架里依然存在，只是配置方式略有不同。日志读取的能力更是通用技能，不管什么后端框架都用得上。保哥的建议是把这套排查思路抽象成一份运维清单，每次部署新站点都过一遍，能避免百分之八九十的低级错误。

能不能写个脚本自动检测这些 403 问题

可以。保哥自己写过一个 PowerShell 巡检脚本，遍历所有站点，检查默认文档列表是否包含期望的入口文件、应用程序池是否处于运行状态、物理目录是否存在并且有正确的权限。如果发现异常会写到事件日志里，再配合监控平台告警。这种方法比临时救火主动得多，特别适合管理多个站点的团队。脚本核心逻辑大约 100 行，建议每天凌晨定时跑一次。

403 错误页面能不能自定义

能。在 IIS 管理器里选中站点，双击“错误页”，找到 403 那一行右键“编辑”，选“在此站点上执行 URL”并填入你的自定义页面路径。这样所有 403 错误都会显示你设计的友好页面，而不是 IIS 默认的红字英文页面。但注意不要在自定义页面里暴露太多系统信息（比如服务器路径、IIS 版本号），这些信息对攻击者有帮助。

如何完全禁止 IIS 暴露版本信息

有两层：第一层是 HTTP 响应头 Server 字段，可以在 web.config 里加<httpProtocol><customHeaders><remove name="Server"/></customHeaders></httpProtocol>移除。第二层是 X-Powered-By 字段，在 web.config 里加<customHeaders><remove name="X-Powered-By"/></customHeaders>。这两个操作组合可以让 IIS 在外部看起来像一个完全匿名的 Web 服务器，增加攻击者的侦察成本。