Proxy Returns 406? Test Response Media Types Before Accepting a Wildcard 200

An authorized data client receives 406 through a proxy, while a browser opens the same address. Changing Accept to */* produces 200, but the JSON parser now receives HTML. That sequence has not repaired the integration. Diagnose the requested response representation, the endpoint contract and the actual returned payload before changing proxy exits. The procedure below is a controlled test plan, not a measured compatibility claim for 98IP or another service.

1. Define the response your task can actually consume

Record the intended endpoint, method, authorization scope, expected media type, parser and a minimal expected result. For a synthetic owned product fixture, require the agreed product ID, market and schema version as well as a parseable document. A successful login page is not a product response. Do not treat browser navigation to a human-facing page as the control for a different API route.

Accept describes response media types the client can consume. Request Content-Type describes a body you send; changing it on a bodyless GET does not request JSON. A 406 can reflect unsuccessful response negotiation, while 415 concerns the request representation. Other negotiation dimensions exist, including language and encoding; keep those fixed in this media-type investigation. Do not infer that an HTTP status alone identifies the generating layer.

2. Inspect the final merged header, not just your code snippet

1. Capture the effective Accept value at the client after shared defaults, SDK configuration and per-request overrides. Remove secrets from evidence.
2. Check whether a global application/json header was accidentally applied to a document, image or export route. Keep browser resource requests scoped to their own context.
3. Look for duplicate Accept fields or unexpected list merging. Establish which configuration layer owns the value and use one intentional definition.
4. Compare with the endpoint's documented response types. A vendor-specific JSON type is not automatically the same negotiated option as application/json merely because both can contain JSON syntax.
5. Record redirects and the final destination. A response from a login or error route does not prove the original API negotiated successfully.

A header visible in configuration can differ from what the receiver sees. On an owned staging endpoint, log the received Accept and a correlation ID without recording credentials. If the request never appears, use the owner's ingress evidence before attributing the failure to the proxy.

3. Run a four-case representation matrix

Use a read-only fixture and the same URL, cookies, region, method and session policy for every case. First choose a documented supported type; second request another documented type if available; third use a syntactically valid type the fixture deliberately does not provide; fourth try */* as a diagnostic control. Do not invent an unsupported negative case on a third-party endpoint without authorization.

For each case save the exact Accept, response status, response Content-Type, final route, parser outcome and expected fixture identity. Set a small request budget and run the same cases on an approved baseline and proxy path. If direct baseline access is unavailable, say so rather than claiming proxy causation.

The supported case should satisfy the documented contract. For the deliberately unsupported case, the owner may specify a 406 or a default representation: do not demand 406 from every server. A wildcard 200 only shows that some representation was returned. It becomes useful production behavior only if your consumer is designed and tested for that representation.

4. Interpret outcomes before choosing a fix

• Both paths reject the same narrow Accept: confirm the route and available representations with the owner. Do not rotate exits to solve an unsupported format.
• The client shows a supported value but the owned receiver observes another: investigate shared middleware, redirect rebuilding or explicitly configured interception using correlated evidence.
• The proxy path reaches a different final route: investigate authorization or regional routing first. Do not force the parser to accept the resulting webpage.
• Both paths return 200 but different Content-Type or fixture identity: fail the comparison and identify the variant rather than counting status-only success.

For ordinary HTTPS inside a non-intercepting CONNECT tunnel, the forward proxy cannot read or rewrite the encrypted inner Accept header. A response template or Server header alone is insufficient attribution. If an edge security rule uses 406 for a different policy, ask the owner for the specific rule and correlation evidence; this guide does not prescribe disguising requests to evade it.

5. Repair the consumer contract and retest reuse

Set endpoint-scoped Accept values for formats the consumer can handle. Use only the documented versioned route or vendor media type. If the application needs a genuine fallback, define separate parsers and semantic checks for each allowed type; never turn an HTML page into an empty successful JSON result.

Validate response Content-Type and decoded body together. Correct labels do not prove valid syntax or the expected schema. An error body may intentionally use a different type from the requested success representation, so handle its actual status and documented error format. Do not feed arbitrary failure payloads into the success parser.

On an owned endpoint with multiple representations, test the sequence structured data, document, structured data again through the normal cache path. Confirm each result's type and fixture identity, and have the owner review cache keys and Vary where negotiation selects the variant. A single isolated success does not demonstrate that shared caching preserves representation boundaries. Do not purge or alter third-party caches.

6. Where 98IP fits

Use the 98IP dynamic residential IP page when the task requires comparing authorized API behavior across selected customer regions. Obtain supported connection details through the 98IP configuration documentation and your account. Keep region and session policy stable during the header matrix and verify the observed egress.

A regional proxy can help reveal routing or representation differences; it does not add an unsupported API format or promise identical regional responses. No throughput, client compatibility or failed-request billing result has been measured here. Keep attempts bounded, check actual usage and collect only authorized synthetic or approved data.

7. Release checklist and FAQ

• The exact endpoint and accepted success media types are documented, with endpoint-scoped effective headers.
• Supported, alternate, unsupported and wildcard cases have explicit expected behavior and observed results.
• Status, final route, Content-Type, parsing and fixture identity all pass together.
• Errors remain errors, HTML is not silently treated as empty JSON, and cache reuse preserves the selected variant.
• Support evidence includes correlation IDs and sanitized headers, without tokens, cookies, proxy passwords or customer content.

Is */* a universal fix? No. It broadens negotiation and may select a representation your parser cannot use. Keep it as a controlled diagnostic unless all allowed results have a deliberate handling path.

Does application/* mean every JSON-based vendor format is interchangeable? No. A broad media range is a negotiation choice, not a promise about schema, version or parser support. Verify the actual agreed type and body.

Should I remove all headers to test? Change one relevant dimension at a time on an authorized fixture. Removing authorization, language and other state together destroys the comparison and can send you to a different resource.