三层架构下Web转App请求的SSL异常问题咨询

根据设计的架构安全规则，此类故障最常见的根因是Angular前端配置不当，将App服务器的直连地址硬编码为API基础路径，导致登录表单提交时，客户端浏览器直接向App服务器发起请求——这类请求既违反“所有请求必须由Web服务器发起”的管控要求，也会因为App服务器的访问控制策略被直接拦截，最终表现为接口无响应。

通过三层证据交叉验证即可明确来源，无需依赖主观判断：

• 查看App服务器的Windows防火墙入站日志，定位登录提交时间点附近的443端口连接记录：
• 如果连接源IP是客户端所在的办公网/公网IP段，说明请求确实是浏览器直接发起的，没有经过Web服务器中转
• 如果连接源IP是Web服务器的固定内网IP，说明请求路径符合设计要求，问题出在Web到App的传输链路本身
• 在App服务器的IIS站点开启W3C详细日志，核对对应请求的User-Agent字段：
• 如果记录的是Edge/IE的浏览器标识，就是客户端直连的请求
• 如果记录的是Web服务器反向代理的标识，才是正常的中转请求
• 在Web服务器上使用系统自带的pktmon工具抓取443端口的出站流量，定位登录提交时间点，看Web服务器有没有实际向App服务器发起对应的API请求：如果时间点完全匹配不到对应流量，100%是前端把请求直接发去了App服务器，没走Web。

场景1：确认请求为浏览器直连App服务器（占此类故障的90%以上） #

• 调整Angular前端的API配置，把所有API请求的基础路径改为和Web站点同源的相对路径（例如所有API请求都以/api作为前缀），确保浏览器发起的所有请求第一目标都是Web服务器，不会直接指向App服务器
• 在Web服务器的IIS上安装URL Rewrite和Application Request Routing组件，配置反向代理规则，将所有匹配/api路径的请求，完整透传转发到App服务器的443端口，配置时注意：
• 转发到App服务器的HTTPS请求要使用已部署的自签名证书完成身份校验，不要降级为HTTP明文传输
• 反向代理配置要保留原始请求的认证头、请求体，不要截断提交的登录表单数据
• 在App服务器的Windows防火墙配置入站规则，对443端口只放通Web服务器的内网IP，直接拒绝所有其他来源的连接，从网络层彻底阻断客户端浏览器直连App的可能

场景2：确认请求已经由Web服务器发起，但App无响应 #

• 排查SSL链路信任问题：检查Web服务器的本地证书存储，有没有将App服务器的自签名根证书导入到受信任的根证书颁发机构目录，避免IIS反向代理转发HTTPS请求时因为证书信任校验失败导致连接握手中断
• 核对App服务器的IIS站点配置：检查443端口的站点绑定主机名，确保和Web服务器反向代理转发时携带的Host头完全匹配，避免站点因为主机名不匹配返回403、404错误
• 排查链路拦截问题：检查Web服务器的出站防火墙规则，确认443端口到App服务器的流量没有被拦截；同时确认两端没有第三方终端安全软件拦截443端口的正常通信
• 清理冗余CORS配置：如果之前调试阶段为了临时打通浏览器直连，在App服务器上添加了允许客户端跨域访问的规则，现在切回Web反向代理的模式后，需要将这些冗余规则移除，避免触发安全策略冲突

• 在客户端浏览器打开F12开发者工具的网络面板，提交登录请求时确认所有请求的目标地址都是Web服务器的域名/IP，不会出现指向App服务器的请求
• 在App服务器上持续监控443端口的连接源IP，只要出现非Web服务器IP的连接，立刻排查是否有配置遗漏

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