“Could not send request”表示请求未发出，主因是代理配置错误、URL缺协议头、SSL证书校验失败、服务器端口未开放或安全组限制；应依次检查Proxy设置、补全http/https、关闭SSL校验、验证云服务器安全组及本地防火墙。
“Could not send request” 不是 Postman 报错，而是请求根本没发出去 —— 它卡在了网络层或配置层，连 HTTP 状态码都收不到。
检查代理设置是否意外启用
这是 Windows/macOS 用户最常踩的坑：Postman 默认会继承系统代理，但一旦你装过 Fiddler、Charles 或某些国产“加速器”，系统代理可能被静默修改，而 Postman 仍照常尝试走它，结果连 DNS 都解析失败。
- 进
Settings → Proxy，确认Use the system proxy是否勾选；如果勾了，先关掉试试 - 若必须用代理，别选
System proxy，改用Custom proxy并填入明确地址和端口（比如127.0.0.1:8888） - 右下角出现红色感叹号？说明当前选中的代理不可达 —— 换成
Disable proxy或换一个 agent（如Browser Agent）
验证 URL 和协议是否被 silently 截断
Postman 对 URL 格式非常敏感。漏写 http:// 或 https:// 会导致它把整个字符串当本地路径处理，比如输 api.example.com/v1/login，实际发出的是 file:///api.example.com/v1/login，自然失败。
- 务必手动补全协议头：
https://api.example.com/v1/login - 如果域名含端口（如
localhost:8080），确保没被浏览器插件或 hosts 文件重定向 - 用 IP 直连测试（如
http://192.168.1.100:8080/api/test）可绕过 DNS 和证书问题，快速定位是域名解析还是服务本身的问题
排查 HTTPS 证书校验失败
自签名证书、过期证书、或企业内网中间人代理（如 Zscaler、Sangfor）都会触发 SSL Error: UNABLE_TO_VERIFY_LEAF_SIGNATURE，而 Postman 在 UI 上只显示模糊的 Could not send request。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 临时方案：进
Settings → SSL certificate verification关闭开关（仅限调试，勿用于生产环境） - 长期方案：把根证书导入系统信任库，或让 Postman 显式信任该证书（
Settings → Certificates → Add Certificate） - 注意：关闭 SSL 校验后，若仍失败，说明问题不在证书，而是更底层的连接问题（如防火墙、端口未开放）
确认目标服务端口对外可达
本地能 curl 通，Postman 却失败？大概率是服务器安全组或防火墙拦住了 Postman 的出向/入向流量 —— 尤其常见于云服务器（阿里云、腾讯云、AWS）。
- 检查云控制台「安全组」：入方向规则必须放行你的 API 端口（如
8080/tcp），且授权对象不能只写127.0.0.1，得是0.0.0.0/0或你的公网 IP 段 - Linux 服务器还需确认本机防火墙：
sudo firewall-cmd --list-ports，缺端口就加：sudo firewall-cmd --add-port=8080/tcp --permanent && sudo firewall-cmd --reload - Windows Server 则检查「高级安全 Windows 防火墙」入站规则，确认对应端口已启用
真正难排查的，往往是多层叠加问题：比如代理开着 + URL 少了 https + 服务器安全组没开 —— 这时候建议关掉所有非必要配置，从最简 http://httpbin.org/get 开始逐项加回，比盲猜高效得多。
