FARMTroubleshoot PhoneFarm proxy and network failures
Identify proxy parsing, authentication, protocol, country and phone-side routing problems, then separate network failures from app and account issues.
Network troubleshooting becomes much easier when you identify where the request starts. Your desktop browser connects to PhoneFarm. PhoneFarm live control connects you to a phone. Apps inside that phone use the phone's configured internet route. A failure in one path does not prove the others are broken.
Use this guide when proxy verification fails, the phone screen works but apps cannot load, or a previously working phone loses internet access. If you cannot obtain a responsive screen at all, start with live-control troubleshooting.
Decide which of these three cases you have
Setup has never passed proxy verification. Focus on the supplied endpoint, credentials, protocol, country and phone-side verification result. Do not begin with TikTok password resets.
The phone used to work and now cannot load anything. Focus on what changed: proxy expiry, credentials, supplier access rules, service availability or the phone's current route.
General internet access works, but one app fails. Focus on the app's message, installation and account session after confirming a basic page loads. A verification challenge is not the same as a total network outage.
Understand what each network check proves
| Check | What it establishes | What it does not establish |
|---|---|---|
| Supplier dashboard says proxy active | The supplier considers the product available | That this phone can authenticate and use it |
| Proxy works from your laptop | Your laptop can reach the endpoint using that test | That the cloud phone uses the same route |
| PhoneFarm shows Proxy verified | Setup verified the configured phone-side route at that time | That the supplier will remain available indefinitely |
| A page loads inside the phone | The phone currently reaches that destination | That every app, domain or login is working |
| TikTok opens its intended profile | The app and account session are usable for that inspection | That a later publishing task cannot encounter a new prompt |
Work from the failing result rather than treating any one green status as a universal health check.
If verification fails: inspect the connection fields
Open the proxy setup for the original phone. Compare Type, Host, Port, Username and Password with your supplier's instructions.
Protocol mismatch
A scheme-free pasted line defaults to HTTP. If the service requires SOCKS5, use socks5:// in the line or select SOCKS5 in Type. HTTP, HTTPS and SOCKS5 are connection protocols; they are not interchangeable labels.
Host and port formatting
The host should be the proxy endpoint, not the supplier's website or a complete URL pasted into the hostname field. Put the port in Port. Watch for spaces or an extra colon introduced when copying a line from an email or spreadsheet.
Username and password
Proxy authentication details may differ from your supplier website login. Copy the endpoint credentials exactly. Some services encode country or session options in the username, so removing a suffix can change the route or invalidate authentication.
If punctuation makes the one-line format ambiguous, enter the fields individually. Do not paste credentials into a public IP checker or a support screenshot to test them.
Check the supplier's access requirements
Confirm that the subscription or allocation is active, that the endpoint allows the required protocol, and that any traffic or data allowance is available. A hostname can still resolve even when the supplier refuses authenticated traffic.
Check whether the service uses username/password authentication, source-IP allowlisting, or both. An allowlist containing only your office IP can explain why a laptop test works while a cloud phone fails. Ask the supplier how to use the endpoint from the PhoneFarm environment rather than guessing which address to allow.
For PhoneFarm's setup route, use a dedicated residential or ISP proxy in the selected phone country. A generic rotating pool may not meet the same requirement. The network setup guide explains the product terms and expected fields.
Investigate a country or network-type rejection
Confirm the phone's selected country, then compare it with the proxy product and its actual routing configuration. A supplier name or a country code in a file label is not proof of the exit being used.
PhoneFarm checks the phone-side exit and rejects a mismatched country or an exit identified as likely datacenter/hosting for this setup flow. If your supplier says the connection is residential but verification disagrees, preserve the message and ask for the endpoint to be checked. Repeatedly submitting the same unchanged credentials does not resolve conflicting classification.
IP geolocation databases can disagree. Capture the observed country and test time so the discrepancy can be investigated. A city's label in one IP lookup is not precise GPS evidence. Do not change several unrelated phone settings merely to force one third-party score to look better.
If setup passed but the phone has no internet now
Open a browser inside the phone and try a simple page. If it fails, try one unrelated destination. This distinguishes a single site's issue from broader connectivity without needing a large test sequence.
Review recent changes: was the proxy renewed, its password reset, its country changed, its IP allowance edited or its service suspended? Was the phone working immediately before the change? Keep the sequence clear.
If multiple phones are affected, group them by shared supplier or configuration. If all affected phones share the same proxy service while other phones work, report that pattern. If only one phone fails, preserve its specific reference and connection history. Do not replace every fleet connection because one endpoint failed.
Where the dashboard exposes a supported connection repair or re-verification action, use it for the affected phone. If the needed change is not available, ask support to help with that phone rather than creating another billable phone as a workaround.
If websites work but TikTok does not
Read the app's actual screen. “Enter a verification code,” “log in again,” a content restriction and an endless loading spinner describe different problems.
An explicit login challenge goes to account-login troubleshooting. A missing or failed app install belongs to the app installation flow. A post-specific error goes to publishing troubleshooting.
Do not diagnose low video views as a networking failure. Once content is confirmed published, distribution depends on other factors as well. Check the account's notices and the content's performance separately.
A useful recovery order
- Identify whether the failure is in setup, general phone internet or one app.
- Correct any verified input error, such as the wrong protocol or expired credentials.
- Re-run the relevant supported connection check once.
- Test the actual phone against a simple page and the app you need.
- If the same failure persists, send the phone reference, time, error and observed checks to support.
Keep the endpoint password private. A useful support report can say “HTTP, dedicated ISP endpoint, expected country US, verification fails after binding” without exposing a reusable secret. Include whether another phone on the same supplier works.
When recovery succeeds, repeat the original failed action. A passing setup badge is useful, but opening the required app on the actual phone is the practical confirmation that your workflow can continue.