本文探讨使用wiremock代理第三方api时，意外收到“javascript禁用”html响应的问题。文章揭示该问题源于将代理指向了需要javascript支持的前端门户而非实际api端点。教程将详细指导如何识别并配置正确的api代理地址，确保wiremock能准确记录和模拟后端api行为，避免常见的配置陷阱。
引言
WireMock作为一个强大的HTTP模拟服务，广泛应用于API开发和测试中，它能够记录、回放和模拟各种HTTP响应。在代理模式下，WireMock允许我们拦截并记录对真实服务的请求和响应，从而为后续的离线测试创建模拟桩。然而，在配置WireMock代理时，有时会遇到意想不到的问题，例如收到与预期API响应不符的HTML页面，甚至提示“JavaScript禁用”的错误信息。本文将深入分析这一常见问题的原因，并提供详细的解决方案。
问题描述：意外的HTML响应
当尝试使用WireMock代理一个第三方API时，用户可能会遇到以下现象：
-
直接调用第三方API： 向实际的第三方服务发出请求，例如：
curl -X GET "http://thrdpary.service.com/api/v2/requests/6396ff4eae78da7b0457f283" \ -H "authorization: Bearer mytoken" \ -H "accept: application/json"
此时会得到预期的JSON响应。
-
通过WireMock代理调用： 首先启动WireMock，并将其配置为代理目标服务：
java -jar ~/tools/wiremock/wiremock-jre8-standalone-2.35.0.jar --print-all-network-traffic \ --verbose \ --proxy-all https://thrdpary.service.com
然后，通过WireMock的本地端口发起请求：
立即学习“Java免费学习笔记（深入）”；
curl -X GET "http://127.0.0.1:8080/api/v2/requests/6396ff4eae78da7b0457f283" \ -H "authorization: Bearer mytoken" \ -H "accept: application/json" -H "Content-Type: application/json"
此时，收到的不再是JSON响应，而是一个HTML页面，其中包含类似“We're sorry but isp-portal doesn't work properly without JavaScript enabled. Please enable it to continue.”的错误信息。
WireMock的日志也会明确显示代理返回的Content-Type是text/html，而非预期的application/json：
Response: HTTP/1.1 200 server: [nginx] date: [Mon, 12 Dec 2022 13:18:40 GMT] content-type: [text/html] content-length: [3191] ...
这表明WireMock成功连接到了目标服务，但目标服务返回的却是前端页面的内容。
根源分析：代理目标误区
导致上述问题的原因在于WireMock的--proxy-all参数指向了一个前端Web门户（例如，一个需要浏览器渲染和JavaScript支持的用户界面），而不是实际提供API服务的后端API端点。
许多现代Web应用采用前后端分离架构，前端应用（如Vue、React、Angular构建的单页应用）和后端API服务可能部署在不同的子域名或路径下。例如，thrdpary.service.com可能是一个面向用户的Web界面，而api.thrdpary.service.com才是真正的API接口。
当WireMock代理到thrdpary.service.com时，它实际上是在请求该域名的根路径或默认页面，而这个页面通常会返回一个HTML文档，其中包含用于加载前端应用资源的
解决方案：精准定位API端点
解决此问题的关键在于识别并指定正确的API服务域名或子域名作为WireMock的代理目标。
在上述案例中，问题在于将--proxy-all指向了https://thrdpary.service.com，而正确的API端点实际上位于https://api.thrdpary.service.com。
因此，修正后的WireMock启动命令应为：
java -jar ~/tools/wiremock/wiremock-jre8-standalone-2.35.0.jar --print-all-network-traffic \ --verbose \ --proxy-all https://api.thrdpary.service.com
通过将--proxy-all参数的值从https://thrdpary.service.com更改为https://api.thrdpary.service.com，WireMock将直接代理到API服务，从而获取到预期的JSON响应，而不是前端HTML页面。
重要提示与最佳实践
HTTPS代理到HTTP的灵活性： WireMock支持将远程的HTTPS服务代理到本地的HTTP端口。这意味着即使第三方API使用HTTPS，你也可以通过本地的http://127.0.0.1:8080来访问它，WireMock会自动处理HTTPS到HTTP的转换。这在开发和测试环境中非常方便，无需额外的SSL证书配置。
-
验证API端点： 在设置WireMock代理之前，始终建议通过curl或其他HTTP客户端工具直接验证目标API端点。确保该端点返回的是预期的API响应（如JSON、XML），而不是HTML页面。这有助于提前发现代理目标配置错误。
例如，在配置WireMock之前，先尝试直接curl https://api.thrdpary.service.com/api/v2/requests/6396ff4eae78da7b0457f283，确认其返回JSON。
理解服务架构： 在进行API代理或模拟时，清晰地了解目标服务的架构至关重要。区分前端应用域名、后端API域名以及可能的静态资源域名，可以避免将代理错误地指向非API服务。
WireMock日志分析： 当遇到意外响应时，仔细检查WireMock的日志输出（特别是当使用--print-all-network-traffic和--verbose参数时）。日志中的Content-Type头部信息是判断代理是否命中正确服务类型（API vs. HTML）的关键线索。
总结
在使用WireMock进行API代理和记录时，收到“JavaScript禁用”的HTML响应是一个常见的配置错误。其根本原因在于将WireMock的--proxy-all参数指向了需要JavaScript支持的前端Web门户，而非实际的后端API端点。通过精准识别并配置正确的API服务域名，可以有效解决这一问题，确保WireMock能够准确地捕获和模拟API的真实行为。在未来的实践中，建议开发者在配置代理前，务必验证目标URL是否确实是API端点，并充分利用WireMock的详细日志进行故障排查。
