How to set up a mobile proxy on iPhone (Wi-Fi proxy settings, step by step)

Your mobile proxy works fine on your laptop. Then you pick up your iPhone, open Settings, and you have no idea where any of it goes. There’s no “proxy” app and no obvious menu. The one setting that does exist is buried three screens deep inside your Wi-Fi network.

The good news is that the basic setup takes about thirty seconds and you don’t need to install anything. The bad news is that there are three places where it quietly breaks, and almost nobody tells you about them until you’ve already been caught out.

I run a mobile proxy farm here in Singapore. Real 4G and 5G modems with real SIM cards on Singtel and M1, more than 300 of them. I connect iPhones to these lines all the time, for my own testing and when I’m helping someone get set up, so I’ve hit every one of those traps myself. Everything in this guide works on a normal iPhone. Nothing to jailbreak, no developer tools, no profile from a stranger.

This is the long version of the video. I’ll walk through the mobile proxy settings on iPhone step by step, show you how to prove it worked, and then spend real time on the parts that fail without telling you, because that’s where people lose an afternoon.

The short answer

If you only need the verdict, here it is. The iPhone gives you three ways to use a mobile proxy, and each one fits a different job.

The order of operations never changes, whichever route you pick. Get your four details from your provider. Choose the route. Use the HTTP port for the built in setting. Then check the exit IP inside the exact app you’re going to use, before you do anything that matters.

If you remember nothing else, remember that last step. I’ll come back to it more than once, on purpose.

What your provider gives you: four details

Before you touch a single setting, look at what your provider actually sent you. It’s always the same four things: a host, a port, a username and a password.

Often they arrive squashed into one long line, in the shape host:port:username:password. Something like this, with made-up values:

sg.example-proxy.com:10432:user8841:p4ssw0rdX

Split that line into its four pieces before you open Settings. The iPhone asks for them in separate boxes, and trying to paste the whole line into one box is the first mistake I see people make.

The host is the address your phone connects to. It’s a hostname or an IP, and it stays the same. The port picks your line, and often the protocol too. On my setup every line has two ports, one for HTTP and one for SOCKS5. The username and password prove the connection is yours, and without them the proxy refuses you.

Hold those four in your head, because every method in this guide uses them. The only thing that changes between routes is where you type them.

If you’ve got two ports for the same line, label them clearly in your notes as “HTTP” and “SOCKS5”. You’ll need the HTTP one for the built in iPhone setting, and mixing them up is one of the traps later on. If the difference between the two protocols is still fuzzy, I’ve written up SOCKS5 vs HTTP proxies separately.

Why put a Singapore mobile IP on an iPhone at all

Most of the people I help with iPhone setups are doing one of a few things.

The first is testing an app the way a real Singapore user sees it. If you build or market an app for this region, you want to see the onboarding, the content and the error messages that a person on a Singapore phone network gets. A desktop on office fibre is a different picture.

The second is checking how local search results and ads look from here. Search pages and ad placements change by location and by network. If you’re responsible for a campaign aimed at Singapore phone users, seeing it through a Singapore carrier connection on an actual phone is the honest way to check it. I go deeper on that in using a mobile proxy for ad verification.

The third is simpler. You’re somewhere else, and you want to see the Singapore version of a site from a phone. Maybe you’re travelling, or your team sits in another country and needs to review what local visitors get.

All of these have something in common. The phone is the point. You want to see what a person on a phone in Singapore sees, on the same kind of network they’re on. That’s why a mobile IP on a real carrier is the right tool here, rather than whatever address your home router happens to have.

It’s also why I keep saying “check inside the app you’ll use”. If the whole reason for the exercise is to see what one app shows a Singapore user, then a test in a different app proves very little.

Why the iPhone beats Android for the basic setup

Here’s something I didn’t expect when I started setting up phones: for the basic route, the iPhone is actually easier than Android.

On Android, the built in Wi-Fi proxy setting only has a host box and a port box. There’s no username field and no password field. So when you point it at a paid proxy that needs a login, the proxy just refuses the connection. That missing pair of fields is why so many Android guides end with “now go and install this app”. I covered the Android side in setting a mobile proxy on Android without root if you run both.

The iPhone has both fields right there. Turn on Authentication and you get a Username box and a Password box. So for a basic setup, the built in route genuinely works with the login your provider gave you, and with no extra software.

That doesn’t make the built in route perfect. It still has real limits, and I’ll be blunt about them further down. But you can get a working Singapore mobile IP in Safari in under a minute, which is a nice place to start.

