{"name":"MiProxy public documentation","updatedAt":"2026-10-17","retrieval":"Deterministic lexical retrieval of public documents; no embeddings or generated answers","environment":"public documentation","documents":[{"id":"proxy-error-407","path":"/guides/proxy-error-407","url":"https://miproxy.io/guides/proxy-error-407","title":"Fix HTTP 407 Proxy Authentication Required","description":"Diagnose proxy authentication errors by checking credentials, gateway details, escaping and allowlists without disabling TLS verification.","category":"guide","updatedAt":"2026-10-17","chunks":[{"id":"proxy-error-407-answer","heading":"Quick answer","text":"HTTP 407 means the proxy requires acceptable authentication. Check the proxy username and password, authentication method and gateway first. It is different from HTTP 401 at the destination and does not prove the destination blocked your exit."},{"id":"proxy-error-407-introduction","heading":"Introduction","text":"HTTP 407 means the proxy is asking for valid proxy authentication. It is a useful diagnostic boundary: a password for the destination website, an unrelated routing setting or a new exit IP does not automatically satisfy the gateway’s challenge.\n\nWork from the observed response toward the configuration. This guide separates credentials, authentication method, URL encoding and other network failures so that one change at a time has a clear purpose."},{"id":"proxy-error-407-disclosure","heading":"Editorial disclosure","text":"Protocol meanings come from the linked primary references. This is not a claim that every application surfaces proxy errors identically. No live failure injection or current production MiProxy authentication test was performed for the article."},{"id":"proxy-error-407-methodology","heading":"How this guide was researched","text":"Troubleshooting guidance grounded in RFC 9110 and official cURL authentication documentation. The direct 407 questions are preserved from saved SERP research; the diagnostic sequence is editorial interpretation of the protocol.\n\n- Proxy challenge versus destination authentication.\n\n- Correct allocation credentials, gateway and supported method.\n\n- Client configuration and credential-component parsing.\n\n- Evidence needed to distinguish a resolved authentication issue from a new failure."},{"id":"proxy-error-407-meaning","heading":"Identify which server rejected the request","text":"A proxy sits between the client and destination. Its credentials are separate from destination credentials and often separate from your dashboard login. A 407 can occur while opening an HTTPS CONNECT tunnel, before any destination page is returned.\n\nClient libraries may expose a failed tunnel as a connection exception. Read the sanitized error category rather than assuming every failure produces a response object with a status field."},{"id":"proxy-error-407-checks","heading":"Check these settings in order","text":"Change one setting at a time so the result is attributable. Begin with the minimal cURL request in the connection guide.\n\n- Copy the exact gateway hostname, protocol and port for the allocation.\n\n- Use proxy credentials, not your email address or dashboard password.\n\n- Remove accidental whitespace and confirm credentials are active.\n\n- When using a URL, encode username and password components correctly.\n\n- If using IP allowlisting, verify the current public egress IP and the product’s supported method.\n\n- Remove undocumented location or session suffixes and reintroduce supported settings one at a time."},{"id":"proxy-error-407-retest","heading":"Run one diagnostic request","text":"Use a known permitted destination and a short timeout. In cURL, --proxy-user with only the username prompts for the password. In Requests, keep credentials outside source code and configure both destination scheme keys.\n\nDo not retry a known bad credential in a tight loop. If the result changes to a TLS failure, timeout or destination status, diagnose that new layer separately. Keep certificate verification enabled throughout."},{"id":"proxy-error-407-407-boundary","heading":"Identify who sent the challenge","text":"A 407 response concerns the proxy’s authentication boundary. The Proxy-Authenticate header describes its challenge. A 401 response concerns authentication to the requested resource. The credentials and client options used at those boundaries are not interchangeable."},{"id":"proxy-error-407-407-boundary-407-visible-response","heading":"Identify who sent the challenge: Preserve the exact symptom","text":"Record whether you observed an HTTP status from the proxy, a library exception wrapping that status, or only a timeout. Capture the challenge header where available, after removing secrets and unrelated identifiers. A generic application message such as connection failed is not enough to conclude that the gateway rejected a password."},{"id":"proxy-error-407-407-boundary-407-first-check","heading":"Identify who sent the challenge: Check the active allocation before editing code","text":"Confirm the gateway hostname, port, username and supported authentication method from the active allocation. Account-login credentials may be different. If a credential has been rotated or an allocation disabled, an older local copy can be structurally correct yet no longer usable."},{"id":"proxy-error-407-407-format","heading":"Distinguish a wrong value from a malformed value","text":"Credentials can be valid in a dashboard but incorrectly supplied to the client. A password containing URL separators needs component encoding when placed in a URL. A separate authentication option follows that client’s own argument rules. Keep the format and the underlying value distinct during diagnosis."},{"id":"proxy-error-407-407-format-407-encoding","heading":"Distinguish a wrong value from a malformed value: Make one formatting change","text":"Choose one documented credential format and test it with the same bounded request. Avoid simultaneously changing the gateway, password, port and client. If the next result differs, that controlled change gives you a better clue about which boundary was wrong."},{"id":"proxy-error-407-407-format-407-method","heading":"Distinguish a wrong value from a malformed value: Read the documented authentication method","text":"A username and password do not specify every detail of how a client authenticates. Use the method the gateway documents and the option your client supports. Do not add an unrelated destination Authorization header and assume it satisfies a proxy challenge."},{"id":"proxy-error-407-407-checklist","heading":"Use a small diagnostic loop","text":"Begin with one permitted request and explicit timeouts. Keep destination TLS verification enabled. Review the resulting status or exception and change one relevant configuration item. Repeated attempts with the same incorrect setup add noise rather than evidence."},{"id":"proxy-error-407-407-checklist-tradeoffs","heading":"Use a small diagnostic loop: tradeoffs","text":"### Where it helps\n\n- A specific status gives a clearer starting point than a generic connection failure.\n\n- A bounded request and sanitized configuration make support evidence reproducible.\n\n- Separating proxy and destination credentials avoids changing the wrong system.\n\n### What to account for\n\n- Some clients wrap the challenge in an exception that needs inspection.\n\n- A corrected 407 can expose an unrelated DNS, TLS or destination issue next.\n\n- A diagnostic trace can reveal credentials unless reviewed before sharing."},{"id":"proxy-error-407-407-escalate","heading":"When to ask for help","text":"If the documented settings still produce 407, send the provider a concise sanitized record: time, active product category, client/version, gateway host and port, selected authentication method, response status and challenge details. Share account or allocation identifiers only through the appropriate support channel."},{"id":"proxy-error-407-407-escalate-407-new-error","heading":"When to ask for help: Treat a new result as new evidence","text":"If the request changes from 407 to a destination response, the authentication boundary may now be satisfied. Confirm that interpretation rather than repeatedly rotating credentials. A destination 403, 429 or unexpected page requires its own diagnosis and access-policy review."},{"id":"proxy-error-407-407-escalate-407-sensitive-data","heading":"When to ask for help: Keep the support record safe","text":"Do not include the literal password, a full credential-bearing proxy URL, session cookies or a private destination query. A useful record shows the request structure and observed boundary without giving another reader the ability to reuse the allocation."},{"id":"proxy-error-407-support","heading":"Send support a useful, sanitized report","text":"Include the allocation or order identifier, timestamp with timezone, client version, gateway host and port, and the exact error category. Say whether the failure is consistent and whether another permitted endpoint behaves the same way.\n\nRemove passwords, tokens, cookies and full credential-bearing URLs from traces. First confirm that your allocation is active and that you are using its current gateway, port and credentials. This article explains the protocol; it is not a guarantee that every authentication failure has the same cause."},{"id":"proxy-error-407-article-verdict","heading":"Which approach should you choose?","text":"Fix the authentication boundary first, then reclassify the next result. A changed error can mean you have moved to a different stage of the connection.\n\n### A clear 407 response\n\nInspect the proxy challenge and verify gateway credentials and the client’s proxy-authentication configuration.\n\n### A timeout or TLS error\n\nDiagnose connection establishment or certificate trust separately; do not assume every proxy failure is 407.\n\n### Authentication succeeds but output is wrong\n\nValidate the destination response and access conditions instead of changing a now-working password."},{"id":"proxy-error-407-faq-1","heading":"What does 407 Proxy Authentication Required mean?","text":"The proxy did not receive valid authentication for the request. Its Proxy-Authenticate response header describes the authentication challenge. Check proxy credentials and authentication configuration separately from credentials for the destination website."},{"id":"proxy-error-407-faq-2","heading":"How to fix error 407 Proxy Authentication Required?","text":"Check the exact gateway, port, active proxy credentials and supported authentication method. Make sure your client sends proxy authentication; encode credential components when using a URL. Retest one permitted request with a timeout. If the error changes, diagnose the new network or destination failure separately."},{"id":"proxy-error-407-faq-3","heading":"Is 407 the same as 401?","text":"No. 407 concerns authentication to the proxy. 401 concerns authentication to the requested resource."},{"id":"proxy-error-407-faq-4","heading":"Will rotating the IP fix bad credentials?","text":"Changing an exit does not repair incorrect gateway authentication. Verify the credentials and supported authentication method first."},{"id":"proxy-error-407-faq-5","heading":"Which response header describes the proxy authentication challenge?","text":"Proxy-Authenticate describes the challenge associated with a 407 response. Inspect it where your client makes it available, and distinguish the proxy’s authentication method from destination authentication."}],"text":"# Fix HTTP 407 Proxy Authentication Required\n\nDiagnose proxy authentication errors by checking credentials, gateway details, escaping and allowlists without disabling TLS verification.\n\n## Quick answer\n\nHTTP 407 means the proxy requires acceptable authentication. Check the proxy username and password, authentication method and gateway first. It is different from HTTP 401 at the destination and does not prove the destination blocked your exit.\n\n## Introduction\n\nHTTP 407 means the proxy is asking for valid proxy authentication. It is a useful diagnostic boundary: a password for the destination website, an unrelated routing setting or a new exit IP does not automatically satisfy the gateway’s challenge.\n\nWork from the observed response toward the configuration. This guide separates credentials, authentication method, URL encoding and other network failures so that one change at a time has a clear purpose.\n\n## Editorial disclosure\n\nProtocol meanings come from the linked primary references. This is not a claim that every application surfaces proxy errors identically. No live failure injection or current production MiProxy authentication test was performed for the article.\n\n## How this guide was researched\n\nTroubleshooting guidance grounded in RFC 9110 and official cURL authentication documentation. The direct 407 questions are preserved from saved SERP research; the diagnostic sequence is editorial interpretation of the protocol.\n\n- Proxy challenge versus destination authentication.\n\n- Correct allocation credentials, gateway and supported method.\n\n- Client configuration and credential-component parsing.\n\n- Evidence needed to distinguish a resolved authentication issue from a new failure.\n\n## Identify which server rejected the request\n\nA proxy sits between the client and destination. Its credentials are separate from destination credentials and often separate from your dashboard login. A 407 can occur while opening an HTTPS CONNECT tunnel, before any destination page is returned.\n\nClient libraries may expose a failed tunnel as a connection exception. Read the sanitized error category rather than assuming every failure produces a response object with a status field.\n\n## Check these settings in order\n\nChange one setting at a time so the result is attributable. Begin with the minimal cURL request in the connection guide.\n\n- Copy the exact gateway hostname, protocol and port for the allocation.\n\n- Use proxy credentials, not your email address or dashboard password.\n\n- Remove accidental whitespace and confirm credentials are active.\n\n- When using a URL, encode username and password components correctly.\n\n- If using IP allowlisting, verify the current public egress IP and the product’s supported method.\n\n- Remove undocumented location or session suffixes and reintroduce supported settings one at a time.\n\n## Run one diagnostic request\n\nUse a known permitted destination and a short timeout. In cURL, --proxy-user with only the username prompts for the password. In Requests, keep credentials outside source code and configure both destination scheme keys.\n\nDo not retry a known bad credential in a tight loop. If the result changes to a TLS failure, timeout or destination status, diagnose that new layer separately. Keep certificate verification enabled throughout.\n\n## Identify who sent the challenge\n\nA 407 response concerns the proxy’s authentication boundary. The Proxy-Authenticate header describes its challenge. A 401 response concerns authentication to the requested resource. The credentials and client options used at those boundaries are not interchangeable.\n\n## Identify who sent the challenge: Preserve the exact symptom\n\nRecord whether you observed an HTTP status from the proxy, a library exception wrapping that status, or only a timeout. Capture the challenge header where available, after removing secrets and unrelated identifiers. A generic application message such as connection failed is not enough to conclude that the gateway rejected a password.\n\n## Identify who sent the challenge: Check the active allocation before editing code\n\nConfirm the gateway hostname, port, username and supported authentication method from the active allocation. Account-login credentials may be different. If a credential has been rotated or an allocation disabled, an older local copy can be structurally correct yet no longer usable.\n\n## Distinguish a wrong value from a malformed value\n\nCredentials can be valid in a dashboard but incorrectly supplied to the client. A password containing URL separators needs component encoding when placed in a URL. A separate authentication option follows that client’s own argument rules. Keep the format and the underlying value distinct during diagnosis.\n\n## Distinguish a wrong value from a malformed value: Make one formatting change\n\nChoose one documented credential format and test it with the same bounded request. Avoid simultaneously changing the gateway, password, port and client. If the next result differs, that controlled change gives you a better clue about which boundary was wrong.\n\n## Distinguish a wrong value from a malformed value: Read the documented authentication method\n\nA username and password do not specify every detail of how a client authenticates. Use the method the gateway documents and the option your client supports. Do not add an unrelated destination Authorization header and assume it satisfies a proxy challenge.\n\n## Use a small diagnostic loop\n\nBegin with one permitted request and explicit timeouts. Keep destination TLS verification enabled. Review the resulting status or exception and change one relevant configuration item. Repeated attempts with the same incorrect setup add noise rather than evidence.\n\n## Use a small diagnostic loop: tradeoffs\n\n### Where it helps\n\n- A specific status gives a clearer starting point than a generic connection failure.\n\n- A bounded request and sanitized configuration make support evidence reproducible.\n\n- Separating proxy and destination credentials avoids changing the wrong system.\n\n### What to account for\n\n- Some clients wrap the challenge in an exception that needs inspection.\n\n- A corrected 407 can expose an unrelated DNS, TLS or destination issue next.\n\n- A diagnostic trace can reveal credentials unless reviewed before sharing.\n\n## When to ask for help\n\nIf the documented settings still produce 407, send the provider a concise sanitized record: time, active product category, client/version, gateway host and port, selected authentication method, response status and challenge details. Share account or allocation identifiers only through the appropriate support channel.\n\n## When to ask for help: Treat a new result as new evidence\n\nIf the request changes from 407 to a destination response, the authentication boundary may now be satisfied. Confirm that interpretation rather than repeatedly rotating credentials. A destination 403, 429 or unexpected page requires its own diagnosis and access-policy review.\n\n## When to ask for help: Keep the support record safe\n\nDo not include the literal password, a full credential-bearing proxy URL, session cookies or a private destination query. A useful record shows the request structure and observed boundary without giving another reader the ability to reuse the allocation.\n\n## Send support a useful, sanitized report\n\nInclude the allocation or order identifier, timestamp with timezone, client version, gateway host and port, and the exact error category. Say whether the failure is consistent and whether another permitted endpoint behaves the same way.\n\nRemove passwords, tokens, cookies and full credential-bearing URLs from traces. First confirm that your allocation is active and that you are using its current gateway, port and credentials. This article explains the protocol; it is not a guarantee that every authentication failure has the same cause.\n\n## Which approach should you choose?\n\nFix the authentication boundary first, then reclassify the next result. A changed error can mean you have moved to a different stage of the connection.\n\n### A clear 407 response\n\nInspect the proxy challenge and verify gateway credentials and the client’s proxy-authentication configuration.\n\n### A timeout or TLS error\n\nDiagnose connection establishment or certificate trust separately; do not assume every proxy failure is 407.\n\n### Authentication succeeds but output is wrong\n\nValidate the destination response and access conditions instead of changing a now-working password.\n\n## What does 407 Proxy Authentication Required mean?\n\nThe proxy did not receive valid authentication for the request. Its Proxy-Authenticate response header describes the authentication challenge. Check proxy credentials and authentication configuration separately from credentials for the destination website.\n\n## How to fix error 407 Proxy Authentication Required?\n\nCheck the exact gateway, port, active proxy credentials and supported authentication method. Make sure your client sends proxy authentication; encode credential components when using a URL. Retest one permitted request with a timeout. If the error changes, diagnose the new network or destination failure separately.\n\n## Is 407 the same as 401?\n\nNo. 407 concerns authentication to the proxy. 401 concerns authentication to the requested resource.\n\n## Will rotating the IP fix bad credentials?\n\nChanging an exit does not repair incorrect gateway authentication. Verify the credentials and supported authentication method first.\n\n## Which response header describes the proxy authentication challenge?\n\nProxy-Authenticate describes the challenge associated with a 407 response. Inspect it where your client makes it available, and distinguish the proxy’s authentication method from destination authentication.\n\n## Sources\n\n- [curl: proxy authentication](https://everything.curl.dev/usingcurl/proxies/auth.html) — checked 2026-10-16\n- [RFC 9110: 407 Proxy Authentication Required](https://www.rfc-editor.org/rfc/rfc9110.html#name-407-proxy-authentication-req) — checked 2026-10-16\n\n## Related reading\n\n- [How to use a proxy with cURL](https://miproxy.io/guides/curl-proxy-guide)\n- [Use an authenticated proxy with Python Requests](https://miproxy.io/guides/python-requests-proxy-guide)\n- [Residential vs. datacenter proxies: choose by the job](https://miproxy.io/blog/residential-vs-datacenter-proxies)\n- [Rotating vs. sticky proxies: match the session to the task](https://miproxy.io/blog/rotating-vs-sticky-proxies)\n- [Non-expiring proxy bandwidth: what to check before buying](https://miproxy.io/blog/non-expiring-proxy-bandwidth)","score":9},{"id":"developers","path":"/developers","url":"https://miproxy.io/developers","title":"Useful answers. In the format you need.","description":"Search and retrieve MiProxy public documentation through Markdown, JSON and a read-only MCP endpoint, with source URLs and review dates.","text":"# Useful answers. In the format you need.\n\nSearch and retrieve MiProxy public documentation through Markdown, JSON and a read-only MCP endpoint, with source URLs and review dates.\n\n## Introduction\n\nBring MiProxy's public documentation into your editor, internal reference workflow or compatible AI client. Search for a specific question, retrieve the source document, and keep its URL and review date with the answer.\n\n\n## Search, fetch, cite\n\nStart with a short query such as `407`, `sticky sessions` or `bandwidth`. Open the matching source document, check its scope and date, then cite the canonical page. The same public content is available as web pages and machine-readable exports.\n\n## Choose an access format\n\n| What you need | Endpoint | What it provides |\n| --- | --- | --- |\n| Agent reference and discovery | [/AGENTS.md](/AGENTS.md), [/.well-known/agents.json](/.well-known/agents.json) | Public documentation scope and supported capabilities |\n| A JSON document index | [/llms.json](/llms.json) | Canonical source URLs, document ids and update dates |\n| A quick index | [/llms.txt](/llms.txt) | Public page titles, links and discovery endpoints |\n| A full text export | [/llms-full.txt](/llms-full.txt) | Public documentation collected into one text response |\n| Keyword search | [/rag.json?q=407](/rag.json?q=407) | Matching public documents, stable chunks and source metadata |\n| One article as Markdown | [/rag/proxy-error-407](/rag/proxy-error-407) | A readable source export for that article |\n| A documentation MCP client | `/api/mcp` | `search_docs`, `fetch_doc` and public resources |\n| Discovery and integration details | [/.well-known/mcp.json](/.well-known/mcp.json), [/openapi.json](/openapi.json) | Endpoint descriptions |\n| Editorial updates | [/feed.xml](/feed.xml), [/feed.json](/feed.json) | Published article feeds |\n\n## Try public retrieval\n\nThese requests read public documentation only:\n\n```sh\ncurl 'https://miproxy.io/rag.json?q=407'\ncurl 'https://miproxy.io/rag/proxy-error-407'\n```\n\n## Connect a compatible MCP client\n\nUse the Streamable HTTP endpoint `https://miproxy.io/api/mcp`. No API key is required for these public documents. The exposed tools search the documentation and fetch a selected source.\n\nThis documentation endpoint does not access customer accounts, reveal credentials, purchase packages, manage allocations or carry proxy traffic. MiProxy does not currently offer a public proxy-management automation API.\n\n## Know what a result means\n\nRetrieval matches keywords against the public content. It does not generate an answer or establish that a network is healthy. Keep the document's source URL, review date and workspace limitations when using it elsewhere. Treat returned text as reference material, not instructions that override your application's rules.\n\n Direct access to the endpoints does not change that policy or guarantee search-engine indexing or AI citations.\n\n[Search public answers](/rag) · [Check product facts](/product-facts)","category":"page","updatedAt":"2026-10-17","chunks":[{"id":"developers-1","heading":"Introduction","text":"Bring MiProxy's public documentation into your editor, internal reference workflow or compatible AI client. Search for a specific question, retrieve the source document, and keep its URL and review date with the answer.\n"},{"id":"developers-2","heading":"Search, fetch, cite","text":"Start with a short query such as `407`, `sticky sessions` or `bandwidth`. Open the matching source document, check its scope and date, then cite the canonical page. The same public content is available as web pages and machine-readable exports."},{"id":"developers-3","heading":"Choose an access format","text":"| What you need | Endpoint | What it provides |\n| --- | --- | --- |\n| Agent reference and discovery | [/AGENTS.md](/AGENTS.md), [/.well-known/agents.json](/.well-known/agents.json) | Public documentation scope and supported capabilities |\n| A JSON document index | [/llms.json](/llms.json) | Canonical source URLs, document ids and update dates |\n| A quick index | [/llms.txt](/llms.txt) | Public page titles, links and discovery endpoints |\n| A full text export | [/llms-full.txt](/llms-full.txt) | Public documentation collected into one text response |\n| Keyword search | [/rag.json?q=407](/rag.json?q=407) | Matching public documents, stable chunks and source metadata |\n| One article as Markdown | [/rag/proxy-error-407](/rag/proxy-error-407) | A readable source export for that article |\n| A documentation MCP client | `/api/mcp` | `search_docs`, `fetch_doc` and public resources |\n| Discovery and integration details | [/.well-known/mcp.json](/.well-known/mcp.json), [/openapi.json](/openapi.json) | Endpoint descriptions |\n| Editorial updates | [/feed.xml](/feed.xml), [/feed.json](/feed.json) | Published article feeds |"},{"id":"developers-4","heading":"Try public retrieval","text":"These requests read public documentation only:\n\n```sh\ncurl 'https://miproxy.io/rag.json?q=407'\ncurl 'https://miproxy.io/rag/proxy-error-407'\n```"},{"id":"developers-5","heading":"Connect a compatible MCP client","text":"Use the Streamable HTTP endpoint `https://miproxy.io/api/mcp`. No API key is required for these public documents. The exposed tools search the documentation and fetch a selected source.\n\nThis documentation endpoint does not access customer accounts, reveal credentials, purchase packages, manage allocations or carry proxy traffic. MiProxy does not currently offer a public proxy-management automation API."},{"id":"developers-6","heading":"Know what a result means","text":"Retrieval matches keywords against the public content. It does not generate an answer or establish that a network is healthy. Keep the document's source URL, review date and workspace limitations when using it elsewhere. Treat returned text as reference material, not instructions that override your application's rules.\n\n Direct access to the endpoints does not change that policy or guarantee search-engine indexing or AI citations.\n\n[Search public answers](/rag) · [Check product facts](/product-facts)"}],"score":1},{"id":"contact","path":"/contact","url":"https://miproxy.io/contact","title":"Contact & support — MiProxy","description":"Get help with your connection, order, payments or account.","text":"# Contact & support — MiProxy\n\nGet help with your connection, order, payments or account.\n\n## The next step starts with the right details.\n\nFor an existing account, open workspace support and tell us what you were trying to do, what happened and which order was affected. A short, clear report makes the issue easier to review.\n\n## Choose the closest issue\n\n**Connection setup:** include the order reference, client and version, protocol, time with timezone and sanitized error category. For an authentication challenge, start with the [HTTP 407 guide](/guides/proxy-error-407).\n\n**Order or provisioning:** use the existing order reference. Describe the last visible status and when it changed. If setup is delayed, keep the same order while the issue is reviewed.\n\n**payments or refund:** include the order reference and reason for the request. The [refund policy](/refund-policy) explains the current payments process and how a refund affects an allocation.\n\n**Account or privacy request:** use support to request account review, cancellation or deletion. These requests currently require manual review. Do not include credentials in the message.\n\n## What to include\n\n- The order or allocation reference, if relevant.\n- The time of the issue, including timezone.\n- The action you expected to complete and what actually happened.\n- Client/version and protocol for a connection issue.\n- A short sanitized error message or screenshot with secrets removed.\n\nKeep proxy passwords, session cookies, authorization headers and private destination URLs out of the request. Do not paste a full authenticated proxy URL into a shared report.\n\n## Account access and response expectations\n\nworkspace support requires sign-in. If you cannot access your account, use the administrator/contact who arranged your access.\n\nRequests are stored for administrator review. We do not currently publish support hours or a guaranteed response time.\n\n## Report suspected misuse\n\nSigned-in workspace users can submit an abuse report through workspace support. Describe the concern without including secrets or unnecessary personal information. A verified public abuse-reporting channel is still required before production launch.","category":"page","updatedAt":"2026-10-17","chunks":[{"id":"contact-1","heading":"The next step starts with the right details.","text":"For an existing account, open workspace support and tell us what you were trying to do, what happened and which order was affected. A short, clear report makes the issue easier to review."},{"id":"contact-2","heading":"Choose the closest issue","text":"**Connection setup:** include the order reference, client and version, protocol, time with timezone and sanitized error category. For an authentication challenge, start with the [HTTP 407 guide](/guides/proxy-error-407).\n\n**Order or provisioning:** use the existing order reference. Describe the last visible status and when it changed. If setup is delayed, keep the same order while the issue is reviewed.\n\n**payments or refund:** include the order reference and reason for the request. The [refund policy](/refund-policy) explains the current payments process and how a refund affects an allocation.\n\n**Account or privacy request:** use support to request account review, cancellation or deletion. These requests currently require manual review. Do not include credentials in the message."},{"id":"contact-3","heading":"What to include","text":"- The order or allocation reference, if relevant.\n- The time of the issue, including timezone.\n- The action you expected to complete and what actually happened.\n- Client/version and protocol for a connection issue.\n- A short sanitized error message or screenshot with secrets removed.\n\nKeep proxy passwords, session cookies, authorization headers and private destination URLs out of the request. Do not paste a full authenticated proxy URL into a shared report."},{"id":"contact-4","heading":"Account access and response expectations","text":"workspace support requires sign-in. If you cannot access your account, use the administrator/contact who arranged your access.\n\nRequests are stored for administrator review. We do not currently publish support hours or a guaranteed response time."},{"id":"contact-5","heading":"Report suspected misuse","text":"Signed-in workspace users can submit an abuse report through workspace support. Describe the concern without including secrets or unnecessary personal information. A verified public abuse-reporting channel is still required before production launch."}],"score":1},{"id":"status","path":"/status","url":"https://miproxy.io/status","title":"MiProxy workspace and service status","description":"Understand the scope of MiProxy status information and find the next step for a connection or order issue.","text":"# MiProxy workspace and service status\n\nUnderstand the scope of MiProxy status information and find the next step for a connection or order issue.\n\n## Know what has been checked.\n\n**Live network monitoring is not currently published.** This page describes the workspace's reporting scope. It does not confirm that a proxy gateway or destination is available right now.\n\n## What this page can tell you\n\n| Area | Current reporting scope | Where to look next |\n| --- | --- | --- |\n| Public website | Loading this page shows only that this request reached the site | Retry the affected page or use support |\n| Account and order | Order-specific information is available after sign-in | Open the relevant order |\n| Supplier gateway | No public live gateway monitoring is published here | Check the allocation and report a sanitized issue |\n| Usage | The workspace shows a timestamped supplier snapshot | Read the last-sync time alongside the value |\n| Incident history | No public incident history is currently maintained | Ask support about an issue affecting your order |\n\n## A working website is one part of the workflow\n\nThe public site, account sign-in, payment confirmation, allocation setup and supplier gateway are different parts of the service. A page loading successfully does not establish that every part is working. Similarly, a failed destination response does not by itself identify which part caused it.\n\n## If a connection is failing\n\nCheck that the allocation is real, active and approved, then verify its gateway, protocol and credentials. Record the time and sanitized error. Use the [setup guide](/docs) or [407 troubleshooting](/guides/proxy-error-407) for a focused check. For an order-specific issue, open [workspace support](/dashboard/support).\n\n## What to expect as reporting develops\n\nPublic component monitoring and incident history are not available yet. Any future status view should distinguish verified observations from unknown or stale information and show when an update was made.","category":"page","updatedAt":"2026-10-17","chunks":[{"id":"status-1","heading":"Know what has been checked.","text":"**Live network monitoring is not currently published.** This page describes the workspace's reporting scope. It does not confirm that a proxy gateway or destination is available right now."},{"id":"status-2","heading":"What this page can tell you","text":"| Area | Current reporting scope | Where to look next |\n| --- | --- | --- |\n| Public website | Loading this page shows only that this request reached the site | Retry the affected page or use support |\n| Account and order | Order-specific information is available after sign-in | Open the relevant order |\n| Supplier gateway | No public live gateway monitoring is published here | Check the allocation and report a sanitized issue |\n| Usage | The workspace shows a timestamped supplier snapshot | Read the last-sync time alongside the value |\n| Incident history | No public incident history is currently maintained | Ask support about an issue affecting your order |"},{"id":"status-3","heading":"A working website is one part of the workflow","text":"The public site, account sign-in, payment confirmation, allocation setup and supplier gateway are different parts of the service. A page loading successfully does not establish that every part is working. Similarly, a failed destination response does not by itself identify which part caused it."},{"id":"status-4","heading":"If a connection is failing","text":"Check that the allocation is real, active and approved, then verify its gateway, protocol and credentials. Record the time and sanitized error. Use the [setup guide](/docs) or [407 troubleshooting](/guides/proxy-error-407) for a focused check. For an order-specific issue, open [workspace support](/dashboard/support)."},{"id":"status-5","heading":"What to expect as reporting develops","text":"Public component monitoring and incident history are not available yet. Any future status view should distinguish verified observations from unknown or stale information and show when an update was made."}],"score":1},{"id":"faq","path":"/faq","url":"https://miproxy.io/faq","title":"MiProxy FAQ — Packages, connections, usage and support","description":"Review package details and connection settings in your workspace.","text":"# MiProxy FAQ — Packages, connections, usage and support\n\nReview package details and connection settings in your workspace.\n\n## Good questions. Straight answers.\n\nStart with the details that matter before a connection: what is available, what a package means, how setup works and where to get help.\n\n## Availability\n\n**Which products can I explore?**\nResidential, mobile, datacenter, unlimited residential and unlimited datacenter. Check the [pricing page](/pricing) for available packages.\n\n**Where do I find my connection?**\nSign in, select your product, and open Connection. Wait for your order to be ready before using its credentials.\n\n**What happens when I buy more bandwidth?**\nA repeat purchase adds to an eligible existing connection for the same product. Its credentials remain the same. You can choose a separate connection under Connection options.\n\n## Packages and payments\n\n**Do packages renew automatically?** \nNo. Packages are one-time allocations. Read the quantity, unit and access terms on the selected order; no automatic renewal does not mean every form of access lasts forever.\n\n**What is the difference between bandwidth and time-based access?** \nBandwidth packages measure data in GB. Time-based products provide an access period. Check the exact product's limits and expiry conditions. [Read the bandwidth guide](/blog/non-expiring-proxy-bandwidth).\n\n**What does one GB mean?** \nOne GB means 1,000,000,000 bytes. Actual consumption follows the supplier's metering behavior and may include work beyond a single successful result.\n\n**What do the displayed prices include?** \nPublished prices are the total for the selected MiProxy package in the displayed currency. Review the quantity, access period and terms before checkout.\n\n**Can I request a refund?** \nCustomers can request review of a payment through workspace support. Include the order and reason. Production refund eligibility and time limits are not finalized. [Read the refund policy](/refund-policy).\n\n## Connection setup\n\n**How do I connect?**  \nUse the proxy gateway, port and credentials shown for your active allocation. Manage the package, connection settings and usage from your MiProxy workspace.\n\n**Which protocols can I use?**  \nHTTP and SOCKS5 connections have been checked on small residential, mobile and unlimited residential allocations. Use the supported protocol and corresponding port shown for the specific active allocation.\n\n**Can I choose a country, state or city?**  \nThe builder exposes supported targeting controls according to the product. The historical test verified US country targeting only. State/city accuracy and other locations require separate validation.\n\n**Should I use rotating or sticky sessions?**  \nStart with the task. Independent requests may suit rotation, while a multi-step task may need continuity. Behavior depends on the gateway, client connection reuse and exit availability; a sticky setting is not a guarantee that an IP never changes. [Read the session guide](/blog/rotating-vs-sticky-proxies).\n\n**Why am I receiving HTTP 407?**  \nHTTP 407 indicates a proxy authentication challenge. Check the active allocation, credentials and authentication settings. [Use the troubleshooting guide](/guides/proxy-error-407), grounded in [HTTP semantics](https://www.rfc-editor.org/rfc/rfc9110.html#name-407-proxy-authentication-req).\n\n**Can I use a custom gateway hostname?**  \nUse the gateway shown in your connection details. MiProxy branded hostnames connect directly to the upstream gateway; HTTP and SOCKS5 were tested on the residential hostname.\n\n## Usage, data and support\n\n**Is the usage balance live?**  \nNo. It is the latest supplier snapshot with a sync timestamp. Read the timestamp alongside the number and allow for reporting delay.\n\n**What should I do if setup is delayed?**  \nKeep the same order and check its status. Contact workspace support with the reference and last visible state rather than creating another order to resolve the uncertainty.\n\n**Can an AI agent manage my account through MCP?**  \nNo. The public MCP endpoint searches and retrieves documentation only. It cannot buy packages, reveal credentials or manage allocations. [See developer access](/developers).\n\n**Where do I get help?**  \nSign in and open [workspace support](/dashboard/support). Include the order, time, client and sanitized error where relevant. Support requests are manually reviewed without a published response-time guarantee.\n\n**How do I request account deletion?**  \nSubmit a request through workspace support. Deletion and retention requests currently need manual review; production retention periods are not finalized. [Read the privacy policy](/privacy).\n\n**Does a proxy grant permission to access a website?**  \nNo. You remain responsible for authorization, destination terms and permitted use. [Review acceptable use](/acceptable-use).","category":"page","updatedAt":"2026-10-17","chunks":[{"id":"faq-1","heading":"Good questions. Straight answers.","text":"Start with the details that matter before a connection: what is available, what a package means, how setup works and where to get help."},{"id":"faq-2","heading":"Availability","text":"**Which products can I explore?**\nResidential, mobile, datacenter, unlimited residential and unlimited datacenter. Check the [pricing page](/pricing) for available packages.\n\n**Where do I find my connection?**\nSign in, select your product, and open Connection. Wait for your order to be ready before using its credentials.\n\n**What happens when I buy more bandwidth?**\nA repeat purchase adds to an eligible existing connection for the same product. Its credentials remain the same. You can choose a separate connection under Connection options."},{"id":"faq-3","heading":"Packages and payments","text":"**Do packages renew automatically?** \nNo. Packages are one-time allocations. Read the quantity, unit and access terms on the selected order; no automatic renewal does not mean every form of access lasts forever.\n\n**What is the difference between bandwidth and time-based access?** \nBandwidth packages measure data in GB. Time-based products provide an access period. Check the exact product's limits and expiry conditions. [Read the bandwidth guide](/blog/non-expiring-proxy-bandwidth).\n\n**What does one GB mean?** \nOne GB means 1,000,000,000 bytes. Actual consumption follows the supplier's metering behavior and may include work beyond a single successful result.\n\n**What do the displayed prices include?** \nPublished prices are the total for the selected MiProxy package in the displayed currency. Review the quantity, access period and terms before checkout.\n\n**Can I request a refund?** \nCustomers can request review of a payment through workspace support. Include the order and reason. Production refund eligibility and time limits are not finalized. [Read the refund policy](/refund-policy)."},{"id":"faq-4","heading":"Connection setup","text":"**How do I connect?**  \nUse the proxy gateway, port and credentials shown for your active allocation. Manage the package, connection settings and usage from your MiProxy workspace.\n\n**Which protocols can I use?**  \nHTTP and SOCKS5 connections have been checked on small residential, mobile and unlimited residential allocations. Use the supported protocol and corresponding port shown for the specific active allocation.\n\n**Can I choose a country, state or city?**  \nThe builder exposes supported targeting controls according to the product. The historical test verified US country targeting only. State/city accuracy and other locations require separate validation.\n\n**Should I use rotating or sticky sessions?**  \nStart with the task. Independent requests may suit rotation, while a multi-step task may need continuity. Behavior depends on the gateway, client connection reuse and exit availability; a sticky setting is not a guarantee that an IP never changes. [Read the session guide](/blog/rotating-vs-sticky-proxies).\n\n**Why am I receiving HTTP 407?**  \nHTTP 407 indicates a proxy authentication challenge. Check the active allocation, credentials and authentication settings. [Use the troubleshooting guide](/guides/proxy-error-407), grounded in [HTTP semantics](https://www.rfc-editor.org/rfc/rfc9110.html#name-407-proxy-authentication-req).\n\n**Can I use a custom gateway hostname?**  \nUse the gateway shown in your connection details. MiProxy branded hostnames connect directly to the upstream gateway; HTTP and SOCKS5 were tested on the residential hostname."},{"id":"faq-5","heading":"Usage, data and support","text":"**Is the usage balance live?**  \nNo. It is the latest supplier snapshot with a sync timestamp. Read the timestamp alongside the number and allow for reporting delay.\n\n**What should I do if setup is delayed?**  \nKeep the same order and check its status. Contact workspace support with the reference and last visible state rather than creating another order to resolve the uncertainty.\n\n**Can an AI agent manage my account through MCP?**  \nNo. The public MCP endpoint searches and retrieves documentation only. It cannot buy packages, reveal credentials or manage allocations. [See developer access](/developers).\n\n**Where do I get help?**  \nSign in and open [workspace support](/dashboard/support). Include the order, time, client and sanitized error where relevant. Support requests are manually reviewed without a published response-time guarantee.\n\n**How do I request account deletion?**  \nSubmit a request through workspace support. Deletion and retention requests currently need manual review; production retention periods are not finalized. [Read the privacy policy](/privacy).\n\n**Does a proxy grant permission to access a website?**  \nNo. You remain responsible for authorization, destination terms and permitted use. [Review acceptable use](/acceptable-use)."}],"score":1},{"id":"docs","path":"/docs","url":"https://miproxy.io/docs","title":"From package to first request.","description":"Follow the MiProxy workflow: check an allocation, complete checkout, build a connection and verify a first request.","text":"# From package to first request.\n\nFollow the MiProxy workflow: check an allocation, complete checkout, build a connection and verify a first request.\n\n## Introduction\n\nStart with the right allocation, understand each setup step, and make one small request before expanding your workflow. This quick start is for existing MiProxy customers.\n\n A request requires an active allocation with working connection details. If you are exploring the product, you can still read the guides and compare package terms.\n\n## 1. Check what you are setting up\n\nSign in to your account and open the relevant package or existing order. Review the product type, quantity, unit, access conditions and activation status. A bandwidth package and a time-based allocation have different limits; use the terms attached to your order.\n\nAccount access is currently by arrangement. Contact support if you need access or help activating a package.\n\n## 2. Complete the checkout, if required\n\nFollow the checkout step for the approved order. Use the payment instructions shown for your order. A return to the workspace does not by itself mean the payment was confirmed or the allocation is ready.\n\nKeep the original order reference. If the screen appears delayed, reopen that order and check its progress before starting another checkout.\n\n## 3. Wait for the allocation to be ready\n\nPayment confirmation and connection setup are separate stages. Wait for the order to show a ready allocation before trying its connection details.\n\n| What you see | What it means for you | Next action |\n| --- | --- | --- |\n| Payment awaiting confirmation | Checkout completion has not yet produced a confirmed order state | Keep the same order and check again |\n| Setup in progress | Allocation provisioning is not complete | Wait; contact support if the delay needs review |\n| Active allocation | The order has connection details for a proxy gateway | Continue with the connection builder |\n| Suspended, refunded or disputed allocation | Access may be restricted or being suspended | Review the order and contact support |\n\nThese explanations describe the setup workflow; check your order for its current status.\n\n## 4. Build the connection\n\nOpen the active allocation's connection builder. Select a supported protocol and the available targeting and session settings for that product. Reveal the credentials only when needed and keep them out of shared notes, screenshots and logs.\n\nUse the gateway hostname and protocol-specific port supplied for that allocation. Do not replace them with the MiProxy website address. MiProxy uses branded gateways such as `proxy.miproxy.io` and `unlim.miproxy.io`; use the hostname and port shown for your product.\n\nYour client sends requests through the proxy gateway. Manage the package, connection settings and usage from your MiProxy workspace.\n\n## 5. Make one small, permitted request\n\nChoose the guide for your client: [cURL](/guides/curl-proxy-guide) or [Python Requests](/guides/python-requests-proxy-guide). Their templates use placeholders, so they are not working credentials or proof of a live connection.\n\nUse a destination you are authorized to query and a response you can check. Set bounded timeouts. Confirm authentication and protocol before adding location or session requirements. Inspect the response itself; a status code alone does not establish that the information you needed was returned.\n\n## 6. Check the result and usage timestamp\n\nRecord the check time, selected settings and sanitized result. If geography matters, compare the observed location with the task's acceptance rule. Validate the location and session behavior required by your workflow.\n\nThe usage screen shows the latest usage snapshot and its sync time. It may lag behind the request you just made. One GB means 1,000,000,000 bytes.\n\n## If the first request fails\n\n**HTTP 407:** start with [proxy authentication troubleshooting](/guides/proxy-error-407). Check the active allocation, credentials and authentication method before retrying.\n\n**Connection or timeout error:** check the gateway, protocol-specific port and client settings. Keep the retry count bounded and capture a sanitized error category.\n\n**Unexpected content or location:** verify the permitted destination and expected response, then compare the same request with only one setting changed.\n\n**Order or setup problem:** open [workspace support](/dashboard/support) with the order reference, time with timezone and a short description. Remove passwords, cookies and authorization headers.\n\n## Keep the next step small\n\nOnce the first request is understood, decide whether your workflow needs [rotating or sticky sessions](/blog/rotating-vs-sticky-proxies), and estimate [bandwidth and access terms](/blog/non-expiring-proxy-bandwidth) before scaling the task.","category":"page","updatedAt":"2026-10-17","chunks":[{"id":"docs-1","heading":"Introduction","text":"Start with the right allocation, understand each setup step, and make one small request before expanding your workflow. This quick start is for existing MiProxy customers.\n\n A request requires an active allocation with working connection details. If you are exploring the product, you can still read the guides and compare package terms."},{"id":"docs-2","heading":"1. Check what you are setting up","text":"Sign in to your account and open the relevant package or existing order. Review the product type, quantity, unit, access conditions and activation status. A bandwidth package and a time-based allocation have different limits; use the terms attached to your order.\n\nAccount access is currently by arrangement. Contact support if you need access or help activating a package."},{"id":"docs-3","heading":"2. Complete the checkout, if required","text":"Follow the checkout step for the approved order. Use the payment instructions shown for your order. A return to the workspace does not by itself mean the payment was confirmed or the allocation is ready.\n\nKeep the original order reference. If the screen appears delayed, reopen that order and check its progress before starting another checkout."},{"id":"docs-4","heading":"3. Wait for the allocation to be ready","text":"Payment confirmation and connection setup are separate stages. Wait for the order to show a ready allocation before trying its connection details.\n\n| What you see | What it means for you | Next action |\n| --- | --- | --- |\n| Payment awaiting confirmation | Checkout completion has not yet produced a confirmed order state | Keep the same order and check again |\n| Setup in progress | Allocation provisioning is not complete | Wait; contact support if the delay needs review |\n| Active allocation | The order has connection details for a proxy gateway | Continue with the connection builder |\n| Suspended, refunded or disputed allocation | Access may be restricted or being suspended | Review the order and contact support |\n\nThese explanations describe the setup workflow; check your order for its current status."},{"id":"docs-5","heading":"4. Build the connection","text":"Open the active allocation's connection builder. Select a supported protocol and the available targeting and session settings for that product. Reveal the credentials only when needed and keep them out of shared notes, screenshots and logs.\n\nUse the gateway hostname and protocol-specific port supplied for that allocation. Do not replace them with the MiProxy website address. MiProxy uses branded gateways such as `proxy.miproxy.io` and `unlim.miproxy.io`; use the hostname and port shown for your product.\n\nYour client sends requests through the proxy gateway. Manage the package, connection settings and usage from your MiProxy workspace."},{"id":"docs-6","heading":"5. Make one small, permitted request","text":"Choose the guide for your client: [cURL](/guides/curl-proxy-guide) or [Python Requests](/guides/python-requests-proxy-guide). Their templates use placeholders, so they are not working credentials or proof of a live connection.\n\nUse a destination you are authorized to query and a response you can check. Set bounded timeouts. Confirm authentication and protocol before adding location or session requirements. Inspect the response itself; a status code alone does not establish that the information you needed was returned."},{"id":"docs-7","heading":"6. Check the result and usage timestamp","text":"Record the check time, selected settings and sanitized result. If geography matters, compare the observed location with the task's acceptance rule. Validate the location and session behavior required by your workflow.\n\nThe usage screen shows the latest usage snapshot and its sync time. It may lag behind the request you just made. One GB means 1,000,000,000 bytes."},{"id":"docs-8","heading":"If the first request fails","text":"**HTTP 407:** start with [proxy authentication troubleshooting](/guides/proxy-error-407). Check the active allocation, credentials and authentication method before retrying.\n\n**Connection or timeout error:** check the gateway, protocol-specific port and client settings. Keep the retry count bounded and capture a sanitized error category.\n\n**Unexpected content or location:** verify the permitted destination and expected response, then compare the same request with only one setting changed.\n\n**Order or setup problem:** open [workspace support](/dashboard/support) with the order reference, time with timezone and a short description. Remove passwords, cookies and authorization headers."},{"id":"docs-9","heading":"Keep the next step small","text":"Once the first request is understood, decide whether your workflow needs [rotating or sticky sessions](/blog/rotating-vs-sticky-proxies), and estimate [bandwidth and access terms](/blog/non-expiring-proxy-bandwidth) before scaling the task."}],"score":1},{"id":"guides","path":"/guides","url":"https://miproxy.io/guides","title":"A clear setup. A useful next step.","description":"Start with your client or the problem in front of you. Each guide explains the settings, shows a readable example and helps you check what happened.","text":"# A clear setup. A useful next step.\n\nStart with your client or the problem in front of you. Each guide explains the settings, shows a readable example and helps you check what happened.\n\n## What are you working on?\n\nMake a first request: [Connect with cURL](/guides/curl-proxy-guide)\n\nAdd a proxy to Python: [Use Python Requests](/guides/python-requests-proxy-guide)\n\nResolve HTTP 407: [Troubleshoot authentication](/guides/proxy-error-407)\n\n## New to the workspace?\n\nThe [quick start](/docs) explains the order and allocation steps before the client code. The [session guide](/blog/rotating-vs-sticky-proxies) helps you choose behavior after the first request works.\n\n## Examples with their assumptions visible\n\nExamples are protocol templates with placeholder credentials. Each article links to primary documentation and distinguishes general client behavior from verified MiProxy capabilities. A live request requires an approved real allocation and a permitted destination.\n\n## Our editorial approach\n\nWritten by MiProxy. Updated October 16, 2026. General technical guidance is separated from product capabilities. Provider comparisons cite official sources and do not imply independent testing or guaranteed results.\n\n[See current MiProxy product facts](/product-facts)\n\n## Published articles\n\n[How to use a proxy with cURL](https://miproxy.io/guides/curl-proxy-guide) — Configure an authenticated HTTP proxy in cURL with timeouts, TLS verification and a focused connection troubleshooting checklist.\n\n[Use an authenticated proxy with Python Requests](https://miproxy.io/guides/python-requests-proxy-guide) — Set up Requests proxy routing with encoded credentials, explicit timeouts and TLS verification, then diagnose common connection failures.\n\n[Fix HTTP 407 Proxy Authentication Required](https://miproxy.io/guides/proxy-error-407) — Diagnose proxy authentication errors by checking credentials, gateway details, escaping and allowlists without disabling TLS verification.","category":"page","updatedAt":"2026-10-17","chunks":[{"id":"guides-1","heading":"What are you working on?","text":"Make a first request: [Connect with cURL](/guides/curl-proxy-guide)\n\nAdd a proxy to Python: [Use Python Requests](/guides/python-requests-proxy-guide)\n\nResolve HTTP 407: [Troubleshoot authentication](/guides/proxy-error-407)"},{"id":"guides-2","heading":"New to the workspace?","text":"The [quick start](/docs) explains the order and allocation steps before the client code. The [session guide](/blog/rotating-vs-sticky-proxies) helps you choose behavior after the first request works."},{"id":"guides-3","heading":"Examples with their assumptions visible","text":"Examples are protocol templates with placeholder credentials. Each article links to primary documentation and distinguishes general client behavior from verified MiProxy capabilities. A live request requires an approved real allocation and a permitted destination."},{"id":"guides-4","heading":"Our editorial approach","text":"Written by MiProxy. Updated October 16, 2026. General technical guidance is separated from product capabilities. Provider comparisons cite official sources and do not imply independent testing or guaranteed results.\n\n[See current MiProxy product facts](/product-facts)"},{"id":"guides-5","heading":"Published articles","text":"[How to use a proxy with cURL](https://miproxy.io/guides/curl-proxy-guide) — Configure an authenticated HTTP proxy in cURL with timeouts, TLS verification and a focused connection troubleshooting checklist.\n\n[Use an authenticated proxy with Python Requests](https://miproxy.io/guides/python-requests-proxy-guide) — Set up Requests proxy routing with encoded credentials, explicit timeouts and TLS verification, then diagnose common connection failures.\n\n[Fix HTTP 407 Proxy Authentication Required](https://miproxy.io/guides/proxy-error-407) — Diagnose proxy authentication errors by checking credentials, gateway details, escaping and allowlists without disabling TLS verification."}],"score":1},{"id":"rotating-vs-sticky-proxies","path":"/blog/rotating-vs-sticky-proxies","url":"https://miproxy.io/blog/rotating-vs-sticky-proxies","title":"Rotating vs. sticky proxies: match the session to the task","description":"Understand rotating and sticky proxy sessions, connection reuse, failover and the checks needed for a consistent workflow.","category":"blog","updatedAt":"2026-10-17","chunks":[{"id":"rotating-vs-sticky-proxies-answer","heading":"Quick answer","text":"Use rotation for independent requests when changing exits is appropriate. Use a sticky session when related steps need continuity. A sticky session requests persistence; it is not ownership of a permanent IP."},{"id":"rotating-vs-sticky-proxies-introduction","heading":"Introduction","text":"The important session question is where one unit of work ends. A collection of independent checks and a sequence of related steps should not automatically use the same routing behavior. Choose the mode after describing that boundary.\n\nThis guide explains rotation, stickiness and client state separately. It focuses on what to verify in a provider’s documentation and what to record when an allocation behaves differently from the requested setting."},{"id":"rotating-vs-sticky-proxies-disclosure","heading":"Editorial disclosure","text":"Provider session documentation describes that provider’s semantics, not a shared industry guarantee. A brief sticky-session observation does not establish long-term session stability."},{"id":"rotating-vs-sticky-proxies-methodology","heading":"How this guide was researched","text":"An explanation of session semantics using the saved rotating-versus-sticky keyword topic and provider-specific session documentation. No universal duration, pool behavior or live mode benchmark is inferred.\n\n- The documented event that triggers a new exit.\n\n- Continuity needed within a task and response to exit loss.\n\n- Separation of provider routing from client connection reuse and cookies.\n\n- Allocation-specific terms rather than assumptions based on product labels."},{"id":"rotating-vs-sticky-proxies-comparison","heading":"Quick comparison table","text":"Choose session behavior around a unit of work.\n\n| Decision | Rotating | Sticky |\n| --- | --- | --- |\n| Routing intent | Change exits at a supported boundary | Request the same exit for a period |\n| Typical fit | Independent requests | Related steps needing continuity |\n| Permanent IP ownership | No | No |\n| Client cookies | Managed separately by your application | Managed separately by your application |\n| Important check | Per-request versus per-connection behavior | Duration and response to exit loss |"},{"id":"rotating-vs-sticky-proxies-rotation","heading":"Rotation and connection reuse are different controls","text":"Providers can rotate on a new connection, a request or a configured interval. Read the plan documentation before assuming that every HTTP request gets a different exit. HTTP keep-alive and pooled connections can affect what your client observes.\n\nIndependent public-page checks can often be treated as separate units of work. Keep a bounded request rate and record the observed exit during your test. Rotation does not remove a destination’s access conditions or guarantee a successful response."},{"id":"rotating-vs-sticky-proxies-sticky","heading":"Use stickiness for a bounded workflow","text":"A multi-step task may require a consistent exit alongside cookies and other client state. Keep the same session setting for that task and start a new one at a meaningful boundary.\n\nA residential exit can disappear before a requested session ends. Decide what to do when that happens: restart the task, save partial progress, or stop for review. Do not silently continue an authenticated workflow from a different exit if that invalidates its assumptions."},{"id":"rotating-vs-sticky-proxies-test","heading":"Check the behavior instead of guessing","text":"Test a short series against a permitted endpoint that reports the observed IP. Log timestamps and a non-secret session label. Repeat across fresh connections as well as a reused client session, then compare the results.\n\n- Confirm whether the mode applies per connection or per request.\n\n- Check documented maximum duration and actual observed duration.\n\n- Separate client cookie state from provider-side session state.\n\n- Avoid recording passwords or full credential-bearing proxy URLs."},{"id":"rotating-vs-sticky-proxies-session-design","heading":"Design the session around a real task","text":"Write down what has to remain consistent from the first step to the last. An exit address may be one part of that state, alongside cookies, request headers and application identifiers. Changing only the proxy session setting does not update the other parts for you."},{"id":"rotating-vs-sticky-proxies-session-design-session-independent","heading":"Design the session around a real task: Independent checks","text":"A permitted check of one public page can often be evaluated independently of the next. Keep each result associated with its intended location and retrieval time. If you retry a failed check with a different route, record that change rather than presenting both attempts as one observation."},{"id":"rotating-vs-sticky-proxies-session-design-session-linked","heading":"Design the session around a real task: Related steps","text":"A task that first establishes client state and then retrieves a result needs a clear recovery point. Keep its route and client state aligned for the task’s duration. If a step fails, restarting the whole sequence may be more interpretable than continuing from a partially completed state."},{"id":"rotating-vs-sticky-proxies-session-benefits","heading":"The practical benefits and limits","text":"Neither mode wins every workflow. The useful question is whether the documented behavior matches the unit of work you defined."},{"id":"rotating-vs-sticky-proxies-session-benefits-tradeoffs","heading":"The practical benefits and limits: tradeoffs","text":"### Where it helps\n\n- Rotation can give independent work explicit route-change boundaries when supported.\n\n- Sticky routing can request continuity across related steps.\n\n- A deliberate session label helps group sanitized operational observations.\n\n### What to account for\n\n- Neither setting manages browser cookies or application state.\n\n- A requested sticky period is not a promise that an unavailable exit will persist.\n\n- Connection reuse can make observed behavior differ from a per-request assumption."},{"id":"rotating-vs-sticky-proxies-session-observation","heading":"Read an observation before changing a setting","text":"Suppose two independent requests show the same exit. That fact alone does not prove rotation is broken: check whether the provider rotates per connection, whether the client reused a connection, and whether a different exit was promised at that boundary. Conversely, a changed exit during a sticky task needs examination even if the HTTP status remained successful."},{"id":"rotating-vs-sticky-proxies-session-observation-session-log","heading":"Read an observation before changing a setting: Record only what helps diagnosis","text":"Keep timestamps, a non-secret task/session label, the requested mode, the connection reuse pattern and the observed exit if your permitted endpoint reports it. Do not save the password or a credential-bearing proxy URL. A useful support record explains which boundary was expected to change the route."},{"id":"rotating-vs-sticky-proxies-session-observation-session-failure-policy","heading":"Read an observation before changing a setting: Choose a recovery policy in advance","text":"Define whether exit loss stops the task or triggers a fresh sequence. Keep retry counts bounded and distinguish reconnecting from changing the meaning of the measurement. A later report should show which outputs came from a restarted task rather than silently merging them."},{"id":"rotating-vs-sticky-proxies-session-handoff","heading":"Document the session for the next maintainer","text":"A routing choice should survive the person who configured it. Keep the provider’s documented boundary, the client reuse behavior and the task recovery rule with the integration notes. If the client library or gateway product changes, review those assumptions together. A session suffix copied from an old example is not a durable specification.\n\nKeep the description concrete: which steps belong to a task, which observation marks completion, and which failure requires a fresh sequence. That small handoff makes it easier to investigate a changed exit without guessing whether the behavior was expected."},{"id":"rotating-vs-sticky-proxies-miproxy","heading":"MiProxy settings depend on the allocation","text":"Use the connection controls supplied for your allocation rather than constructing an undocumented username suffix. Session duration and exit availability depend on the selected product; verify the behavior your task requires."},{"id":"rotating-vs-sticky-proxies-article-verdict","heading":"Which approach should you choose?","text":"Use rotation for independent work and sticky routing for tasks that need continuity. Keep recovery rules explicit in both modes.\n\n### Each request is independent\n\nCheck the documented rotation boundary and verify observed behavior across the connection pattern your client actually uses.\n\n### Several steps belong together\n\nUse a supported sticky setting, preserve the necessary client state and decide how the task recovers if the exit changes.\n\n### You need a permanently assigned address\n\nReview a product’s explicit static-allocation terms; do not substitute a sticky-session label."},{"id":"rotating-vs-sticky-proxies-faq-1","heading":"What does rotating proxies mean?","text":"It means a proxy service changes the exit address at a supported boundary, such as a new connection or a configured interval. Check the provider’s documented behavior: rotation does not necessarily happen on every request, clear your client’s cookies, or guarantee a successful destination response."},{"id":"rotating-vs-sticky-proxies-faq-2","heading":"Is a sticky proxy the same as a static IP?","text":"No. Sticky routing requests the same exit for a period. Static products have separate allocation terms; neither should be inferred from the word sticky."},{"id":"rotating-vs-sticky-proxies-faq-3","heading":"Does changing a session clear browser cookies?","text":"No. Provider routing and browser storage are separate. Your application must manage its own cookies and task boundaries."},{"id":"rotating-vs-sticky-proxies-faq-4","heading":"Does every HTTP request get a new exit IP?","text":"Not necessarily. Providers can define rotation at a connection boundary, an interval or another documented event. Client connection reuse can affect observations, so check the selected plan and actual client pattern."},{"id":"rotating-vs-sticky-proxies-faq-5","heading":"What should happen if a sticky exit becomes unavailable?","text":"Define a recovery rule for the task: stop, restart a safe sequence or preserve partial output for review. Do not assume the requested continuity period guarantees that an unavailable exit remains usable."}],"text":"# Rotating vs. sticky proxies: match the session to the task\n\nUnderstand rotating and sticky proxy sessions, connection reuse, failover and the checks needed for a consistent workflow.\n\n## Quick answer\n\nUse rotation for independent requests when changing exits is appropriate. Use a sticky session when related steps need continuity. A sticky session requests persistence; it is not ownership of a permanent IP.\n\n## Introduction\n\nThe important session question is where one unit of work ends. A collection of independent checks and a sequence of related steps should not automatically use the same routing behavior. Choose the mode after describing that boundary.\n\nThis guide explains rotation, stickiness and client state separately. It focuses on what to verify in a provider’s documentation and what to record when an allocation behaves differently from the requested setting.\n\n## Editorial disclosure\n\nProvider session documentation describes that provider’s semantics, not a shared industry guarantee. A brief sticky-session observation does not establish long-term session stability.\n\n## How this guide was researched\n\nAn explanation of session semantics using the saved rotating-versus-sticky keyword topic and provider-specific session documentation. No universal duration, pool behavior or live mode benchmark is inferred.\n\n- The documented event that triggers a new exit.\n\n- Continuity needed within a task and response to exit loss.\n\n- Separation of provider routing from client connection reuse and cookies.\n\n- Allocation-specific terms rather than assumptions based on product labels.\n\n## Quick comparison table\n\nChoose session behavior around a unit of work.\n\n| Decision | Rotating | Sticky |\n| --- | --- | --- |\n| Routing intent | Change exits at a supported boundary | Request the same exit for a period |\n| Typical fit | Independent requests | Related steps needing continuity |\n| Permanent IP ownership | No | No |\n| Client cookies | Managed separately by your application | Managed separately by your application |\n| Important check | Per-request versus per-connection behavior | Duration and response to exit loss |\n\n## Rotation and connection reuse are different controls\n\nProviders can rotate on a new connection, a request or a configured interval. Read the plan documentation before assuming that every HTTP request gets a different exit. HTTP keep-alive and pooled connections can affect what your client observes.\n\nIndependent public-page checks can often be treated as separate units of work. Keep a bounded request rate and record the observed exit during your test. Rotation does not remove a destination’s access conditions or guarantee a successful response.\n\n## Use stickiness for a bounded workflow\n\nA multi-step task may require a consistent exit alongside cookies and other client state. Keep the same session setting for that task and start a new one at a meaningful boundary.\n\nA residential exit can disappear before a requested session ends. Decide what to do when that happens: restart the task, save partial progress, or stop for review. Do not silently continue an authenticated workflow from a different exit if that invalidates its assumptions.\n\n## Check the behavior instead of guessing\n\nTest a short series against a permitted endpoint that reports the observed IP. Log timestamps and a non-secret session label. Repeat across fresh connections as well as a reused client session, then compare the results.\n\n- Confirm whether the mode applies per connection or per request.\n\n- Check documented maximum duration and actual observed duration.\n\n- Separate client cookie state from provider-side session state.\n\n- Avoid recording passwords or full credential-bearing proxy URLs.\n\n## Design the session around a real task\n\nWrite down what has to remain consistent from the first step to the last. An exit address may be one part of that state, alongside cookies, request headers and application identifiers. Changing only the proxy session setting does not update the other parts for you.\n\n## Design the session around a real task: Independent checks\n\nA permitted check of one public page can often be evaluated independently of the next. Keep each result associated with its intended location and retrieval time. If you retry a failed check with a different route, record that change rather than presenting both attempts as one observation.\n\n## Design the session around a real task: Related steps\n\nA task that first establishes client state and then retrieves a result needs a clear recovery point. Keep its route and client state aligned for the task’s duration. If a step fails, restarting the whole sequence may be more interpretable than continuing from a partially completed state.\n\n## The practical benefits and limits\n\nNeither mode wins every workflow. The useful question is whether the documented behavior matches the unit of work you defined.\n\n## The practical benefits and limits: tradeoffs\n\n### Where it helps\n\n- Rotation can give independent work explicit route-change boundaries when supported.\n\n- Sticky routing can request continuity across related steps.\n\n- A deliberate session label helps group sanitized operational observations.\n\n### What to account for\n\n- Neither setting manages browser cookies or application state.\n\n- A requested sticky period is not a promise that an unavailable exit will persist.\n\n- Connection reuse can make observed behavior differ from a per-request assumption.\n\n## Read an observation before changing a setting\n\nSuppose two independent requests show the same exit. That fact alone does not prove rotation is broken: check whether the provider rotates per connection, whether the client reused a connection, and whether a different exit was promised at that boundary. Conversely, a changed exit during a sticky task needs examination even if the HTTP status remained successful.\n\n## Read an observation before changing a setting: Record only what helps diagnosis\n\nKeep timestamps, a non-secret task/session label, the requested mode, the connection reuse pattern and the observed exit if your permitted endpoint reports it. Do not save the password or a credential-bearing proxy URL. A useful support record explains which boundary was expected to change the route.\n\n## Read an observation before changing a setting: Choose a recovery policy in advance\n\nDefine whether exit loss stops the task or triggers a fresh sequence. Keep retry counts bounded and distinguish reconnecting from changing the meaning of the measurement. A later report should show which outputs came from a restarted task rather than silently merging them.\n\n## Document the session for the next maintainer\n\nA routing choice should survive the person who configured it. Keep the provider’s documented boundary, the client reuse behavior and the task recovery rule with the integration notes. If the client library or gateway product changes, review those assumptions together. A session suffix copied from an old example is not a durable specification.\n\nKeep the description concrete: which steps belong to a task, which observation marks completion, and which failure requires a fresh sequence. That small handoff makes it easier to investigate a changed exit without guessing whether the behavior was expected.\n\n## MiProxy settings depend on the allocation\n\nUse the connection controls supplied for your allocation rather than constructing an undocumented username suffix. Session duration and exit availability depend on the selected product; verify the behavior your task requires.\n\n## Which approach should you choose?\n\nUse rotation for independent work and sticky routing for tasks that need continuity. Keep recovery rules explicit in both modes.\n\n### Each request is independent\n\nCheck the documented rotation boundary and verify observed behavior across the connection pattern your client actually uses.\n\n### Several steps belong together\n\nUse a supported sticky setting, preserve the necessary client state and decide how the task recovers if the exit changes.\n\n### You need a permanently assigned address\n\nReview a product’s explicit static-allocation terms; do not substitute a sticky-session label.\n\n## What does rotating proxies mean?\n\nIt means a proxy service changes the exit address at a supported boundary, such as a new connection or a configured interval. Check the provider’s documented behavior: rotation does not necessarily happen on every request, clear your client’s cookies, or guarantee a successful destination response.\n\n## Is a sticky proxy the same as a static IP?\n\nNo. Sticky routing requests the same exit for a period. Static products have separate allocation terms; neither should be inferred from the word sticky.\n\n## Does changing a session clear browser cookies?\n\nNo. Provider routing and browser storage are separate. Your application must manage its own cookies and task boundaries.\n\n## Does every HTTP request get a new exit IP?\n\nNot necessarily. Providers can define rotation at a connection boundary, an interval or another documented event. Client connection reuse can affect observations, so check the selected plan and actual client pattern.\n\n## What should happen if a sticky exit becomes unavailable?\n\nDefine a recovery rule for the task: stop, restart a safe sequence or preserve partial output for review. Do not assume the requested continuity period guarantees that an unavailable exit remains usable.\n\n## Sources\n\n- [Oxylabs: residential proxy session control — provider-specific semantics](https://developers.oxylabs.io/products/proxies/residential-proxies/session-control) — checked 2026-10-16\n- [Requests: advanced usage and proxies](https://requests.readthedocs.io/en/latest/user/advanced/#proxies) — checked 2026-10-16\n\n## Related reading\n\n- [Residential vs. datacenter proxies: choose by the job](https://miproxy.io/blog/residential-vs-datacenter-proxies)\n- [Use an authenticated proxy with Python Requests](https://miproxy.io/guides/python-requests-proxy-guide)\n- [How to use a proxy with cURL](https://miproxy.io/guides/curl-proxy-guide)\n- [Non-expiring proxy bandwidth: what to check before buying](https://miproxy.io/blog/non-expiring-proxy-bandwidth)\n- [Fix HTTP 407 Proxy Authentication Required](https://miproxy.io/guides/proxy-error-407)","score":1}],"links":["https://miproxy.io/AGENTS.md","https://miproxy.io/.well-known/agents.json","https://miproxy.io/llms.json","https://miproxy.io/llms.txt","https://miproxy.io/llms-full.txt","https://miproxy.io/rag","https://miproxy.io/rag.json","https://miproxy.io/feed.xml","https://miproxy.io/feed.json","https://miproxy.io/entities.json","https://miproxy.io/developers","https://miproxy.io/.well-known/mcp.json","https://miproxy.io/openapi.json"]}