Apify Custom Proxy Setup: Use Your Own Residential Route

Apify Proxy can supply managed routing, while an Actor may also use a proxy pool you own. The decision belongs at the Actor input or SDK configuration boundary. Your proxy controls the network path. Apify provides the execution platform and storage services; the Actor's implementation determines its parser, queue handling and output validation. Changing the proxy does not replace that application logic.

Check the Actor before changing its route

The Apify proxy guide and own-proxy guide make two boundaries explicit. In Console, custom proxy URLs are available only when the Actor's input schema exposes the Proxy and browser configuration section. In the SDK, proxy_urls or new_url_function supplies custom URLs to ProxyConfiguration. Read the specific Actor schema before designing a migration around an input field.

For a private SDK route check, the Python API supports a list of custom URLs and a session ID:

import asyncio
import os

import requests
from apify import Actor


async def main():
    async with Actor:
        proxy_configuration = await Actor.create_proxy_configuration(
            proxy_urls=[os.environ["PROXY_URL"]]
        )
        proxy_url = await proxy_configuration.new_url(session_id="catalog-page")
        response = requests.get(
            "https://example.com/",
            proxies={"http": proxy_url, "https": proxy_url},
            timeout=20,
        )
        if response.status_code != 200 or "Example Domain" not in response.text:
            raise RuntimeError("The route check did not return the expected page")
        print({"status": response.status_code, "has_expected_text": True})


asyncio.run(main())

The URL is read from the runtime environment and is never printed. Replace the fixed target with a permitted route-check endpoint or the first allowed item from the Actor. The snippet proves a response through the configured proxy for that request; it does not prove that every Actor request, redirect or parser result will be valid.

Keep the Actor result testable

Run one item before a batch and define the record contract first. For a product observation, that may be a product ID, price, currency and source timestamp. Store the Actor run ID, target URL, response phase and field validation result with the sample.

A run can be marked successful while its output is empty, a challenge page or the wrong record shape. A target denial can also leave the proxy configuration untouched. Record the failing phase before changing suppliers or retry policy.

Choose session behavior with the workload

Apify documents that the same session identifier can keep a proxy IP across connections, but session behavior depends on proxy type. Treat the provider's session lifetime as a variable to verify. A residential label alone does not establish the required continuity.

Price valid records, then decide

Apify's proxy product and your external pool sit in different billing boundaries. Compare traffic, failed attempts, retries and valid records for the same target slice. The raw proxy price is only one input when the Actor still performs parsing, queue work and storage.

Apify's proxy documentation restricts connecting to Apify Proxy from an external client to paid plans and applies external data-transfer charges. That is a different direction from an Actor connecting to your own proxy. For the latter, check the Actor's charges, applicable platform usage and your supplier's invoice separately; do not apply Apify Proxy's external-client restriction to every custom-proxy setup.

If the job needs a managed extractor, a raw proxy may leave too much application work in your Actor. Keep that choice separate from the question of whether your own route is technically accepted. For browser-specific routing, use the Playwright proxy guide.

Check the target's terms, robots guidance where relevant, rate limits and personal-data obligations before running the Actor. An external proxy changes transport and supplier control; it does not authorize collection.