IIS托管Node.js应用时浏览器无法访问物理静态文件的咨询

优先排查应用端配置（本地IIS Express也可复现，说明与生产IIS环境无关） #

• 问题根因：Node应用的请求处理逻辑存在两处漏项，导致所有未匹配API路由的请求，都会被兜底逻辑捕获并返回根目录server.js的内容：
  • 未配置静态资源托管规则，无法识别/images/路径下的图片文件、RSS生成目录下的XML文件的返回逻辑
  • 兜底路由的返回逻辑配置错误，将不存在路径的响应指向server.js文件
• 修复操作：
  • 若使用Express框架开发，在所有API路由、兜底路由注册前，通过内置的express.static中间件配置静态托管规则：
    • 图片目录配置示例：app.use('/images', express.static(path.join(__dirname, 'images')))
    • RSS存储目录按相同逻辑追加匹配规则
    • *注意：静态托管中间件必须放在路由注册顺序的最前面，否则请求会先被兜底逻辑匹配，依然会返回server.js内容
  • 排查兜底路由的返回逻辑，禁止将兜底响应的文件路径指向server.js，常规业务场景下该位置应返回标准404状态码或提示页面
  • 若使用原生Node http模块开发，在请求处理逻辑的最开头增加判断：如果请求路径对应磁盘上存在的物理文件，直接读取文件内容、设置正确的MIME类型响应头返回，不进入后续API处理流程

修复IIS/IIS Express的反向代理规则 #

通过iisnode、ARR将Node应用挂载到IIS的场景中，如果URL重写规则配置漏项，会导致请求直接转发给Node进程，哪怕磁盘上存在对应的静态文件也不会优先返回。

• 修复核心逻辑：在站点根目录的web.config中调整URL重写规则，将“磁盘存在对应物理文件”的判断设为最高优先级：
  • 新增最高优先级规则：检查服务器变量{REQUEST_FILENAME}对应的物理路径，如果文件/文件夹实际存在，直接终止重写流程，由IIS直接处理静态文件返回
  • 配置次一级规则：将剩余未匹配到物理文件的请求，转发给Node应用入口（如server.js），由iisnode进程处理API请求
  • 排查现有配置：如果当前web.config仅配置了“所有请求一律重写到server.js”的单条规则，必然会出现静态文件无法正常访问的问题

校验静态文件访问权限 #

• 确认IIS站点对应的应用池身份账号，对应用下的images目录、RSS文件存储目录拥有读取权限，避免因权限不足导致IIS无法读取静态文件、将请求转发给Node进程的问题
• 可在目标目录的安全属性中，给IUSR账号、应用池对应的运行身份账号分配读取权限

满负载场景下的资源占用参考 #

基于Puppeteer、RSS Parser组合的应用，资源占用无固定通用值，按常规业务场景估算：

• 基础内存占用：Node进程本身稳定占用150MB-200MB；单启动一个Puppeteer控制的Chrome渲染实例，额外占用80MB-150MB
• 并发承载能力：1核2G规格的服务器，配置并发控制（限制最多同时启动3个Chrome渲染实例）时，可稳定承载每秒2-3次网页截图请求、每秒5-10次网页RSS解析请求
• 资源波动特征：截图请求触发Chrome全页面渲染时，CPU占用会短时冲高（可达70%以上）；RSS解析场景的CPU、内存占用均处于较低水平

各部署方案适配性对比 #

• 自有Windows Server（IIS托管）：已具备现成的多站点托管环境，无额外硬件采购成本，仅需按上述步骤调整应用和IIS配置即可上线，是当前投入成本最低的选型
• 专业Node.js托管服务商：适合未来有高并发承载需求、且不希望自行维护服务器配置的场景，这类服务无需自行配置反向代理、静态文件规则，但会产生持续的固定服务成本
• 升级现有Apache服务器：当前Apache剩余资源不足，升级硬件的投入远高于复用现有Windows Server环境的成本，无特殊业务需求不优先选择

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