Will the SOCKS5 tunnel also route DNS through the phone, or just HTTP traffic?

SOCKS5 routes DNS through the phone — that is the whole reason we recommend SOCKS5 over HTTP for mobile QA. You see exactly the same DNS resolution your real users see, including carrier-side DNS rewrites, captive portals and content filters. An HTTP proxy, by contrast, resolves DNS on the proxy server, not on the carrier network.

Can the iOS simulator on macOS use a Nodetonet SOCKS5 proxy?

Yes. Set the SOCKS5 proxy at the macOS network level (System Settings → Network → your Wi-Fi → Details → Proxies → SOCKS Proxy). The iOS simulator inherits the host machine's proxy settings. For Xcode UI test runs, you can also inject the same config via simctl on the command line.

Does the Android phone running the Nodetonet agent need to be rooted?

No. The agent runs as a regular foreground service and uses Android's VPNService API to capture traffic without root access or a custom ROM. We test on stock Pixel, Samsung One UI, Xiaomi MIUI, and stock AOSP builds from Android 11 onwards.

How do I run tests on multiple carriers automatically?

Create one SOCKS5 proxy per device (each bound to a different phone), then loop over the proxy URLs in your test runner script. The shell example on this page shows the pattern: set ALL_PROXY to each proxy URL in turn, run your test suite, and collect a JUnit report per carrier. Wire the script into GitHub Actions, Jenkins or any CI tool for automatic per-carrier regression on every commit.

My app uses certificate pinning. Will a SOCKS5 proxy break it?

No. A SOCKS5 proxy tunnels the raw TCP connection and does not intercept TLS. Certificate pinning checks the TLS certificate of the actual server, which is unaffected. Your app will still validate the pin correctly; you just get the carrier IP and carrier-resolved DNS as the exit, which is exactly what you need for geo-IP and carrier-quirk testing.

Is the billing per gigabyte, like residential proxies?

No. Nodetonet uses prepaid credit, not a per-gigabyte meter. You pay for what you use and idle proxies cost nothing. For a QA workload — typically a few gigabytes of test traffic per week — the cost is much lower than an equivalent residential proxy plan. See pay-as-you-go pricing for a full breakdown.

Can I test geo-IP features for cities, not just countries?

Yes. With geo-targeting modifiers you can target a specific city (such as Istanbul) in your proxy username without changing the endpoint. Pair that with a device physically located in that city and your test traffic exits from the exact metropolitan IP range the city's users see. See geo-targeting for the full syntax and available modifiers.

Nodetonet for mobile app testing — real carrier IPs, real device DNS, real test conditions

Most mobile-app bugs are not bugs in your code. They are bugs that only appear on a real cellular network: a Vodafone CGNAT timeout that kills long-polling, a Türk Telekom DNS interceptor silently rewriting your SDK calls, a T-Mobile MTU clamp that shreds TLS handshakes mid-session, or a geo-fenced feature that the simulator's "Set Location" menu cannot trigger because the backend checks the exit IP, not GPS coordinates.

You can buy a SIM in every country your app ships to — expensive, slow, and impossible to automate. Or you can pair an Android phone with Nodetonet, point your dev laptop at it as a SOCKS5 exit, and run your entire test suite with traffic emerging from real Türk Telekom IPs — from the same desk where you write code. That is what this page is about.

Why the iOS simulator cannot replace a real carrier connection

Three classes of bugs are systematically invisible in simulators and staging environments:

Geo-IP gated features. "Show Turkish pricing only when the user is in Turkey." Your simulator's locale spoof does not change the IP your API sees. The feature simply never activates. You ship, and real users in Turkey see a broken onboarding screen.
Carrier-specific network quirks. CGNAT port-mapping timeouts that kill long-polling after 30 seconds. MTU values that break post-quantum TLS during handshake. DNS interception that rewrites api.yourcompany.com to a transparent proxy silently removing headers. None of these exist on your office Wi-Fi — and none show up in your staging logs.
Operator content filters. Mobile carriers in Turkey, India and Indonesia route certain destinations through national-level content filters. If your CDN sits on a flagged netblock, half your users get timeouts — and you only find out from one-star reviews three days after launch.

The table below summarises what each testing environment can and cannot catch:

Test environment	Geo-IP gating	Carrier DNS / MTU quirks	Operator content filters	Real CGNAT behaviour	Automation-friendly
iOS / Android simulator	No	No	No	No	Yes
Physical device on office Wi-Fi	No	No	No	No	Partial
Physical device on local carrier SIM	Local carrier only	Local carrier only	Local carrier only	Yes (local)	Hard
Nodetonet mobile proxy (SOCKS5)	Yes — any carrier	Yes — DNS through phone	Yes — real egress	Yes	Yes — scriptable

How Nodetonet fits into a mobile QA workflow

You pair an Android phone with the Nodetonet agent. The phone becomes a named, controllable exit on a real cellular SIM. From your dev laptop you create a SOCKS5 proxy bound to that device: anything you send to localhost:1080 exits through phone-istanbul-vodafone-01. Your curl, your Postman collection, your CI integration tests, your iOS simulator pointed at a local DNS — they all appear to the world as a Turkish Vodafone subscriber.

