How to evaluate a free proxy trial: exit IP, DNS, WebRTC and IPv6 checklist

Scope: what this checklist can verify

Prepare the client and a record sheet before claiming a free trial. After a successful claim, verify the protocol, port and authentication, check the HTTP exit in the same client, then test DNS, WebRTC and IPv6 against the intended routing. Fifteen minutes does not guarantee completion of the whole checklist. Mark anything untested as unverified; one successful check cannot stand in for the others. Read and prepare this complete acceptance and troubleshooting method before starting the short trial.

This checklist is for individuals and teams considering a static residential proxy, requesting a test endpoint or checking newly delivered connection details. It helps establish whether the proxy connects, authentication works and HTTP, DNS, WebRTC and IPv6 follow the agreed paths.

It cannot prove that an IP will never change, or establish its reputation, long-term success rate, account safety or guaranteed access to a particular platform from one test. Account status, client, device environment, regional policies and destination rules also affect access. Changing IPs does not replace investigating those factors.

PuppyIP's free trial is at https://puppyip.com/free-test and is subject to the site's customer and geographic restrictions. It serves compliant overseas businesses and their authorized personnel, is not offered in mainland China and must not be used within mainland China. Claiming requires login and depends on your eligibility and regional resource availability. Each account has one entitlement per region per Asia/Shanghai (Beijing time) calendar month; the 15 minutes start after successful confirmation. See the first-use guide in the sources for the claiming steps. This article does not claim to have obtained or tested a resource on your behalf.

Step 1: fix the conditions and create a test record

Before starting the short trial, install or open your intended client, locate its proxy fields, choose permitted neutral destinations and record the direct-connection exit and intended routing. Confirm the claim after preparing rather than looking for installers or menus during the countdown. Once claimed, check the countdown, protocol and corresponding port. Changing a URL prefix cannot enable an unsupported protocol.

Write down a routing agreement first: date and time, local network, proxy protocol, host, port, authentication method, target country or city, test client and destination URL. Specify which HTTP, DNS, WebRTC and IPv6 paths must use the proxy and which may intentionally connect directly. Redact usernames, passwords and complete proxy addresses, keeping only the fields needed to reproduce a problem.

Use the same record format for each run: check, expected result, actual result, duration, page status, exit IP, ASN/location, reconnection count and notes. At minimum, repeat checks on the same network and destination so changes in conditions are not mistaken for endpoint instability.

Step 2: check connection layers rather than only ping

Confirm that the proxy hostname resolves and that its host and port accept a TCP connection, then verify the supplied protocol and authentication fields. A 407 means the proxy requires authentication; check the username, password, allowlist and format before repeatedly refreshing the destination. If the format is unclear, read the Proxy Address Format Guide in the sources.

After authentication, check TLS and the destination response. For a 403 or429, first identify whether it comes from the proxy's CONNECT response or the destination, then check the relevant policy or rate limit. Do not hide certificate failures by disabling verification. See the 407, Timeout, DNS and TLS Troubleshooting Checklist for the complete layered method.

Step 3: verify the HTTP exit without treating it as complete acceptance

Query the HTTP exit before and after enabling the proxy using the same client and neutral destination, and confirm the configuration applies to the traffic being tested. Opening a page does not mean every application uses the proxy. System, browser and application-level proxy settings may cover different traffic.

If you need a consistent regional environment, check that the exit matches the required country, region and time zone in that same client. Do not repeatedly switch countries or cities merely to obtain a preferred database label; that changes the test conditions.

Step 4: check DNS, WebRTC and IPv6 with four separate results

Record expectations and results for four checks. The HTTP exit establishes the path of that client's HTTP request. DNS shows whether the destination name resolves locally or at the proxy. WebRTC ICE candidates show addresses browser real-time communications may expose. IPv6 checks reveal direct routes that remain outside an IPv4-only proxy. These checks establish different things; passing one does not replace the other three.

