我之前在项目里刚好碰到过这个问题，确实configSource属性在customHeaders这个层级不被支持，挺头疼的。不过除了启动时用代码加载，还有几个非代码的方案可以解决，给你梳理一下：

方案1：分离整个httpProtocol节点到外部文件 #

虽然customHeaders本身不支持configSource，但它的父节点httpProtocol是支持这个属性的。你可以把整个httpProtocol节点迁移到单独的配置文件，比如httpProtocol.config，然后在主Web.config里引用它：

主Web.config中的配置：

<system.webServer>
  <!-- 引用外部的httpProtocol配置文件 -->
  <httpProtocol configSource="httpProtocol.config" />
  <!-- 保留system.webServer下的其他配置项 -->
  <modules>...</modules>
  <handlers>...</handlers>
</system.webServer>

httpProtocol.config的内容：

<httpProtocol>
  <customHeaders>
    <!-- 这里放你的所有自定义头配置 -->
    <add name="X-Frame-Options" value="SAMEORIGIN" />
    <add name="X-Content-Type-Options" value="nosniff" />
    <add name="Strict-Transport-Security" value="max-age=31536000" />
  </customHeaders>
</httpProtocol>

这个方案的唯一小缺点是需要把整个httpProtocol的配置都移出去，但如果这部分配置不多，算是最简单直接的解决办法。

方案2：利用IIS的分布式配置能力 #

如果你是在IIS 7及以上环境部署应用，可以借助IIS管理器的配置工具来实现分离：

• 打开IIS管理器，选中你的目标站点
• 双击「Configuration Editor」，在顶部的「Section」下拉菜单中找到system.webServer/httpProtocol/customHeaders
• 点击右侧的「Feature Delegation」，确保该配置节的权限设置为「Read/Write」（这样站点级可以独立配置）
• 点击「Export Configuration」，将当前的customHeaders配置导出到一个外部文件（比如customHeaders.config）
• 完成后回到主Web.config，你会发现IIS已经自动帮你生成了对应的引用逻辑

这个方案依赖IIS的配置系统，如果你是在非IIS环境（比如Kestrel）运行应用，可能就不适用了。

额外小技巧：全局配置（适合通用头） #

如果你的自定义头是所有站点都需要的通用配置，可以直接在服务器级的applicationHost.config中设置，这样所有站点都会自动继承这部分配置，不用每个应用单独处理。不过这不是应用级的分离，适合全局统一管控的场景。

内容的提问来源于stack exchange，提问作者HardLuck