The critical detail: DNS also resolves through the phone when you use SOCKS5. If Türk Telekom's transparent resolver rewrites api.yourapp.com, your test runner sees exactly what real users see. That is not something an HTTP proxy gives you — HTTP proxies resolve DNS on the proxy server, not on the carrier network. SOCKS5 is the right choice for faithful network-layer simulation.

You are not limited to one exit. With token groups you can pool several phones — one Vodafone TR, one Turkcell TR, one T-Mobile DE — and let your CI pipeline hit each in turn. If a device goes offline, the failover rule promotes the next one automatically, with no test-suite changes. See automatic failover for mobile proxies for the setup.

Need to target a specific carrier or city in your proxy username? The geo-targeting modifier system lets you append -country-tr, -carrier-vodafone or -city-istanbul without changing the endpoint. Read more about specific carrier networks: Vodafone TR, Türk Telekom, Turkcell.

Step-by-step setup (5 steps)

Create an account. Sign up at /auth/register and add a small prepaid credit balance — a few dollars covers weeks of QA usage.
Install the agent on the phone. Download the Android agent from /download and pair it with a token. Keep the phone on the carrier you want to test against: Vodafone TR, T-Mobile DE, EE UK, and so on.
Create a token per exit. On the Tokens page, create a token per phone with a descriptive name (phone-vf-tr-01, phone-tm-de-02). This is the identifier your test harness will reference. See your first token and Android pairing for a guided walkthrough.
Create a SOCKS5 proxy per token. On the Proxies page, create a SOCKS5 proxy bound to each token. SOCKS5 — not HTTP — so DNS resolves through the phone. Add per-proxy authentication (username and password) and optionally an IP allowlist so only your CI runner can connect. The SOCKS5 with authentication guide covers the options.
Point your test runner at the proxy. iOS simulator: System Settings → Network → Wi-Fi → Details → Proxies → SOCKS Proxy. Android emulator: -http-proxy flag at launch (emulators support SOCKS5 via emulator -http-proxy socks5://…). Headless scripts: set ALL_PROXY or pass the proxy URL directly to your HTTP client library.

Automating multi-carrier regression in CI

The real payoff comes when you wrap your integration test suite in a per-carrier loop and wire it into your CI pipeline. The script below runs your tests through each regional exit in sequence and writes a JUnit report per carrier — so your dashboard shows pass/fail per network:

#!/bin/bash
# Run integration tests through every regional exit we have paired.
# Each EXIT is a SOCKS5 proxy URL created on the Nodetonet panel.

EXITS=(
  "tr-vodafone|socks5://tok_vf_tr:secret@panel.nodetonet.com:11080"
  "de-tmobile|socks5://tok_tm_de:secret@panel.nodetonet.com:11081"
  "uk-ee|socks5://tok_ee_uk:secret@panel.nodetonet.com:11082"
)

for entry in "${EXITS[@]}"; do
  name="${entry%%|*}"
  proxy="${entry##*|}"
  echo "Testing on ${name} via ${proxy}"
  ALL_PROXY="${proxy}" npm run test:integration -- --reporter junit > "results-${name}.xml"
done

Drop that into a GitHub Action triggered on every pull request and you have per-carrier regression coverage at zero manual effort. When a carrier-specific bug appears, the failing test report tells you exactly which network broke and which did not. For a deeper look at managing many proxies from code, see bulk operations for managing proxies and your first REST API call.

Per-proxy controls for QA environments

Nodetonet gives each proxy its own access controls, which is useful when sharing a QA fleet across a team:

IP allowlist. Lock each proxy to your CI runner's IP so a leaked credential cannot be abused. See IP allow and deny lists.
Thread limits. Cap the number of concurrent connections so a runaway test suite cannot saturate the device. Covered in thread limits per client.
Quota and expiry. Assign a data quota or a hard expiry date to any tester's proxy credentials. See quota limits per client.
Sticky sessions for stateful flows. Append -session-XXXX to your proxy username to pin the same IP for the duration of a checkout or login test. Details in sticky sessions explained.

You can also use our free proxy checker to verify that each exit is live and returning the carrier IP you expect before kicking off a long test run.

When this approach is not the right fit

You only need to test on your local carrier. A real device on a real SIM at your desk gives faster feedback for that single network. Use Nodetonet for the carriers you do not have on hand.
You are testing on-device sensors (camera, accelerometer, push notifications, battery state). A proxy changes the network egress, not the hardware. Test sensors on a physical device; use Nodetonet for the network-layer and geo-IP pieces.
Your app uses certificate pinning. A SOCKS5 proxy does not intercept TLS — it tunnels the raw TCP connection. Certificate pinning continues to work exactly as intended, which is fine: you still get the correct carrier IP and DNS, just not a TLS inspection point. If you need to MitM your own app's TLS for debugging, use a dedicated tool like mitmproxy alongside the SOCKS5 tunnel.

Get started

Create a free account, pair one phone, and point your simulator at it. Most teams find their first carrier-specific bug within the first hour. For a broader picture of what mobile proxies can do, read what is a mobile proxy or explore the full feature set. Questions? Reach us on Discord or email.