How to Debug SOAP Requests: Using Fiddler, Wireshark, and curl for XML Inspection

SOAP services fail silently, return cryptic XML faults, or behave differently than what the WSDL promises. Unlike REST APIs where you can quickly inspect JSON payloads in browser DevTools, SOAP debugging requires specialized tools to capture, read, and analyze XML envelopes wrapped in HTTP requests. This guide covers four essential tools for SOAP debugging and when to use each one.

Choosing the Right Tool

Before diving in, here's when to reach for each tool:

Debugging with curl

curl is the fastest way to send a SOAP request and inspect the raw response. No GUI, no setup — just a terminal.

Basic SOAP Request

curl -X POST https://api.example.com/OrderService \
  -H "Content-Type: text/xml; charset=utf-8" \
  -H "SOAPAction: http://example.com/GetOrder" \
  -d '<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:ord="http://example.com/orders">
  <soap:Header/>
  <soap:Body>
    <ord:GetOrder>
      <ord:OrderId>12345</ord:OrderId>
    </ord:GetOrder>
  </soap:Body>
</soap:Envelope>'

Seeing Full HTTP Headers

The -v flag shows the complete HTTP conversation, which is critical for diagnosing SOAPAction mismatches and content-type issues:

curl -v -X POST https://api.example.com/OrderService \
  -H "Content-Type: text/xml; charset=utf-8" \
  -H "SOAPAction: http://example.com/GetOrder" \
  -d @request.xml

Output includes both request and response headers:

> POST /OrderService HTTP/1.1
> Content-Type: text/xml; charset=utf-8
> SOAPAction: http://example.com/GetOrder
>
< HTTP/1.1 200 OK
< Content-Type: text/xml; charset=utf-8
< Content-Length: 847

Formatting the XML Response

SOAP responses are typically a wall of unformatted XML. Pipe through xmllint for readability:

curl -s -X POST https://api.example.com/OrderService \
  -H "Content-Type: text/xml; charset=utf-8" \
  -H "SOAPAction: http://example.com/GetOrder" \
  -d @request.xml | xmllint --format -

Saving Request and Response for Comparison

# Save response with HTTP headers
curl -v -X POST https://api.example.com/OrderService \
  -H "Content-Type: text/xml; charset=utf-8" \
  -H "SOAPAction: http://example.com/GetOrder" \
  -d @request.xml \
  -o response.xml \
  2> headers.txt

# Compare responses over time
diff <(xmllint --format response-before.xml) \
     <(xmllint --format response-after.xml)

SOAP 1.2 Differences

SOAP 1.2 changes the Content-Type and removes the SOAPAction header in favor of an action parameter:

# SOAP 1.1
curl -X POST https://api.example.com/Service \
  -H "Content-Type: text/xml; charset=utf-8" \
  -H "SOAPAction: http://example.com/DoSomething" \
  -d @request.xml

# SOAP 1.2
curl -X POST https://api.example.com/Service \
  -H "Content-Type: application/soap+xml; charset=utf-8; action=http://example.com/DoSomething" \
  -d @request.xml

Debugging with Fiddler

Fiddler acts as an HTTP proxy, capturing all traffic between your application and the SOAP service. It excels at inspecting production-like traffic from actual applications (not just manual requests).

Setup for SOAP Traffic

1. Install Fiddler Classic (Windows) or Fiddler Everywhere (cross-platform)
2. Configure your application to use Fiddler's proxy (default: 127.0.0.1:8888)
3. For Java applications, set the JVM proxy:

java -Dhttp.proxyHost=127.0.0.1 -Dhttp.proxyPort=8888 \
     -Dhttps.proxyHost=127.0.0.1 -Dhttps.proxyPort=8888 \
     -jar your-app.jar

For .NET, add to app.config:

<system.net>
  <defaultProxy>
    <proxy proxyaddress="http://127.0.0.1:8888" bypassonlocal="False"/>
  </defaultProxy>
</system.net>

Decrypting HTTPS Traffic

Most SOAP services use HTTPS. Fiddler can decrypt this traffic by acting as a man-in-the-middle proxy:

1. Go to Tools > Options > HTTPS
2. Check Decrypt HTTPS traffic
3. Trust the Fiddler root certificate when prompted
4. For Java apps, import Fiddler's certificate into the Java keystore:

# Export Fiddler's root certificate (from Fiddler: Tools > Options > HTTPS > Actions > Export Root Certificate)
keytool -import -trustcacerts -alias fiddler \
  -file FiddlerRoot.cer \
  -keystore "$JAVA_HOME/lib/security/cacerts" \
  -storepass changeit

Inspecting SOAP Envelopes in Fiddler

Once traffic is captured, select a session and use these inspectors:

• Raw tab: Full HTTP request/response including headers
• XML tab: Parsed and formatted SOAP envelope (easier to read)
• Headers tab: Check SOAPAction, Content-Type, authentication headers

