Compare the exact IP reported by the same check service before and after the change. A website retaining your login, language or region is not evidence that the public IP stayed the same.

  1. Make a new request in the configured profile. Reload the checker or use its refresh control and request timestamp. A result from curl or another browser does not describe this profile.
  2. Confirm the active configuration. In Firefox, an address is used only under the corresponding manual mode; system, automatic and no-proxy modes select differently. For Chrome, inspect the system proxy or the flags on the actual running profile. A launch can reuse an existing process; a new dedicated user-data directory makes a separate flag-based test clearer. If an extension controls settings, inspect it.
  3. Check exclusions for the test URL. Manual bypasses, PAC results and system exceptions can leave one destination direct. Avoid localhost as the test: Chrome implicitly bypasses loopback and certain local addresses.
  4. Compare the right addresses. The configured listener and destination-observed exit can differ. If the reported address changed from your direct result but differs from the list entry, the proxy can still be working.

If direct and proxied results remain identical, try another endpoint with the same protocol from your service or the free proxy list and inspect a client trace for an attempt to reach the selected proxy. For Chrome, a NetLog capture can follow the route used by that request. A fresh request still working while that proxy is unreachable is a reason to investigate direct routing or fallback, rather than repeatedly editing the address.

Erthyglow kevrennek