curl documents that socks5h:// resolves the destination hostname at the proxy, while socks5:// resolves it differently. The W3C WebRTC specification also notes that ICE candidate addresses can reveal location and local network topology and add fingerprinting information. Browser policies, extensions, system DNS, protocol support and the network stack affect results. Record observations rather than turning one testing site's result into a permanent anonymity guarantee.

During a limited trial, check basic connectivity and the HTTP exit first, then DNS, WebRTC and IPv6 as required for your use case. Record the expectation, result and time for each. Keep the network, client and endpoint unchanged, using only necessary, low-frequency, small-scale requests. Do not raise concurrency or repeatedly refresh to beat the countdown. If a tool cannot check an item, time runs out or a path remains unclear, mark it unverified and postpone logging into real accounts.

When curl, the browser and your application disagree

Do not log into a real account yet. On the same network and endpoint, record curl, browser and application HTTP exits, DNS, WebRTC and IPv6 results. Investigate the component that owns each configuration: curl arguments and environment variables, browser proxy and security settings, or an application's use of system proxies, built-in proxies or independent DNS. Avoid changing multiple clients at once.

Stop going live if any path required to use the proxy still connects directly, a tool requests production credentials, TLS or authentication still fails, or further verification requires real accounts. Correct the configuration and retest from the direct-connection baseline. Account eligibility, platform policies, device fingerprints and destination rate limits are outside the network-exit acceptance result.

An online checker may receive the proxy host, port and even username and password you paste into it. No registration, browser-session isolation or a completed test does not establish its logging, retention, sharing or deletion policies. Do not upload production credentials, complete proxy lists, real-account cookies, authorization headers or information linked to orders. A third-party marketing statement is not a verified privacy guarantee.

Before choosing a tool, check its operator, privacy policy, transport encryption, data uses, retention, deletion methods and supported protocols. Prefer a minimal local curl test or an explicitly authorized provider endpoint. If a third-party checker is necessary, use one dedicated test endpoint and short-lived credentials, and rotate or revoke them afterward where supported. Stop if it requires disabling TLS checks, bulk production uploads or cannot explain data handling.

PuppyIP's format converter processes text locally in the browser. Successful conversion means formatting completed; it does not verify the endpoint or password. Connectivity testing requires login and makes a basic server-side probe. That cannot prove your network, browser or application uses the same proxy, or replace local DNS, WebRTC and IPv6 checks. Record local formatting, server-side probing and actual-client results separately.

Step 5: cross-check ASN, location and residential classification

Use at least two public IP databases to record ASN, operator and location. Their update schedules, city granularity and classification rules differ. Keep conflicting results and query times, and ask the provider for verifiable clarification rather than choosing the most favorable label.

A reverse-DNS lookup, ping latency or one database label cannot independently prove residential status. Describe each result as the identification by database A/B on a particular date; dynamic data is not a permanent commitment.

Step 6: repeat connections and record stability

Within a fixed window, repeat connections and record successes, timeouts, authentication failures, TLS errors and destination statuses. Keep multiple latency results or percentiles rather than only the best run. With few samples, describe observations without estimating long-term stability.

Record the exit IP after every disconnect and reconnect. Static products aim for a relatively stable exit, which does not mean it is permanent. Before buying, confirm maintenance, renewal, replacement and refund rules, and the circumstances eligible for replacement.

PuppyIP trial bandwidth is limited and nodes may be shared by multiple valid trials. Short-trial speed does not represent a purchased IP's speed or long-term stability. The 15 minutes are your authorized window, not an exclusive IP. A few successful requests or an initialized page's100% online rate do not establish long-term stability.

Command example: test HTTP and SOCKS against the same destination

This example is for an already authorized test endpoint. Configure proxy-user = "YOUR_USER: YOUR_PASSWORD" in a local proxy-test.conf readable only by you; do not upload or share it when it contains real credentials. Replace proxy.example, the port and destination with actual values. Use curl.exe on Windows and curl on macOS or Linux. Check whether NO_PROXY bypasses the proxy for the destination and verify the actual exit as in step3.

