启用 directoryBrowse 后 403.14 更频繁，是因为它仅控制是否允许列目录，不解决权限或路径映射问题；根源从“功能禁用”变为“访问被拒”，需检查文件权限、web.config 继承、URL 授权及 applicationHost.config 的 overrideModeDefault 设置。
directoryBrowse 启用后 403.14 错误反而更频繁？
不是配置没生效，而是 directoryBrowse 只控制「是否允许列出目录内容」，不解决权限或路径映射问题。IIS 默认禁用目录浏览，启用后若物理路径不可读、或 web.config 被子目录继承覆盖，反而会暴露权限缺失——此时报的仍是 HTTP Error 403.14 - Forbidden，但根源已从「功能关闭」变成「访问被拒」。
实操建议：
- 确认目标目录的 Windows 文件权限：IIS_IUSRS 或应用池标识用户必须有「读取 & 列出文件夹内容」权限
- 检查是否有子目录下的
web.config覆盖了父级设置（尤其<system.webServer>节点被重复定义时） - 在 IIS 管理器中右键站点 →「浏览」能打开，但浏览器直接访问 URL 报错？说明是 URL 授权或请求筛选规则拦截，不是
directoryBrowse本身的问题
system.webServer 下的 directoryBrowse 配置项怎么写才有效？
必须放在 <system.webServer> 节点内，且只在站点或应用级别生效；虚拟目录不支持该配置。启用只需设 enabled="true"，但默认不显示文件大小和修改时间，得显式开启 showFlags。
常见写法：
<system.webServer> <directoryBrowse enabled="true" showFlags="Date, Time, Size, Extension" /> </system.webServer>
注意：
-
showFlags值是逗号分隔的字符串，不是布尔值；拼错（如写成size小写）会导致整个属性被忽略 - 如果同时启用了
customErrors或 URL 重写模块，可能拦截 403 响应并跳转，让目录浏览看起来“不生效” - IIS 10+ 支持
showFlags="All"，但老版本不识别，会退回到默认行为（仅显示文件名）
为什么本地 IIS Express 能浏览，部署到正式 IIS 就 404？
根本区别在于 IIS Express 默认启用目录浏览，而正式 IIS 安装时默认关闭，且多数服务器管理员会通过组策略或脚本全局禁用——这时即使你在 web.config 里写了 enabled="true"，也会被上级配置（applicationHost.config 中的 <section name="directoryBrowse" overrideModeDefault="Deny" />）拒绝。
解决路径：
- 进 IIS 管理器 → 选择服务器节点 →「配置编辑器」→ 打开
system.webServer/directoryBrowse→ 检查右上角「位置」是否为「Machine Config」，再看overrideModeDefault值 - 若为
Deny，需联系服务器管理员改applicationHost.config，或改用 IIS 管理器界面操作（功能视图 →「目录浏览」→「启用」） - 别依赖
web.config强行覆盖——IIS 会静默忽略，连警告日志都不记
开启 directoryBrowse 有哪些实际风险？
它会让所有未设默认文档（如 index.html）的目录直接暴露文件列表，包括备份文件（web.config.bak）、临时上传目录、甚至源码压缩包。攻击者不需要任何漏洞，只要猜到路径就能下载。
务必检查：
- 是否在生产环境意外启用（比如开发时加的配置没删）
- 敏感目录是否被排除：可在
<location path="Uploads">外层套一层禁用配置 - 是否配合了
<requestFiltering>屏蔽常见敏感扩展名（.config,.cs,.vb）——否则列表里点一下就 200 返回源码
最常被忽略的是：目录浏览开启后，OPTIONS 请求也会返回 200，某些扫描器靠这个批量发现可列目录——这和你有没有放默认页无关。
