Mobile Proxies in Apify: Setup, Geo Checks, and Debugging

What Apify is and why teams use it for data collection

Apify is a web automation and data extraction platform where your code (or a ready-made module) runs as an Actor. An Actor takes input, performs scraping/automation, stores outputs in built-in storage (Dataset, Key‑Value Store, Request Queue), and exposes results via API and integrations. This is useful for marketing and analytics teams that need repeatable runs, schedules, logs, and consistent output schemas.

Example use case: marketing collects public competitor data (catalog, prices, availability, attributes) to analyze assortment changes. A typical pipeline is Actor → Dataset → webhook to a downstream system (BI, spreadsheets, workflow tools).

When you need proxies for Apify and why dedicated mobile proxies matter

Teams use proxies for Apify to control IP origin and geography, reduce IP-based blocking risks, and verify localized content (language, currency, geo redirects). Dedicated mobile proxies (3G/4G/5G) are often chosen for quick proof‑of‑concept pilots and “mobile‑like traffic” checks, especially when the target site behaves differently for mobile networks.

Apify Proxy vs custom mobile proxies

• Apify Proxy: built-in proxy service (datacenter/residential/SERP) with platform-native session and country parameters.
• Custom proxies: your own third‑party proxies (including mobile) that you plug into runs or SDK configuration.

Proxy type	Strengths	Trade-offs	Best for
Datacenter	Fast, stable, cost-effective	Blocked more often on strict sites	Large-scale crawling on lighter targets
Residential	Often higher trust (ISP networks)	More expensive, session behavior varies	Strict e-commerce/catalog targets
Mobile	Mobile network “look and feel”, good for pilots	Highest cost, depends heavily on provider	Localization QA, mobile experiences

Where to configure proxies in Apify (profile level and run level)

Profile level: Apify Console → Proxy

At the account level, Apify Console has a Proxy page where you can see your Apify Proxy password and available proxy groups. The documentation notes that the proxy password is shown on that Console page.

Security note: Apify Proxy uses the HTTP proxy protocol, and the docs warn that the password is sent unencrypted due to protocol limitations. Treat it as a secret and avoid exposing it in logs. <

Run level: Actor “Input and options” → “Proxy and browser configuration”

For third‑party proxies, Apify recommends adding them per run/task: open your Actor run settings, scroll to Proxy and browser configuration, and paste your proxy URLs.

SDK level: ProxyConfiguration and session IDs

If you build custom Actors, proxy rotation and sticky behavior are managed via ProxyConfiguration (Crawlee / Apify SDK). You can generate proxy URLs based on a session ID to keep a consistent IP per session when needed.

Required fields: host, port, login, password, and protocol

Dedicated mobile proxy providers typically give:

• host (gateway hostname or IP)
• port
• login (username/sub-user)
• password
• protocol (usually http or https)

In Apify, you usually enter this as a single proxy URL:

http://LOGIN:PASSWORD@HOST:PORT

Item	What to store	Common mistake
Proxy URL	Full URL with auth	Logging credentials or using the wrong scheme (http vs https)
Geo/pool	Provider-side country/carrier settings	Assuming “country” implies “mobile ASN”
Sticky sessions	Provider mechanism or sessionId mapping	Not testing for unexpected IP changes

Validation: geo, ASN, and “no session jumps”

1) IP → Country

Use a diagnostic endpoint to confirm what the server sees. Apify provides /v2/browser-info that returns clientIp, countryCode, and request headers such as accept-language. Run a few checks through the same proxy/session before spending traffic on target sites.

2) ASN check (mobile vs hosting)

Country alone is not enough for “mobile”. Validate the IP’s ASN (Autonomous System) to see who operates the network (carrier/ISP vs hosting). You can use ASN datasets/services (e.g., IPinfo) or RIPEstat documentation for ASN-related lookups and country-ASN data.

3) Session persistence (sticky IP)

Repeat 3–5 diagnostic requests using the same session identifier and compare clientIp. If it changes without your intent, your session is not sticky (or the provider rotates aggressively). For Apify Proxy, the docs describe the session parameter behavior and note that session persistence depends on proxy type.

Why the country is right but the locale is wrong

Localization is multi-signal. Besides IP, sites may use:

• Accept-Language (server-side content negotiation).
• Browser timezone/locale (front-end logic).
• Cookies (stored country/currency choices).
• CDN geo (for example, Cloudflare can add CF-IPCountry based on its geolocation database).

For localization QA, aim for consistency: match IP geo + Accept‑Language + timezone, and test with clean sessions/profiles.

Debugging: proxy problem or site problem?

1. Validate your proxy on /v2/browser-info (IP, country, headers).
2. Try the same target without a proxy.
3. Try a different proxy type/ASN (mobile vs residential).
4. Check geo redirects and reduce concurrency (rate limiting).
5. If using Apify Proxy, be aware of their extended 59x status codes for upstream issues.

FAQ

Can I use my own mobile proxies in Apify?

Yes. Add them as Custom proxies in run settings or manage them via ProxyConfiguration in code.

How do I verify the proxy is really in the target country?

Route a diagnostic request through the proxy and confirm countryCode in the response. Repeat across multiple sessions.

Why do I need an ASN check?

Because “country” does not guarantee “mobile network”. ASN helps you confirm the network operator and understand block patterns.

Sources

• Apify Docs: Proxy usage; Using your own proxies; Actors running; Webhooks.
• MDN: Accept-Language header.
• Cloudflare: IP geolocation (CF-IPCountry).
• RIPEstat / IPinfo: ASN references.