HTTP proxy example: curl --config proxy-test.conf --proxy http://proxy.example: 3128 --connect-timeout 10 --max-time 30 --write-out " connect=%{http_connect} http=%{response_code} total=%{time_total}" https://example.com/

If the supplied endpoint explicitly supports SOCKS, replace the value after --proxy with socks5://proxy.example: 1080 or socks5h://proxy.example: 1080 in that command. They resolve destination names in different places in curl; see the Proxy Address Format Guide. Do not apply either protocol to a port that does not support it.

The10-second and30-second limits are troubleshooting bounds, not service-quality standards. Keep curl's original error and process exit code. A displayed000 when no HTTP response arrives is not a server-issued status. By default, curl may exit0 after successfully transferring a 403, 429 or5xx response, so inspect both the response and the application result.

Step 7: record request timing rather than treating ping as proxy performance

Choose test counts, times and destinations in advance based on business risk and written service terms, not an unsupported universal acceptable-latency threshold. For every request, save the time, environment, exit, response_code, http_connect, time_namelookup, time_connect, time_appconnect, time_starttransfer, time_total and exit code. curl timings are generally cumulative from the start of the request; each value is not the exclusive duration of that stage.

ping measures the ICMP path to the proxy host, not DNS resolution, connection, encryption and page retrieval through the proxy. --connect-timeout limits connection establishment and --max-time limits the whole transfer; either can return exit28. Recording the stage that exhausted its time is more useful than writing only timeout. Results vary with local network, region, time and destination and are not long-term performance promises by PuppyIP or any endpoint. Keep median, p95, success rate and error distribution for repeated runs under identical conditions, and show the sample count. A small-sample p95 does not represent long-term service.

Step 8: use three comparisons to locate timeouts and define stopping conditions

Make three small-scale comparisons within the same window: direct versus proxy access to one permitted destination, to find shared local-network or destination failures; one proxy accessing two permitted destinations, to identify destination maintenance, limits or account restrictions; and one destination through two authorized endpoints, to identify an individual endpoint problem. Keep client, protocol, region and request method consistent, and record DNS, connection, TLS, authentication, destination response and exit code separately.

For persistent407 responses, stop performance comparisons and fix authentication. For certificate-chain or hostname failures, stop and retain TLS evidence without disabling checks. If the destination reports maintenance, 403, 429 or insufficient account permission, stop attributing the result to the proxy. Start a new record when conditions change rather than combining results. Stop if further testing needs higher concurrency, more traffic or could violate third-party rules, and contact the provider or destination with redacted original records.

Record template and the next decision

Copy these fields: time and time zone | client and version | test network | protocol and authentication | destination URL | internal order or endpoint ID, if any | exit IP | database and query time | expected region | actual region | CONNECT status | destination HTTP status | exit code | total duration | exit before/after reconnecting | conclusion. Redact any version you share.

If configuration or authentication fails, correct the fields and retest; exclude those runs from performance comparisons. If only one destination refuses access, check its permissions, quota and frequency. If multiple destinations repeatedly fail at the same network layer, or the exit/location conflicts with confirmed delivery terms, retain evidence and contact support. Replacement and refunds follow written terms; one failure does not establish refund eligibility.

After purchasing a PuppyIP static residential proxy, copy the required format from the delivery page, open the usage tutorial on the right to configure it, and record connection, authentication, region and reconnection results. To view current products, use Visit the PuppyIP website on the right.

If observations conflict with delivery information, submit redacted test times, protocol, error type, destination, exit IP and multiple-source location results. Do not expose passwords, complete proxy addresses or authorization headers in tickets or screenshots.

For short trials, also record the test region, countdown or expiry status, and each of the four checks as expected, unexpected or unverified. You can keep this record without an order. When the countdown ends or the page says the trial has ended, disable the trial configuration in your client rather than relying on the connection. Refreshing, repeated clicking or revisiting the page does not reset that trial. Authorization expiry does not guarantee every existing connection closes within seconds. Keep unfinished checks unverified and continue only under new valid authorization and permitted conditions.