一、问题现象
在 Power Automate Desktop 中使用「调用 Web 服务」GET 请求访问内网接口时，HTTP 状态码 200 正常，但返回大量 HTML 网页源码，无法获取正常的 JSON 接口数据。
同时，浏览器手动输入同一 URL 可以正常返回接口数据，不存在地址错误、网络不通、接口故障问题。
二、问题根本原因
该问题由企业 Zscaler 安全网关拦截机制导致，核心原因如下：
1. 浏览器与 PAD 会话完全隔离 浏览器访问内网资源时已完成 Zscaler 登录认证，自带有效会话 Cookie； PAD 属于独立客户端，不会共享浏览器 Cookie 和登录状态，网关判定为未认证客户端。
2. 网关双重安全校验（Cookie + User-Agent） 企业 Zscaler 网关有严格安全策略：
- 无有效 Cookie → 判定为未登录，拦截请求
- UA 不是标准浏览器标识 → 判定为自动化脚本、爬虫程序，拒绝放行
PAD 默认请求头缺少浏览器 UA，会被网关识别为非可信客户端，直接返回登录 HTML 页面。
3. Accept 接收类型不匹配 PAD 默认请求头仅接收 XML 格式数据，接口返回 JSON 时会出现数据解析异常、内容错乱。
三、完整解决方案
1.获取浏览器有效 Cookie
浏览器打开目标接口 URL，确保能正常访问 2. F12 打开开发者工具 → 网络 → 刷新页面 3. 找到对应接口请求，复制请求头（Request Headers）中的完整 Cookie 字符串
2.添加标准浏览器 User-Agent 伪装客户端
在 PAD 自定义标头中添加：
作用：伪装成正规浏览器，绕过网关爬虫拦截策略。
3.填入有效登录 Cookie
自定义标头新增：
作用：向网关证明已完成身份登录认证。
4.修改 Accept 接收类型
将 Accept 改为通用匹配：
支持接收 JSON、文本、网页等所有数据格式，彻底解决格式不兼容问题。
四、原理总结
1. HTTP 200 状态码仅代表网络通信成功，不代表业务请求成功，网关拦截、跳转认证页依旧返回 200。
2. Cookie 是身份凭证，负责证明登录状态；User-Agent 是客户端标识，负责证明是人工浏览器访问。
3. 浏览器自带全套合法请求头，PAD 默认请求头极简，是造成两者访问结果不一致的根本原因。
4. 企业网关会双重校验「登录会话 + 客户端类型」，缺一不可。
五、最终效果
配置完成后，PAD 请求携带合法浏览器身份与登录凭证，Zscaler 网关正常放行，成功返回接口 JSON 业务数据，不再返回 HTML 认证页面。
