How to set up a mobile proxy on Mac (macOS proxy settings, step by step)

Your mobile proxy works fine on your phone. Then you sit down at your Mac, open System Settings, and there’s no “Proxy” item anywhere in the sidebar. The page you need exists, but it’s three clicks deep inside your network connection, behind a button most people never press.

The good news is that the setup takes about two minutes and you don’t need to install anything. The bad news is that there are four places where it quietly fails, and the labels on the screen don’t help. One of them catches nearly everyone the first time, me included.

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 set up Macs on these lines every week, for my own testing and when I’m helping someone get started, so I’ve walked into every one of those traps myself.

This is the long version of the video. I’ll walk through the Mac proxy settings step by step, show you how to prove it worked, then spend real time on the parts that fail without telling you. Everything here uses the current System Settings app. If your Mac is older, I’ll point out where the menus differ.

The short answer

If you only need the verdict, here it is. On a Mac there are three places a mobile proxy can live, and each fits a different job.

The order of operations never changes. Get your four details. Pick the network service you’re actually using. Fill in both Web proxy and Secure web proxy with the HTTP port. Then check the exit IP in the exact app you’re going to use.

If you remember one thing, make it “both switches”. One without the other is the mistake I fix most often.

What your provider gives you: four details

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

Often they arrive as one long line with colons between the pieces, something like this (made-up values):

sg.proxy-host.example:8000:user-sg01:yourpassword

Split that into four pieces first. The Mac asks for them in separate boxes, and pasting the whole line into the Server box is a surprisingly common first mistake.

The host is the address your Mac connects to. The port picks your line, and often the protocol as well. The username and password prove the connection is yours. Without them, a paid proxy just refuses you.

Most providers, including me, give every line two ports: one for HTTP and one for SOCKS5. Same modem, same SIM, same exit IP. The port only changes how your Mac talks to it. For the system settings on a Mac, you want the HTTP one, and I’ll explain why in a minute. Write both down and label them clearly, because mixing them up is behind a good share of “it doesn’t work” messages I get. I’ve written more on what each port is for in mobile proxy setup with HTTP and SOCKS5 ports.

Why bother with a Singapore mobile IP on a Mac at all? The people I help usually want to see their own site the way a local visitor sees it, check how local search results and ads look from here, or test prices and pages that change by country. All three are about seeing what someone in Singapore sees, on the same kind of network they’re on.

Before you start: the Mac is friendlier than the iPhone

If you’ve already been through setting up a mobile proxy on iPhone, the Mac will feel generous.

On the iPhone, the built in proxy is a single HTTP box hidden inside one Wi-Fi network, and it doesn’t exist at all on mobile data. On the Mac you get a separate switch for each kind of proxy, a password option on each one, and it works on a cable as well as on Wi-Fi.

That extra choice is also where the Mac trips people up. There are several switches, the names sound more technical than they are, and the one you need second is easy to skip. So take the next two sections slowly once, and after that it’s a two minute job.

You’ll also want to know which network connection you’re actually using right now. macOS calls each connection a “service”. Wi-Fi is one service, Ethernet is another, and a USB or Thunderbolt adapter, or a phone plugged in by cable, shows up as its own service too. Proxy settings belong to a service, not to the whole Mac. Hold on to that, because it comes back as one of the traps.

Step by step: open the proxy settings

Here’s the path on any recent version of macOS (Ventura and later), which use the System Settings app.

1. Open the Apple menu and choose System Settings.
2. Click Network in the sidebar. You’ll see a list of your services, each marked connected or not.
3. Click the service you’re actually using right now. For most laptops that’s Wi-Fi.
4. On the Wi-Fi page, find the network you’re connected to and click the Details button next to its name.
5. A panel opens with its own list down the left side. Click Proxies.

If you’re on a cable, it’s the same idea: Network, then Ethernet, then Details, then Proxies.

On older Macs (Monterey and earlier) the app was called System Preferences. The path there is Network, pick the service on the left, click Advanced, then open the Proxies tab. The fields inside are almost the same. The one real difference is that after clicking OK you also have to click Apply on the main Network screen, or nothing changes. I’ve watched people fill everything in perfectly and then close the window without pressing Apply.

If you can’t find Proxies at all, you’re most likely in the wrong place: the Wi-Fi item at the very top of the sidebar is a shortcut that also has Details, and either route gets you to the same panel. What matters is that you open Details for the network you’re connected to.

