[{"data":1,"prerenderedAt":19},["ShallowReactive",2],{"blog:post:en:debugging-proxy-connection-timeouts-tcpdump-wireshark":3},{"slug":4,"lang":5,"title":6,"summary":7,"date":8,"tags":9,"tag_slugs":14,"thumbnail_url":15,"translations":16,"body":17,"asset_base":18},"debugging-proxy-connection-timeouts-tcpdump-wireshark","en","Debugging Proxy Connection Timeouts with tcpdump and Wireshark","Learn to isolate proxy timeout causes by capturing and analyzing traffic between your client, proxy, and origin server.","2026-10-23",[10,11,12,13],"proxy","debugging","networking","tcpdump",[10,11,12,13],"https://blog-api.ro-proxy.com/api/blog/posts/debugging-proxy-connection-timeouts-tcpdump-wireshark/thumbnail.svg?lang=en",[5],"## Why Proxy Timeouts Are Hard to Diagnose\n\nA proxy timeout rarely tells you where the failure happened. Your scraper sees a socket timeout, but the problem could live in your local network, the proxy provider’s exit node, the upstream origin, or even a DNS resolver inside the proxy’s network. Because the proxy sits in the middle, standard application logs often show only the final symptom: `ConnectTimeout` or `ReadTimeout`.\n\nTo fix it, you need packet-level visibility. Tools like `tcpdump` and Wireshark let you see the actual TCP handshake, TLS negotiation, and data flow. This guide walks through a repeatable method for diagnosing proxy connection timeouts, with examples for Python scrapers and commands you can run on Linux or macOS.\n\n## What You Need Before You Start\n\n- A machine with `tcpdump` installed (Linux) or available via Wireshark (macOS/Windows).\n- Shell access to the machine running your scraper or bot.\n- The proxy endpoint, port, and credentials you are debugging.\n- A reproducible test case: a single URL that consistently times out through the proxy.\n\nIf you are using a residential or ISP proxy, remember that exit IPs rotate. Pin the capture to one proxy session or IP so you do not mix traffic from different nodes.\n\n## Step 1: Reproduce the Timeout with a Minimal Client\n\nStart with the smallest possible client that fails. Remove retries, concurrency, and custom headers so the capture is easy to read.\n\nHere is a minimal Python script using `requests`:\n\n```python\nimport requests\n\nPROXY = \"http://user:pass@GATEWAY_HOST:HTTP_PORT\"\nTARGET = \"https://example.com\"\n\ntry:\n    resp = requests.get(\n        TARGET,\n        proxies={\"http\": PROXY, \"https\": PROXY},\n        timeout=(10, 10),\n    )\n    print(resp.status_code, resp.elapsed.total_seconds())\nexcept requests.exceptions.ProxyError as e:\n    print(\"ProxyError:\", e)\nexcept requests.exceptions.ConnectTimeout as e:\n    print(\"ConnectTimeout:\", e)\nexcept requests.exceptions.ReadTimeout as e:\n    print(\"ReadTimeout:\", e)\n```\n\nRun this until you reproduce the timeout. Note the exact timestamp. If it works locally but fails through the proxy, the issue is likely between your machine and the proxy, or between the proxy and the target.\n\n## Step 2: Capture Traffic with tcpdump\n\nRun `tcpdump` on the interface your traffic uses. If you are unsure, `ip route get \u003Ctarget-ip>` shows the outgoing interface.\n\n```bash\nsudo tcpdump -i any -n -s 0 -w proxy-timeout.pcap port 443 or port 10000\n```\n\nFlags explained:\n\n- `-i any`: capture on all interfaces.\n- `-n`: do not resolve hostnames; keeps IP addresses and ports readable.\n- `-s 0`: capture full packet payload, not just headers.\n- `-w proxy-timeout.pcap`: write to a file for Wireshark analysis.\n- `port 443 or port 10000`: capture HTTPS traffic and your proxy port. Adjust the port to match your proxy configuration.\n\nStart the capture, run your Python script, wait for the timeout, then stop `tcpdump` with `Ctrl+C`.\n\nIf you are on macOS and `tcpdump` requires elevated privileges, run it with `sudo` and enter your password.\n\n## Step 3: Filter and Inspect the Capture\n\nOpen `proxy-timeout.pcap` in Wireshark. Use display filters to isolate the conversation.\n\n```\nip.addr == \u003Cproxy-ip> && ip.addr == \u003Ctarget-ip>\ntcp.analysis.flags\ntcp.analysis.retransmission\n```\n\nLook for these patterns:\n\n1. **SYN sent, no SYN-ACK**: The client reaches the proxy or origin, but the other side never acknowledges. This points to a firewall, dropped packet, or dead proxy node.\n2. **SYN, SYN-ACK, then silence**: The TCP handshake completes, but the application never sends data. This often means a TLS handshake stall or an application-level hang at the proxy.\n3. **TLS Client Hello, no Server Hello**: The proxy connected to the origin, but TLS negotiation failed. Check SNI, ALPN, or certificate validation settings.\n4. **Data sent, duplicate ACKs, retransmissions**: Network congestion or packet loss between the proxy and the origin.\n\nFor quick command-line inspection, `tshark` is useful:\n\n```bash\ntshark -r proxy-timeout.pcap -Y \"tcp.analysis.retransmission\" -T fields -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport\n```\n\nThis lists retransmitted packets, which usually indicate an unhealthy path.\n\n## Step 4: Correlate Proxy Logs with Packet Captures\n\nPacket captures show what happened on the wire, but proxy logs explain why the provider dropped or delayed the request. Match the timestamp from Step 1 with your proxy provider’s dashboard or logs.\n\nCommon log entries to check:\n\n- `407 Proxy Authentication Required`: Your credentials are wrong or expired. The timeout may actually be authentication retries.\n- `502 Bad Gateway` or `504 Gateway Timeout`: The proxy could not reach the origin.\n- `429 Too Many Requests`: You are hitting the proxy provider’s rate limit, not the target site.\n- `connection_pool_exhausted`: All sticky sessions for that IP are in use.\n\nIf the capture shows a successful TCP handshake to the proxy but no response, and the proxy logs show `504`, the failure is between the proxy and the target. If the capture shows no SYN-ACK from the proxy, the failure is between your machine and the proxy.\n\n## Step 5: Common Patterns and Fixes\n\n### Proxy-to-origin TCP timeout\n\nWhen the proxy connects to your machine but stalls before reaching the origin, try a different proxy location or protocol. Residential proxies sometimes throttle long-lived connections to non-browser targets.\n\nFix: Switch from a sticky session to a rotating IP, or reduce the request rate to that specific geo.\n\n### DNS resolution delay at the proxy\n\nSome proxies resolve DNS on their side. If the proxy’s resolver is slow, your client sees a connect timeout even though the network is fine.\n\nFix: Use the target’s IP address directly if possible, or switch to a proxy provider with faster DNS in that region.\n\n### TLS handshake failure\n\nModern origins expect specific SNI and ALPN values. If your proxy strips or alters them, the origin drops the connection.\n\nFix: Verify your HTTP client sends the correct `Host` header and does not disable SNI. In Python, `requests` handles this automatically, but custom `urllib3` pool managers sometimes do not.\n\n### Exhausted proxy session pool\n\nSticky sessions bind you to one IP for a set duration. If you open more concurrent connections than the session allows, new requests queue and time out.\n\nFix: Lower concurrency, increase the sticky session duration, or rotate sessions more aggressively.\n\n## Step 6: Automate Timeout Detection in CI\n\nDo not wait for production scraping jobs to fail. Add a synthetic probe to your CI pipeline that runs the minimal client against a known URL through each proxy region you use.\n\nExample GitHub Actions step:\n\n```yaml\n- name: Proxy smoke test\n  run: |\n    python scripts/proxy_smoke_test.py \\\n      --proxy http://user:pass@GATEWAY_HOST:HTTP_PORT \\\n      --target https://example.com \\\n      --timeout 15\n```\n\nIf the script exits non-zero, fail the job and attach the `pcap` file as an artifact. Over time, this builds a baseline of normal latency per region and flags degradation early.\n\n## Checklist: Before You Escalate to Your Proxy Provider\n\n- [ ] Reproduced the timeout with a single-request script.\n- [ ] Captured packets with `tcpdump` during the failure.\n- [ ] Confirmed the TCP handshake reaches the proxy.\n- [ ] Checked provider logs for `502`, `504`, `429`, or auth errors.\n- [ ] Tested the same target without the proxy to rule out origin-side blocking.\n- [ ] Tried a different proxy location or rotation mode.\n\n## Conclusion\n\nProxy timeouts are frustrating because they hide the failure point behind an intermediary. By combining a minimal reproducible client, `tcpdump` packet captures, Wireshark filters, and provider logs, you can isolate whether the problem is local network, proxy-to-origin, or application-layer. Use the checklist above before opening a support ticket, and attach a `pcap` file so your provider’s engineering team can see the exact packets instead of guessing from your error message.\n","https://blog-api.ro-proxy.com/api/blog/posts/debugging-proxy-connection-timeouts-tcpdump-wireshark/assets",1792821466037]