Modifying and Replaying Requests

Fiddler's Composer tab lets you replay captured requests with modifications — invaluable for testing different parameter values or header combinations without changing application code.

1. Right-click a captured SOAP request
2. Select Replay > Reissue and Edit
3. Modify the SOAP body or headers
4. Execute and compare responses

Debugging with Wireshark

Wireshark operates at the network packet level, below HTTP. Use it when you need to diagnose TCP-level issues or when Fiddler's HTTP proxy approach isn't feasible (for example, with non-HTTP SOAP transports or embedded devices).

Capturing SOAP Traffic

1. Start Wireshark and select the correct network interface
2. Apply a capture filter to limit traffic:

# Filter by destination host
host api.example.com

# Filter by port
tcp port 8080

3. Apply a display filter after capture to isolate SOAP:

# Show only HTTP traffic containing SOAP
http contains "Envelope"

# Filter by specific endpoint
http.request.uri contains "OrderService"

# Show only SOAP faults
http contains "soap:Fault"

Analyzing TCP-Level Issues

Wireshark reveals problems invisible at the HTTP level:

• TCP retransmissions: Indicate network instability (filter: tcp.analysis.retransmission)
• RST packets: Connection was forcibly closed (filter: tcp.flags.reset == 1)
• Window size zero: Server or client buffer is full (filter: tcp.window_size == 0)

These TCP issues manifest as timeouts or intermittent failures in your SOAP client but are impossible to diagnose with HTTP-level tools alone.

Decrypting HTTPS in Wireshark

For HTTPS traffic, set the SSLKEYLOGFILE environment variable before starting your application:

# Linux/macOS
export SSLKEYLOGFILE=/tmp/ssl-keys.log

# Windows
set SSLKEYLOGFILE=C:\temp\ssl-keys.log

Then configure Wireshark:

1. Go to Edit > Preferences > Protocols > TLS
2. Set (Pre)-Master-Secret log filename to the path above
3. Restart capture — HTTPS traffic will be decrypted

Debugging with SoapUI

SoapUI is purpose-built for SOAP testing. It reads your WSDL, generates request templates, and validates responses against the schema.

Quick WSDL-Based Debugging

1. Create a new SOAP project and paste the WSDL URL
2. SoapUI generates request templates for every operation
3. Fill in parameters, send the request, and inspect the response

Key SoapUI Debugging Features

Raw message view: Shows the exact XML sent and received, including HTTP headers.

SOAP Fault analysis: SoapUI highlights SOAP faults and displays the fault code, string, and detail elements separately.

Assertion-based testing: Define expected values and get clear pass/fail results:

Contains Assertion: Response contains "OrderId"
XPath Match: //ord:Status = "Confirmed"
Not SOAP Fault: Response is not a SOAP fault

Mock services: Create a local mock of the SOAP service for testing without connecting to the real endpoint — useful for reproducing issues in isolation.

Common Debugging Patterns

Pattern 1: "The Server Did Not Recognize the HTTP Header SOAPAction"

Debug with curl:

# Check the WSDL for the correct SOAPAction
curl -s "https://api.example.com/Service?wsdl" | grep -i "soapaction"

# Test with the correct value
curl -v -X POST https://api.example.com/Service \
  -H "Content-Type: text/xml; charset=utf-8" \
  -H 'SOAPAction: "http://example.com/IService/GetOrder"' \
  -d @request.xml

Note the double quotes inside the SOAPAction header — some servers require them.

Pattern 2: Getting HTML Instead of XML

When you receive an HTML error page instead of a SOAP response:

# Check the Content-Type of the response
curl -v -X POST https://api.example.com/Service \
  -H "Content-Type: text/xml; charset=utf-8" \
  -d @request.xml 2>&1 | grep "< Content-Type"

# If you get text/html, you're likely hitting a load balancer or error page

Pattern 3: Intermittent Timeouts

Use Wireshark to check for TCP retransmissions:

tcp.analysis.retransmission && ip.addr == <service-ip>

If you see retransmissions, the issue is network-level, not application-level.

How SOAPless Helps

Debugging SOAP requests is hard because you're working with verbose XML, namespace-heavy envelopes, and opaque error messages. SOAPless reduces the need for this debugging by converting SOAP services to REST JSON APIs.

Instead of constructing XML envelopes and inspecting raw SOAP responses, you send and receive clean JSON. When something goes wrong, the error messages are JSON-formatted with clear error types and codes — no XML fault parsing required. You can test any operation directly in the SOAPless dashboard, which shows both the JSON request you send and the underlying SOAP XML that gets generated — giving you full visibility without needing Fiddler or Wireshark.

SOAPless also generates OpenAPI 3.0 documentation for every registered WSDL, so you can use standard REST tools like Postman or your browser's DevTools for debugging instead of specialized SOAP tooling.