Step by step: Web proxy and the password

The Proxies panel shows a column of switches, each a different kind of proxy. The two you’ll use are Web proxy (HTTP) and Secure web proxy (HTTPS). Above them sit two automatic options, and further down there’s a SOCKS proxy switch plus a couple of older types. The exact list varies a little between versions.

Leave the two automatic options off. Auto proxy discovery asks the network to hand the Mac a proxy, and Automatic proxy configuration wants the address of a PAC file, a small script companies use to steer office traffic. Most mobile proxy providers don’t give you either. If you never received a link to a .pac file, you don’t need them.

Now set up the first proxy:

1. Switch on Web proxy (HTTP).
2. Type your host into the Server box. Just the host: no http:// in front, no slashes, no space at the end.
3. Type your HTTP port into the port box beside it.
4. Turn on Proxy server requires password.
5. Type your username and password into the boxes that appear.

Type the host by hand if you can. Pasted text loves to carry an invisible trailing space, and one stray space is enough to make the whole thing fail.

Don’t click OK yet. You’re halfway, and the next switch is the one that matters most.

Trap one: the Secure web proxy switch

Here’s the trap that catches almost everyone. The Web proxy switch only covers plain HTTP pages. Nearly every site you’ll visit today is HTTPS, and those go through the second switch, Secure web proxy.

Fill in only Web proxy, run a quick test, and you’ll see something confusing. A few old pages go through Singapore, but most of your browsing goes straight out on your own connection. The settings look correct, which makes it worse.

So:

1. Switch on Secure web proxy (HTTPS) as well.
2. Fill it in with exactly the same host.
3. Use the same HTTP port as before.
4. Turn on the password option and enter the same username and password.

The name is what trips people up. “Secure web proxy” sounds like it wants a special secure port, or an encrypted connection to the proxy. It doesn’t. “Secure” here describes the websites, the HTTPS ones, not the proxy. Your browser still talks to your proxy the same way and asks it to open a tunnel to the secure site. So both switches take the same HTTP port.

If your provider gives you an HTTP port and a SOCKS5 port, put the HTTP port in both of these. Keep the SOCKS5 port for tools that ask for SOCKS5 by name.

Trap two: leave the SOCKS switch off

Trap two is the SOCKS proxy switch sitting right below. It’s tempting to fill it in too, since you’ve got a SOCKS5 port and it seems like more coverage. For browsing, leave it off.

The reason is Chrome. Chrome on a Mac follows the system proxy settings, but it doesn’t support a SOCKS proxy that needs a username and password. If the system says “use this SOCKS proxy” and that proxy wants a login, Chrome can’t supply it, and pages fail. Since you need a login with a paid mobile proxy, a SOCKS entry in the system settings causes more trouble than it solves.

The HTTP port in both Web proxy and Secure web proxy is the setup that works in Safari, Chrome and most Mac apps. It covers ordinary web traffic, which is what most people are trying to test.

SOCKS5 still has a place. It’s a lower level protocol that some tools prefer, and it can carry DNS lookups through the proxy when the tool supports it. Use it inside a tool that asks for SOCKS5 by name and has its own login fields, like Firefox’s manual settings, curl or an automation script. If the difference between the two is still fuzzy, I’ve covered it in SOCKS5 vs HTTP proxies.

The exceptions list, then OK

Further down the Proxies panel there’s a box listing hosts and domains that skip the proxy. On most Macs it already contains entries like *.local and 169.254/16. Leave those alone. They keep printers, file shares and other devices on your local network reachable directly, which is what you want.

You can add your own entries, separated by commas. A company intranet, a local test server, anything you’d rather reach on your own connection. Everything not on the list goes through the proxy.

There’s also an option to exclude simple hostnames, meaning single word names with no dots, which on most networks are local machines. Turning it on is harmless for most people, and I usually leave it as it was.

Now click OK. That’s the setup. Safari, Chrome and most Mac apps now send their web traffic through your proxy, on this network service.

The Mac stores the proxy password in your keychain. Even so, some browsers pop up their own box asking for the proxy’s username and password the first time. That’s normal. Type the same login in, and it should stop asking.

If you prefer the command line, there’s a built in tool called networksetup that sets the same values:

networksetup -listallnetworkservices
networksetup -setwebproxy "Wi-Fi" sg.proxy-host.example 8000 on user-sg01 yourpassword
networksetup -setsecurewebproxy "Wi-Fi" sg.proxy-host.example 8000 on user-sg01 yourpassword

