Replay Proxy Requests Safely with Chrome DevTools 152

Chrome for Developers announced on 25 August 2026 that the Chrome 152 DevTools Network panel replaces the former Replay XHR action with Resend. The new action covers XHR and other fetchable requests, converts standard requests into fetch() calls, and preserves replay fidelity. DevTools also adds Base64, Hex, and UTF-8 views for binary or compressed request payloads.

Those changes make proxy troubleshooting faster, but a convenient replay button can also repeat a purchase, reuse an expired browser credential, or send a sensitive body into a debugging environment. A good test must preserve the network evidence while controlling side effects.

What request replay can prove

A controlled resend is useful when the original browser request failed with a proxy-related symptom such as:

• a 407 Proxy Authentication Required response;
• a connection or TLS failure before the destination answered;
• a region, ASN, or exit-IP mismatch;
• a 403, 429, or 5xx response that may come from the destination rather than the proxy;
• a malformed or compressed request body that an upstream service cannot parse;
• a request that works outside the browser but fails with browser headers, cookies, or origin rules.

Replay can show whether the same browser context produces the same outcome. It cannot, by itself, prove that the proxy is at fault. DevTools operates above several transport decisions, and a replayed fetch() can inherit cookies, service workers, connection reuse, DNS state, and browser policy from the current page.

Create a safe test boundary first

Before opening the Network panel, write down the allowed destination, test account, proxy gateway, region, and maximum request count. Prefer a staging endpoint or an idempotent read request.

Classify the request before replaying it:

If you cannot explain the side effect, do not click Resend.

Capture the original request without exposing secrets

Open DevTools, select Network, enable Preserve log only when navigation is required, and reproduce one authorized failure. Record the request number, UTC time, method, destination host, status, initiator, proxy region, and browser version.

Inspect headers and payload, but redact before copying or sharing:

• Authorization and Proxy-Authorization;
• cookies and anti-CSRF tokens;
• API keys, signed URLs, session IDs, and bearer tokens;
• email addresses, customer identifiers, and personal data;
• multipart file contents and binary bodies;
• internal hostnames that are not needed for the diagnosis.

Store a salted fingerprint of a token when you need to prove that two attempts used the same credential. Never paste the credential itself into tickets, chat, screenshots, or Airtable.

Build three controls

One replay is not a diagnosis. Prepare three comparable attempts:

1. Original control: the failed request in its original browser context.
2. Resend control: the same request replayed once with no intentional change.
3. Single-variable test: change exactly one approved factor, such as proxy region, proxy credential reference, timeout, or a non-secret application header.

Keep destination, method, body, browser profile, and test account constant unless one of them is the variable. If you change the proxy, user agent, cookies, and payload together, a successful response cannot identify the fix.

Resend the request in Chrome 152

Verify that the installed DevTools build shows Resend in the Network request context menu. Feature availability can differ by Chrome channel and enterprise rollout.

1. Filter the Network panel to the exact host and method.
2. Select the original request and note its request number and execution context.
3. Confirm the method and side-effect classification again.
4. Right-click and choose Resend once.
5. Do not start parallel resends; wait for the response or the defined timeout.
6. Compare status, remote address, timing phases, initiator, response headers, and response size.
7. Run the single-variable test only after the unchanged resend is recorded.

If the original request was not XHR, Chrome 152 may represent the resend as a fetch() call. Record that fact because the execution context and console originator are part of the evidence.

Inspect binary payloads without guessing

Chrome 152 adds Base64, Hex, and UTF-8 decoding choices to the request Payload tab for binary and compressed bodies. Choose the view that answers a specific question:

• Hex for magic bytes, separators, lengths, and unexpected byte changes;
• Base64 for a transport-safe comparison or a fingerprinting workflow;
• UTF-8 only when the payload is expected to contain valid text.

Do not assume that readable UTF-8 means the entire body is text. Do not alter compressed bytes and resend them unless the application team has provided an exact encoder and a duplicate-safe endpoint. For comparison, hash the original and replay payloads locally and record only the hash, byte length, content type, and encoding.

Separate proxy failures from destination failures

Use the following evidence matrix:

Never rotate IPs faster in response to a 429. A rate-limit response is a control signal, not permission to evade a destination limit.

Verify the actual route

A 200 response is not enough. Confirm that the resend used the intended route:

• expected proxy gateway and region;
• expected remote address or approved exit evidence;
• no direct fallback after proxy failure;
• correct DNS policy for the workflow;
• no unexpected service-worker interception;
• consistent certificate and TLS evidence;
• no credential copied into the page or console output.

When browser tooling cannot expose the complete proxy hop, correlate the request timestamp with sanitized proxy-side logs. Use a generated request ID that contains no customer data.

Define pass, fail, and inconclusive outcomes

Mark the test pass only when the expected response arrives through the verified proxy path and negative controls fail closed. Mark it fail when the same authorized request consistently breaks at an identified layer. Use inconclusive when browser state changed, the destination was unavailable, the route cannot be verified, or the replay mechanism changed behavior that matters.

Keep an evidence record with:

• browser and DevTools version;
• request number and UTC timestamps;
• redacted method, host, status, and timing summary;
• proxy gateway label, region, and route-verification result;
• original, unchanged resend, and single-variable outcomes;
• payload hash and byte length when relevant;
• side-effect review, owner, conclusion, and next action.

Release checklist

• [ ] The destination, test identity, proxy, region, and request limit are authorized.
• [ ] The request is idempotent or routed to a duplicate-safe sandbox.
• [ ] Credentials, cookies, tokens, personal data, and file bodies are redacted.
• [ ] The original request is captured before any change.
• [ ] An unchanged resend is compared before a single-variable test.
• [ ] No parallel resend or retry loop was created.
• [ ] 407, TLS, timeout, 403, 429, and application errors are attributed by layer.
• [ ] The proxy path and absence of direct fallback are verified.
• [ ] Binary comparisons retain hashes and lengths, not secret-bearing bodies.
• [ ] Pass, fail, or inconclusive status is supported by reproducible evidence.

For related diagnostics, use the 98IP guides on proxy 407 authentication failures, sanitizing proxy diagnostic archives, and separating proxy failures from target throttling.

FAQ

Does Resend reproduce the exact wire-level request?

Not necessarily. Chrome 152 expands replay by converting fetchable requests to fetch() calls. Browser connection reuse, generated headers, cookies, service workers, and policy can still affect the wire behavior. Treat replay as controlled browser evidence, not a byte-for-byte packet generator.

Can I resend a failed payment or order request once?

Not against production unless the application has an explicit idempotency mechanism and the test is authorized. Prefer a sandbox with a test identity and verify the idempotency key before replay.

Why did the resend succeed without changing the proxy?

The first attempt may have used an expired connection, cold DNS state, stale token, service-worker transition, or transient destination condition. Repeat only within the bounded plan and compare timing and execution context before concluding that the problem is fixed.

Should I export the binary payload for another engineer?

Only when policy allows it and the payload has been reviewed and sanitized. Usually a hash, byte length, content type, encoding, and minimal redacted excerpt provide safer evidence.

Compliance note

Replay only requests, accounts, proxies, destinations, and data you are authorized to test. Respect destination terms, privacy requirements, rate limits, consent rules, data-minimization policies, and regional law. Do not replay actions that can create duplicate transactions, expose credentials, generate invalid traffic, or bypass access controls.

Research note: Chrome for Developers, “What's new in DevTools (Chrome 152),” published 25 August 2026. The external research location is retained only in the internal operations record.