How to prepare a support request so the issue can be checked quickly
The more precise the request, the faster it can be checked. “Does not work” does not show whether the problem is authentication, protocol, country, limits, software or target website.
Short answer
A good support request should make the issue reproducible. Include protocol, country, proxy type, test time, target site, exact error text and what you already tried.
What you should understand
- Specify plan and authentication mode: IP auth or username/password.
- Include an example host:port without exposing the password if the channel is not secure.
- List country, proxy type, blacklist filter, sticky/rotation and TTL.
- Add exact error text, test time, target website and screenshot/log.
What to include in the request
| What to send | Why it matters | Example |
|---|---|---|
| Protocol and format | so the connection can be reproduced | SOCKS5 or HTTP(S), host:port, auth method |
| Test time | so the event can be found in logs | 2026-07-04 18:20 UTC+3 |
| Target website | so the real workflow can be checked | domain or URL without private tokens |
| Error text | so support does not guess from a retelling | timeout, auth failed, connection refused, screenshot |
Details that make the request faster to check
| Setting | When it matters | What to keep in mind |
|---|---|---|
| Protocol and format | so support can reproduce the connection | include SOCKS5/HTTP(S), host, port and auth method |
| Time and timezone | so the event can be found in logs | write the exact test time |
| Target website | so the workflow can be checked | include the domain or page without private credentials |
| Error or screenshot | so nobody guesses from a retelling | send the exact error text but never expose passwords |
Practical check order
- Do not send only “it does not work”; describe one concrete test.
- Include protocol, country, proxy type, sticky/rotation mode and exact time.
- Check basic connectivity first, then the target website.
- If you send a screenshot, hide passwords and tokens but keep the error text visible.
Practical example
A good support request is a small test report. It should not expose passwords in an unsafe channel, but it should contain enough information to reproduce the issue. If the message includes country, protocol, mode, test time, target website and exact error text, support can check facts immediately instead of asking five clarification questions.