The same steps work on an iPad, and on older versions of iOS the menus barely move. The path is always Settings, Wi-Fi, the (i) icon, Configure Proxy.

Step by step: the built in Wi-Fi proxy

Let’s do it properly. Have your four details ready, split into separate pieces.

1. Open Settings and tap Wi-Fi. Make sure you’re connected to the network you actually want to use, because this setting belongs to one network.
2. Tap the small blue (i) on the right of the network name. Tapping the name itself just tries to reconnect.
3. Scroll all the way to the bottom. There’s a section called HTTP Proxy with one row, Configure Proxy, and right now it says Off.
4. Tap Configure Proxy and pick Manual. I explain why in the next section.
5. Type your host into Server, exactly as your provider wrote it. No http:// in front, no slashes, and no space at the end.
6. Type your port into Port. Use the HTTP port, not the SOCKS5 one.
7. Switch on Authentication. Two more boxes appear, Username and Password.
8. Fill in both, check them once, then tap Save in the top right corner.

If Save stays grey, one of the boxes is still empty. Go back and look for the one you missed.

A word on that trailing space in step 5. Copy and paste on a phone loves to grab an extra space at the end of a selection, and the Server box won’t trim it for you. One stray space is enough to make the whole thing fail. If you can, type the host by hand. It’s short.

That’s the whole built in setup. Safari and most of Apple’s own apps will now go out through your proxy, on this one Wi-Fi network. No app, no profile, nothing installed. Honestly, it takes longer to explain than to do.

If you can’t find the HTTP Proxy section at all, you’re almost certainly looking at the wrong screen. Go back to the Wi-Fi list and make sure you tapped the (i) next to the network with the tick.

Manual or Automatic: which one to pick

When you tap Configure Proxy, iOS offers Manual and Automatic as well as Off. Most people should pick Manual, and here’s why.

Automatic doesn’t mean “work it out for me”. It asks for the URL of a PAC file. A PAC file is a small script, hosted somewhere, that tells the device which proxy to use for which address. Companies use it to steer office traffic, with rules like “send this site through the proxy, send everything else direct”.

Most mobile proxy providers don’t hand you a PAC URL. They give you the four details we just used. So if you never received a link ending in something like .pac, you want Manual. If you’re not sure, ask your provider.

There’s one more reason I prefer Manual for testing. When something goes wrong, you can see every value in front of you. With Automatic, the actual proxy details live inside a file you can’t read from the phone, so troubleshooting turns into guesswork.

If you do have a PAC file from a company IT team, that’s a different situation, and you should follow their instructions rather than mine. This guide assumes the normal case: one proxy, four details, Manual.

Check that it actually worked

Now prove it worked, because a proxy that silently failed looks exactly like one that worked. Safari loads pages either way. Nothing on the screen tells you which connection it used.

Stay on the exact same Wi-Fi network you just set up. Open Safari and load any “what is my IP” page.

You want a Singapore address, and you want the owner to be a mobile carrier. On my lines that means Singtel or M1. Some of these pages show the network owner or an “ISP” line, and it should read like a phone company. It shouldn’t be your home broadband provider, and it shouldn’t be a cloud hosting name.

If that’s what you see, you’re done with the basic route. The proxy is live on this network, in Safari.

If the page shows your own normal IP, the proxy isn’t being used at all. The usual causes are that you’re on a different Wi-Fi network from the one you configured, or the phone has dropped to mobile data. Check the Wi-Fi icon at the top of the screen first.

Here’s the habit I’d like you to build from day one. Do this check inside the app you’re actually going to use, not just in Safari. A pass in Safari tells you the system proxy is working. It doesn’t tell you every app is using it, because some apps skip the setting entirely.

It takes five seconds. It has saved me more times than I can count.

When the check fails: logins, relays and cafe Wi-Fi

Most failed checks fall into a handful of patterns. Here’s how I work through them.

If the page won’t load at all, or Safari keeps asking you to log in, the username or password is wrong. Go back to the (i) screen, delete both, and retype them by hand. Pasted credentials are the usual culprit, again because of that extra space. Also check you didn’t swap them around.

If the page spins for a long time and then gives up, it’s usually the wrong port. If you typed the SOCKS5 port into the Server and Port boxes, it fails exactly like this, with no error message. Swap in the HTTP port. It can also be a typo in the host, so look closely at every character.

If you see an address that belongs to Apple’s relay partners instead of Singapore, that’s iCloud Private Relay doing its own routing in Safari. Turn Private Relay off while you test, then reload the page. You’ll find it under your Apple account settings, in iCloud.

