No KYC — no ID, no selfie, no documents. Pay in crypto.
Language: English
Choose 1 GB

Status and connection checks

Troubleshoot the connection, the selected location or an order, and send support the details needed to investigate.

3 min read

Quick answer

How do I check a connection or report a service problem?

For a LocalSERP Proxy service issue, check the endpoint and protocol, verify the exit, compare a permitted target and send support a redacted report. These 4 checks help separate connection, location, order and crypto-payment questions. Reviewed 15 October 2026. No KYC applies; this page is a support guide rather than a live monitor.

Where can I check the affected component?

Review the relevant connection, payment or order in the client area, then record the last successful action and the first error you observed. Check a simple permitted IP service before testing the destination separately. If only one destination fails, include that distinction in your support report. This page provides the diagnosis sequence and contact routes; it does not publish a live component-health feed.

4 checks that narrow the problem

  1. Confirm the selected product and endpoint

    Read the endpoint in the client area and verify HTTP versus SOCKS5, username shape and selected location. Keep credentials out of screenshots. A dedicated port can have its own endpoint; do not replace it with a remembered example.

  2. Test the connection on an IP service

    Use a compatible browser or client to open a simple IP lookup. Record the exit address, time and lookup provider. A lookup response demonstrates that connection at that instant, without proving access to a different target.

  3. Compare the destination separately

    Visit only a destination you may access and record its own response and location label. Stop after a deliberate refusal. Repeated exit changes are not a diagnostic for a target asking you to stop.

  4. Send one useful report

    Include the timestamps, selected location, protocol, redacted error and outcomes of the first checks. Identify whether the problem concerns a top-up, an order, an exit or one target. Support can then review the relevant record.

How should I interpret authentication errors?

An authentication failure can come from a wrong username, password, endpoint or permitted connecting IP. Review the values shown for the product and any allowlist settings. Do not repeatedly guess credentials or disable the target’s TLS certificate verification. Use the how-it-works page and ask support when the same supported configuration still fails. Username and password on every plan, or an IP allowlist (up to 10 IPs). Sub-users with their own credentials and traffic cap. API keys you can revoke at any time. An error from the proxy stage and a refusal from the destination are different observations.

What if the IP lookup and requested place disagree?

Save the requested country, state, city or ZIP with the returned IP and database label. Retain the location shown by the destination too. Different labels alone do not establish a gateway outage. A selected city may have no suitable exit currently, and geolocation sources can differ. Ask support to review the example. If a broader location is acceptable for the test, record that change explicitly instead of continuing under the original city label.

What if a payment or order appears delayed?

Check the payment state and order state separately. A transfer must be reported, matched by its exact amount and confirmed before the balance is credited. A plan is then purchased from that balance. Keep the payment reference and available TXID, and contact support before sending again. This page makes no promised confirmation or crediting time. For an undelivered dedicated port or persistent service fault, the refund policy defines the relevant balance-credit rule.

What evidence should accompany an incident?

Record when the issue started, the last successful attempt you observed and whether it affects more than one permitted destination. Avoid turning a small sample into a success-rate or uptime claim. Note changes made during diagnosis, such as another endpoint, client or requested location. Send the report to [email protected]. Harmful traffic reports go to [email protected] with an exit IP and event time; do not send credentials with either kind of report.

How are service updates distinguished from measurements?

The changelog records changes to product wording, policies and documented methods. It is not an availability series. Current plans are on pricing, while sourcing states the attributed supply confirmation. If a dated incident notice is published, assess its scope and affected component rather than treating every page edit as an operational event. This distinction keeps a local audit based on the evidence you have, including interruptions during your own test.

1 GB $1.50 · no KYC

See pricing