我来帮你梳理几个在测试环境里常用的方案，解决你用Fiddler没抓到内部服务请求的问题：

• 检查服务配置文件
  ASMX服务的依赖地址通常会配置在web.config（服务端）或者调用方的配置文件里。你可以找一下customer.asmx所在项目的web.config，看看有没有类似<appSettings>里的URL配置项，或者<system.web.services>、<system.serviceModel>节点下的服务引用端点配置，直接就能找到reports.asmx和catalogue.asmx的完整地址。如果是动态读取配置（比如从数据库或配置中心拉取），那得顺着代码里的配置加载逻辑找对应的存储位置。

• 启用服务端日志输出
  要是能修改服务端代码或者配置，给customer.asmx的A()方法加个日志：在调用reports.asmx之前，把目标URL写入日志文件（比如用File.WriteLine或者日志框架输出）。或者在reports.asmx的服务端配置里开启请求日志，这样每次被调用时都会记录自身的请求地址和调用来源，能反向推导出它的完整URL。

• 调整Fiddler的监听策略
  Fiddler抓不到内部调用，大概率是因为服务之间走的是内网IP或者本地回环（比如localhost），且没有走Fiddler代理。你可以尝试：

  1. 在customer.asmx的代码里，给reports服务对象设置代理：reportsService.Proxy = new WebProxy("http://localhost:8888");（8888是Fiddler默认端口）
  2. 或者修改测试环境的系统代理，让所有HTTP请求都走Fiddler，这样内网服务之间的调用也会被捕获。

• 用调试器直接查看
  如果测试环境允许远程调试，把调试器附加到customer.asmx所在的IIS进程（w3wp.exe），然后在A()方法调用reports服务的位置打个断点。运行到断点时，查看reports服务实例的Url属性，就能直接拿到完整地址了。要是能拿到代码在本地调试，这个方法最直观。

• 借助网络监控工具
  如果有权限的话，找运维同事帮忙，在customer.asmx所在的服务器上用网络监控工具（比如Wireshark、Windows自带的网络监视器）筛选HTTP请求，找从该服务器发出的、指向其他ASMX服务的请求，就能提取出目标URL。

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