Hotel and cafe Wi-Fi has its own snag. A lot of public networks want you to tick a box on a login page first. With the proxy already switched on, that page may never appear, so you’re stuck. Do things in order: join the network, get through the login page, and only then turn the proxy on.

If the proxy settings have vanished, you probably tapped Forget This Network at some point. The setting is stored with the network, so forgetting the network deletes the proxy too. You’ll be typing the details in again the next time you join.

If the connection works but keeps dropping, that’s a different problem from setup, and I’ve covered the common causes in why a mobile proxy keeps disconnecting.

Trap one: it only exists on one Wi-Fi network

Now the three places this setup quietly breaks. This is the part that burns people, so I’ll take each one slowly.

The first trap is that the proxy lives on one Wi-Fi network and nowhere else. It isn’t a phone-wide setting. Join a different network and it’s simply not there. Your home Wi-Fi, the office and the cafe down the road each need their own setup, entered by hand. Drop to 4G or 5G and the proxy is gone too.

That last part surprises people the most. There is no proxy box for mobile data on a normal iPhone. You can look through every screen under Mobile Data and you won’t find one. Only a company managed, supervised device can have a cellular proxy pushed to it, through a configuration profile from the organisation’s device management system. Your personal phone doesn’t get that option.

Here’s how it plays out in real life. You set everything up at your desk and the check looks great. Then you walk out the door, the Wi-Fi drops, and every app is quietly back on your own connection. No warning, no banner, nothing on screen. If you were halfway through a test, everything after that point came from the wrong network.

So treat the built in proxy as a desk tool, for a check on one network rather than a phone you carry around. If you move networks, redo the IP check before you carry on. If the work has to continue on mobile data, skip ahead to the proxy client route, because that’s what it’s for.

Nothing is broken when this happens. The setting is doing exactly what Apple designed it to do. It just wasn’t designed for a phone on the move.

Trap two: the built in setting only speaks HTTP

The second trap is the protocol. The iPhone’s built in proxy setting is HTTP only. There’s no SOCKS5 option anywhere on that screen, no toggle, no dropdown.

If you type a SOCKS5 port into the Server and Port boxes, it will just fail. The phone won’t warn you either. There’s no “wrong protocol” message. The page spins for a while and then gives up, which looks exactly like a dead proxy. It isn’t one.

Most providers, including me, give every line two ports, one for HTTP and one for SOCKS5. The line behind them is the same modem and the same SIM. The ports only change how your device talks to it.

So the rule is easy. In the built in iPhone setting, always use the HTTP port. Save the SOCKS5 port for an app that understands SOCKS5, like a proxy client.

Why have SOCKS5 at all, then? It’s a lower level protocol that can carry more kinds of traffic than HTTP proxying, and some tools work better with it. On a phone, you’ll mostly use it inside a proxy client app, which I’ll get to shortly.

If you’ve been sent only one port and you’re not sure which protocol it is, ask your provider before you start guessing. On my dashboard each line shows both ports side by side, labelled, for exactly this reason.

Trap three: some apps skip the setting

The third trap is the sneaky one. The built in proxy is a request, not a rule.

Safari respects it, and so do apps built on Apple’s own networking. But some apps open their own connections and skip the system proxy completely. That usually means apps built with their own networking code. From the outside, you can’t tell which ones they are. There’s no label in the App Store and nothing in Settings.

The worst part is that the settings screen still says Manual the whole time. You look at it and think you’re covered. Meanwhile one app is quietly going out on your real address, and the only way you’d ever know is to check the IP inside that app.

Your hotspot has the same blind spot. If you share your iPhone’s connection with a laptop through Personal Hotspot, the proxy doesn’t travel with it. The laptop goes out on the phone’s mobile connection, which has no proxy, as we covered in trap one. If you want the laptop on the proxy, set the proxy on the laptop itself.

So, to sum up the built in route honestly. It’s great for one job: a quick browser check on one Wi-Fi network. It won’t follow you onto mobile data, it won’t take SOCKS5, and some apps ignore it. That’s still useful, as long as you know where the edges are. For anything that has to hold up, move the proxy out of iOS settings and into an app that carries it itself.

The better route: a proxy client app

The cleanest way to run a mobile proxy on an iPhone, for anything beyond a quick check, is a proxy client app.

The app sets up a local tunnel on the phone, using the same system iOS uses for VPNs. It catches the traffic from your apps, then forwards it to your proxy with the username and password attached. You add your proxy once inside the app, pick HTTP or SOCKS5, enter the four details, and switch it on.

