How to Test If Your Proxy Is Actually Working (Complete Checklist)

Configuring a proxy is only half the job. Without proper testing, you might believe your traffic is routed through the proxy when it is actually bypassing it entirely, leaking your real IP through DNS or WebRTC, or connecting through a different proxy than the one you intended.

This guide provides a comprehensive, step-by-step checklist for verifying that your proxy is functional, anonymous, and performing as expected. Whether you are setting up a new proxy for the first time or auditing an existing configuration, work through each section in order.

Phase 1: Basic Connectivity Test

Before testing anything else, confirm that your client can reach the proxy server and that the proxy can reach the internet.

Test 1: TCP Connectivity

# Verify the proxy port is reachable
nc -zv proxy.example.com 8080

Expected result: Connection to proxy.example.com 8080 port [tcp/*] succeeded!

If this fails, the issue is network connectivity, not proxy configuration. Check firewall rules, DNS resolution, and network routing.

Test 2: Proxy Authentication

# Test with credentials
curl -x http://user:pass@proxy.example.com:8080 -I https://httpbin.org/ip

Expected result: HTTP 200 response. If you get a 407, your credentials are incorrect.

Test 3: HTTP and HTTPS Through the Proxy

# HTTP request
curl -x http://user:pass@proxy:8080 http://httpbin.org/ip

# HTTPS request
curl -x http://user:pass@proxy:8080 https://httpbin.org/ip

Both should return a JSON response with an IP address that is not your real IP. If the HTTP test succeeds but HTTPS fails, the proxy may not support the CONNECT method for HTTPS tunneling.

Phase 2: IP Address Verification

The most fundamental proxy test: does the outside world see the proxy IP instead of your real IP?

Test 4: Check Your Apparent IP

# Through the proxy
curl -x http://user:pass@proxy:8080 https://httpbin.org/ip

# Direct (without proxy) for comparison
curl https://httpbin.org/ip

The IP addresses should be different. If they are the same, your traffic is not routing through the proxy.

Test 5: Verify with Multiple IP Check Services

Do not rely on a single service. Test with several:

for service in "https://httpbin.org/ip" "https://api.ipify.org" "https://ifconfig.me"; do
  echo "$service: $(curl -s -x http://user:pass@proxy:8080 $service)"
done

All services should report the same proxy IP. If results differ, some traffic may be leaking.

Test 6: Verify the Expected Proxy IP

If your proxy provider tells you which IP you should see, verify it matches:

EXPECTED_IP="123.45.67.89"
ACTUAL_IP=$(curl -s -x http://user:pass@proxy:8080 https://api.ipify.org)
if [ "$EXPECTED_IP" = "$ACTUAL_IP" ]; then
  echo "PASS: IP matches expected proxy IP"
else
  echo "FAIL: Expected $EXPECTED_IP but got $ACTUAL_IP"
fi

Phase 3: DNS Leak Testing

Even if your HTTP traffic routes through the proxy, DNS queries may leak through your local connection.

Test 7: DNS Leak Test

Visit a DNS leak test service through your proxy, or test from the command line:

# Start a packet capture for DNS traffic
sudo tcpdump -i any port 53 -nn &

# Make requests through the proxy
curl -x http://user:pass@proxy:8080 https://example.com

# Stop the capture
kill %1

If you see DNS queries in the capture, DNS is leaking outside the proxy tunnel. For SOCKS5 proxies, use the socks5h:// prefix to ensure remote DNS resolution.

Test 8: IPv6 DNS Leak

Even with IPv4 DNS properly proxied, IPv6 DNS queries may leak:

# Check for IPv6 connectivity
curl -6 https://api.ipify.org

If this returns an IP, your system has IPv6 connectivity that may bypass the proxy.

Phase 4: WebRTC Leak Testing

Test 9: WebRTC Leak Check

WebRTC can expose your real IP even when all HTTP traffic routes through the proxy. Visit a WebRTC leak test page through your proxy browser, or test programmatically.

If your real IP appears in WebRTC results, disable WebRTC in your browser settings or use a browser extension to prevent WebRTC leaks.

Phase 5: Geolocation Verification

Test 10: Verify Geographic Location

If you selected a specific geographic location for your proxy, verify it:

curl -s -x http://user:pass@proxy:8080 https://ipinfo.io | python3 -m json.tool

Check the city, region, and country fields. For mobile proxies, also verify the org field shows a mobile carrier name rather than a data center.

Test 11: Timezone Consistency

Advanced anti-fraud systems check if your browser’s timezone matches your IP’s geographic location:

// In browser console
console.log(Intl.DateTimeFormat().resolvedOptions().timeZone);

If your proxy is in New York but your browser reports Asia/Tokyo, the mismatch may flag your session.

Phase 6: Anonymity Level Testing

Test 12: Check Proxy Headers

Some proxies add headers that reveal you are using a proxy:

curl -x http://user:pass@proxy:8080 https://httpbin.org/headers

Look for these revealing headers in the response:

X-Forwarded-For – Contains your real IP
Via – Indicates proxy use
X-Real-IP – Contains your real IP
Proxy-Connection – Indicates proxy use

A high-anonymity (elite) proxy should not add any of these headers. If they appear, your proxy is transparent or anonymous but not elite. Review the proxy glossary for definitions of proxy anonymity levels.

Test 13: HTTP/2 and Protocol Support

curl -x http://user:pass@proxy:8080 --http2 -v https://httpbin.org/ip 2>&1 | grep "< HTTP"

Verify the proxy supports the HTTP versions your applications need.

Phase 7: Performance Testing

Test 14: Latency Measurement

curl -x http://user:pass@proxy:8080 -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://httpbin.org/ip

Compare these times with direct (non-proxy) requests. Reasonable overhead for a proxy is 50-200ms additional latency.

Test 15: Throughput Test

# Download speed through proxy
curl -x http://user:pass@proxy:8080 -o /dev/null -s -w "Speed: %{speed_download} bytes/sec\n" https://speed.hetzner.de/10MB.bin

Test 16: Concurrent Connection Test

# Test 10 concurrent requests
for i in $(seq 1 10); do
  curl -x http://user:pass@proxy:8080 -o /dev/null -s -w "$i: %{time_total}s %{http_code}\n" https://httpbin.org/ip &
done
wait

All requests should succeed. If some fail, the proxy may have concurrent connection limits.

Phase 8: Rotation and Session Testing

Test 17: IP Rotation Verification

For rotating proxies, verify that IPs actually rotate:

for i in $(seq 1 10); do
  echo "$i: $(curl -s -x http://user:pass@proxy:8080 https://api.ipify.org)"
  sleep 1
done

You should see different IPs across requests (unless you are using sticky sessions).

Test 18: Sticky Session Test

If using sticky sessions, verify the IP remains consistent:

for i in $(seq 1 10); do
  echo "$i: $(curl -s -x http://user:pass@sticky-proxy:8080 https://api.ipify.org)"
done

All requests should return the same IP for the duration of the sticky session.

Automated Testing Script

Combine all tests into a single script for repeated use:

#!/bin/bash
PROXY="http://user:pass@proxy:8080"
PASS=0
FAIL=0

run_test() {
  local name=$1
  local result=$2
  if [ "$result" = "PASS" ]; then
    echo "[PASS] $name"
    ((PASS++))
  else
    echo "[FAIL] $name"
    ((FAIL++))
  fi
}

# Test connectivity
NC_RESULT=$(nc -zv proxy.example.com 8080 2>&1 | grep -c "succeeded")
run_test "TCP Connectivity" "$([ $NC_RESULT -gt 0 ] && echo PASS || echo FAIL)"

# Test IP masking
REAL_IP=$(curl -s https://api.ipify.org)
PROXY_IP=$(curl -s -x $PROXY https://api.ipify.org)
run_test "IP Masking" "$([ "$REAL_IP" != "$PROXY_IP" ] && echo PASS || echo FAIL)"

echo ""
echo "Results: $PASS passed, $FAIL failed"

When to Retest

Run the full checklist:

After initial proxy setup
After changing proxy providers or plans
After OS or browser updates
After network environment changes
Weekly for production proxy configurations
After any proxy testing checklist item fails

Conclusion

A proxy is only useful if it actually works as intended. A partial configuration that routes HTTP traffic through the proxy but leaks DNS queries, WebRTC data, or reveals proxy headers is worse than no proxy at all because it creates a false sense of security. Work through every phase of this checklist, address any failures, and automate the testing process for ongoing verification. The 30 minutes invested in thorough testing prevents hours of debugging failed scraping jobs, banned accounts, or compromised research data.