Use the service name exactly as the first command prints it. Bear in mind that a password typed into a command ends up in your shell history, so I’d only do this on a Mac that’s yours.

Check that it actually worked

Now prove it worked, because a proxy that silently failed looks exactly like one that worked. Pages load either way, and nothing on screen tells you which route they took.

Stay on the same network service you just configured. Open a fresh private window, so old tabs and saved logins don’t muddy the result, and load any “what is my IP” page.

You want a Singapore address that belongs to a mobile carrier. On my lines that’s Singtel or M1. Many of these pages also show the network owner, sometimes labelled ISP or organisation. 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 system route.

If you want to see what the Mac itself thinks is configured, open Terminal and run:

scutil --proxy

It prints the proxy settings the Mac is using right now. You’re looking for the HTTP and HTTPS entries, each enabled, each with your host and port. If only HTTP shows as enabled, you’ve hit trap one.

Here’s the habit I’d like you to build from day one. Do the IP check inside the app you’re actually going to use. A pass in Safari tells you the system setting works. It doesn’t tell you that Firefox, a Terminal script or some other app is using it, and as you’ll see in trap four, several don’t.

When the check fails

Most failed checks fall into a few patterns.

A login box keeps popping up. If Chrome or Safari asks for a username and password, that’s the proxy asking. Type the same login. If it keeps coming back, the password is wrong somewhere. Go back to Proxies and retype it by hand in both Web proxy and Secure web proxy, watching for a stray space.

Pages spin and never load. Check the port before anything else. The most common cause I see is the SOCKS5 port typed into the Web proxy boxes. The Mac won’t warn you about a protocol mismatch; it just waits and gives up. Swap in the HTTP port, click OK, and reload. Then look at every character of the host.

Some sites show Singapore, most show your own IP. That’s trap one. Secure web proxy is off or filled in differently from Web proxy.

Everything shows your own IP. The proxy isn’t being used at all. Usually you’ve set it on one service while the Mac is using another, which is trap three below. Check which service in the Network list is actually connected.

Something else entirely shows up. If a VPN app is running, it can change how traffic leaves the Mac. Turn it off while you test, so you know what you’re measuring.

If the setup is right but the connection keeps dropping out after a while, that’s a different problem, and I’ve gone through the common causes in why a mobile proxy keeps disconnecting.

Trap three: one service, one location

Here’s the trap that burns people because everything still looks fine. The proxy belongs to one network service, not to the whole Mac.

Set it on Wi-Fi, then plug in an Ethernet cable or a USB adapter, and that new connection has no proxy at all. Each service needs its own setup, entered separately.

Docks are where I see this most. You set the proxy on Wi-Fi at your desk and the check passes. Later you plug into a dock with a network port. The Mac quietly prefers the cable, because wired services usually sit above Wi-Fi in its priority order, and now everything goes out raw. Wi-Fi is still connected, its proxy settings are still there, and nothing on screen tells you the traffic has moved. The same happens if you plug your phone in by cable to share its connection, because that shows up as another service.

The fix is one of two things. Either set the proxy on every service you use, or change the service order so the one with the proxy sits on top. The order lives in the small action menu at the bottom of the services list on the Network page (on older Macs it was under the gear icon).

Settings also belong to a location. A location is a saved set of network settings for all your services. Switch to another location and you get a different set, with or without a proxy. You’ll find locations in that same action menu on the Network page.

That’s useful as well as a trap. Some people keep a “Proxy” location and a normal one and flip between them, which is a neat way to turn everything on or off in one go. Just remember which location you’re in before you trust a test.

One case that confuses people works the other way. If your Mac joins your iPhone’s Personal Hotspot over Wi-Fi, that’s still the Wi-Fi service, so a proxy you set on Wi-Fi still applies. Your traffic goes from the Mac, over the phone’s own mobile data, to the proxy in Singapore, and the IP check shows the proxy’s address, not your phone’s. It only breaks when the phone is plugged in by cable, because then it’s a different service with no proxy on it.

Trap four: Terminal and Firefox don’t always follow

The last trap: the system setting is a request, not a rule.

Safari and Chrome respect it, and so do most normal Mac apps that use Apple’s networking. But curl and most Terminal tools ignore it, and Firefox can be set to use its own settings instead. Some apps with their own networking code skip it too, and from the outside you can’t tell which ones.