You’ll see a little VPN badge at the top of the screen. That’s normal, and it confuses a lot of people the first time. You’re not sending your traffic to some VPN company. The app just uses Apple’s VPN system locally on the phone, so it can catch every app’s traffic and send it to your proxy.

That one move fixes all three traps at once. The app doesn’t care which network you’re on, so the proxy follows you onto mobile data. It speaks SOCKS5 as well as HTTP, so you can use whichever port suits the job. And because it works at the tunnel level, apps with their own networking code get routed too.

If you use SOCKS5 in a client, look for the option that sends DNS lookups through the proxy as well. If your lookups still happen on the phone, they leak out on your own connection, even while the traffic itself looks proxied. Your IP check will pass, but the phone is still asking its own network where every site lives.

One catch with these apps. An iPhone only runs one VPN style connection at a time. If you already use a VPN app, switching the proxy app on turns the other one off, and the other way round. You can’t stack them, so pick one per job.

Choose a client from a developer you trust, and read what it asks permission for. I’m not going to name a specific app here, because the App Store changes and I’d rather you pick one that’s current and well reviewed when you read this.

The simplest route: the proxy field in your tool

The third route is the tool you already work in. Plenty of browsers and testing apps have their own proxy field, separate from the system setting.

Paste the host, port, username and password straight into that field, and the tool carries the proxy itself. Like the proxy client, this works on mobile data too, because it doesn’t depend on any Wi-Fi network.

If most of your work happens inside one app, this is the simplest route of the lot. Nothing else on the phone changes. Your messages and email don’t need to go through Singapore just because one browser does. You can also swap proxies per session without ever opening iOS settings.

When you set it up, check which protocol the field supports, since some tools only take HTTP and some take both. Also check there’s a username and password box. If there isn’t, it can’t use a proxy that needs a login, and you’ll need a different route.

The same rule applies here as everywhere else. Wherever the proxy lives, do your IP check inside that same tool. A pass in Safari doesn’t promise a pass in another app.

Habits for day to day use

Once it’s working, a few small habits make the difference between a setup you trust and one that surprises you.

On my lines you can rotate to a fresh IP from the dashboard or through the API. When you do, Safari can hang on to the old connection for a moment, so your next check might show the previous address. Close the tab, or switch Wi-Fi off and on, then check again.

If you’re working through a multi-step test in one app, you want the same address from start to finish. Sticky sessions keep your IP steady until you choose to rotate. The tradeoffs between the two modes are in sticky vs rotating mobile proxies.

Expect it to feel a little slower than your own line. Every request now takes a trip through a modem in Singapore before it reaches the site. Judge it by how real pages load, not by a speed test app, because some of those test the phone’s own connection directly.

When you finish testing, go back and set Configure Proxy to Off. Otherwise, the next time that proxy changes or your plan ends, Safari on that network just stops loading, and you’ll spend ten minutes wondering why your home Wi-Fi is broken. I’ve done this to myself more than once.

Keep your four details somewhere safe, like a note in your password manager. Between forgotten networks and new apps, you’ll type them in more often than you expect.

Which route should you use

It depends on the job, and most people end up using more than one.

For a quick browser check on one Wi-Fi network, the built in setting is fine. For anything on mobile data, use a proxy client app or the proxy field inside your tool, because the built in setting simply doesn’t exist there. Anything that needs SOCKS5 goes in a proxy client, with DNS sent through the proxy. If the result depends on one specific app, a proxy client is the safer bet, because it catches apps that skip the system setting. And if your work lives in one browser, that browser’s own proxy field keeps everything else on the phone untouched.

Whichever you pick, the order is the same. Get your four details and split them up. Pick the route. Use the HTTP port in the built in setting. Then check the exit IP inside the exact app you’re going to use.

Check the IP inside the app you’re about to use, every single time. Five seconds, and you’ll never wonder again whether that test really came from Singapore.

Try it on a real Singapore mobile line

If you want real Singapore mobile IPs for this, that’s what I do. Over 300 4G and 5G modems with real SIM cards on Singtel and M1. Every line comes with an HTTP port for the iPhone’s built in setting and a SOCKS5 port for a proxy client. Sticky sessions keep your IP steady while you work, and you can rotate from the dashboard or the API when you want a fresh one.

Your traffic exits on a real Singapore carrier, the same way it would for someone browsing on their phone on the MRT.

There’s a free trial of Singapore Mobile Proxy so you can run the whole setup above on your own iPhone and see a Singtel or M1 address in Safari within a few minutes. Use the code YT30 for thirty percent off your first month.

Get new guides and videos first — join the Telegram channel.