In Terminal, you set the proxy with environment variables:

export https_proxy="http://user-sg01:[email protected]:8000"
export http_proxy="$https_proxy"
curl https://example.com

Note that the address starts with plain http://, even for https_proxy. That’s describing how curl talks to the proxy, which is the same HTTP port as before. If your password contains characters like @ or :, they need to be URL-encoded or curl will misread the address.

Those variables only last for that Terminal window. Close it and they’re gone. For a single command, curl also takes -x with the same address:

curl -x "http://user-sg01:[email protected]:8000" https://example.com

If you’d rather use the SOCKS5 port with curl, use the socks5h:// scheme. The “h” tells curl to send DNS lookups through the proxy too, rather than resolving names on your Mac.

In Firefox, open Settings, stay on General, scroll down to Network Settings and click the Settings button there. By default Firefox uses the system proxy settings, so it follows whatever you set in System Settings. You can also pick manual proxy configuration and enter the host and HTTP port, then tick the option to use the same proxy for HTTPS. Firefox asks for the username and password in a pop up the first time you load a page. For SOCKS5 in Firefox, look for the option to proxy DNS when using SOCKS v5.

The sturdier route: the proxy field in your tool

For a quick browser check, the system settings are fine. For anything that has to hold up, I’d move the proxy out of macOS settings and into the tool you actually work in.

Plenty of browsers, testing tools and automation scripts have their own proxy field. Paste the host, port, username and password straight in. Nothing else on the Mac changes, your email and chat don’t go through Singapore just because one test does, and each tool can have its own line. A dock or a second network service doesn’t knock it off either, because the tool carries the proxy itself.

This is also where the SOCKS5 port earns its keep. A tool with its own SOCKS5 fields handles the login itself, so Chrome’s limitation doesn’t apply. Pick the option that sends DNS through the proxy too. If lookups stay on the Mac, they leak out on your own connection, even while the pages themselves look proxied.

There’s a quieter benefit too. When the proxy lives in the tool, a test that passes today still passes tomorrow, even if you’ve changed networks, docked the laptop or switched locations in between. When the proxy lives in the system settings, every one of those changes is a chance for traffic to slip out on your own line without you noticing.

If you drive a browser from code, the same idea applies there. I’ve written up how to do it with Selenium in setting up a mobile proxy with Selenium.

Wherever the proxy lives, do your IP check inside that same tool. A pass in Safari doesn’t promise a pass in Terminal, Firefox or a script.

Habits for day to day use

A few small habits make the difference between a setup you trust and one that surprises you.

Rotating. On my lines you can rotate to a fresh IP from the dashboard or through the API. When you do, your browser can hang on to the old connection for a moment, so the next check may still show the previous address. Close the tab or restart the browser, then check again. If you’re working through a multi-step test and want the same address throughout, sticky sessions keep it steady until you choose to rotate. The tradeoffs are in sticky vs rotating mobile proxies.

Speed. Expect it to feel a bit slower than your own line, because every request now takes a trip through a modem in Singapore. Judge it by how real pages load, not by a speed test app, which may test the Mac’s own connection directly.

Turning it off. When you’re done, go back to Proxies and switch Web proxy and Secure web proxy off. Otherwise the next time those details change, every browser on the Mac just stops loading and you’ll spend ten minutes thinking your Wi-Fi is broken. With networksetup it’s -setwebproxystate "Wi-Fi" off and -setsecurewebproxystate "Wi-Fi" off. Or, if you set up a separate location, switch back to your normal one.

Keep your details safe. Store the four details in your password manager. You’ll end up typing them again 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 look at a site in Safari or Chrome, the system settings are fine, as long as both Web proxy and Secure web proxy are on with the HTTP port. For anything in Terminal, use environment variables or curl’s -x. For SOCKS5, or anything that has to stay on one line no matter which network the Mac is on, put the proxy in the tool itself.

Whichever you pick, the order is the same. Get your four details. Pick the service you’re really using. Fill in both switches with the HTTP port. Then check the exit IP in the exact app you’ll use.

And if you only remember one thing: switch on both. One without the other looks like it worked, and that’s exactly why it’s the mistake I fix most often.

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 Mac’s system settings and a SOCKS5 port for tools that want it, with username and password login. 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 Mac and see a Singtel or M1 address in a few minutes. Use the code YT30 for thirty percent off your first month.

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