Compatible apps · WPS technical guide

Which VPN apps does WLOC need—and why?

WLOC itself is not a VPN. Coordinate management works independently. A network-location response test additionally needs one compatible iOS network client to provide the local tunnel, host-scoped HTTPS inspection, and script runtime.

Open WLOC in the App Store Compare compatible apps

The App Store listing name is "WLOC". If a regional storefront opens instead, search "WLOC" in the App Store.

01WLOCTarget, profile, diagnostics, recovery

02Network clientLocal tunnel, rules, and scripts

03Apple WPSWi-Fi and cell location landmarks

04Core LocationFuses GPS, permission, and cache

Direct answer

The short answer: install one compatible client

Choose Shadowrocket, Surge 5, Quantumult X, Loon, Stash, or Egern; you do not need all six. WLOC manages target coordinates, setup profiles, status bridging, diagnostics, and recovery. The third-party client puts the matching rules into the iOS network path. Each client is independently supplied by its developer; WLOC does not sell, bundle, or imply endorsement by Apple or those vendors.

iOS network clients

Six currently supported clients and their profile formats

This compatibility map comes from WLOC's current profile generator and in-app walkthrough. Third-party versions, menus, and regional availability can change; verify against the vendor's current App Store listing.

Client and official listing	WLOC output	Connection method and note
Shadowrocket ↗	`wloc.module`	Import as a module, then enable HTTPS Decryption for the two listed Apple WPS hosts.The current in-app walkthrough uses this as the first validation path.
Surge 5 ↗	`wloc.sgmodule`	Subscribe to or import the Surge module and enable its MitM host list.Uses WLOC's native Surge-format output.
Quantumult X ↗	`wloc.conf`	Import the rewrite and MitM sections; both the script resource and host list must be active.Refresh the resource before diagnosing a stale script.
Loon ↗	`wloc.lpx`	Install the URL as a plug-in, enable it, then configure the plug-in certificate path.Keep the plug-in and script resource current.
Stash ↗	`wloc.stoverride`	Subscribe to the .stoverride directly and enable its scripts and MitM scope.Do not convert this file through Script Hub.
Egern ↗	`wloc.sgmodule`	Use the Surge-format module, then generate and trust Egern's own CA for the scoped hosts.Egern reuses the Surge output; WLOC does not generate a separate file for it.

Already use one of these clients? Install WLOC, then copy the official wloc.app setup URL that matches your selected client from inside the app.

Open WLOC in the App Store

VPN ≠ IP location

The word “VPN” here does not automatically mean changing IP

These clients commonly use the iOS VPN or Network Extension path to process local rules, so iOS may show a VPN indicator. That does not mean WLOC sends all traffic to a remote VPN server.

Component	What it does	What it does not do
WLOC	Stores targets, generates matching profiles, triggers the status bridge, and presents diagnostics and recovery.	Does not create a VPN tunnel, change public IP, install a CA, or write GPS hardware.
Compatible network client	Creates the local network path, loads rules, and runs host-scoped HTTPS inspection and response scripts.	Is not part of WLOC; its permissions, pricing, privacy, and runtime state belong to its vendor.
Remote VPN or proxy service	If separately configured, may change the network exit IP or transport path.	Is not required by WLOC, and IP region is not the same switch as a coordinate target.

End-to-end path

Six steps from a target coordinate to a network-location result

Each step can fail independently. WLOC records bridge, request, patch, and passthrough evidence instead of treating the VPN icon as proof.

01Save targetWLOC stores a WGS84 coordinate on-device

02Import profileThe client loads its matching format

03Start network pathiOS may show a VPN indicator

04Scope HTTPSInspect only the Apple WPS hosts

05Handle responsePatch coordinate fields in compatible records

06Verify and restoreCheck the target app, then clear to passthrough

Wi-Fi Positioning System

Why a network response can influence some location results

An iPhone's final location does not come only from GPS. Apple's current documentation says Location Services can combine cellular, Wi-Fi, GPS, and Bluetooth; a Wi-Fi Positioning System uses nearby access points as location landmarks.

Current public boundary

Core Location is multi-source fusion, not one GPS switch

Apple's current support documentation says Location Services can use cellular, Wi-Fi, GPS, and Bluetooth, and that devices augment a crowd-sourced Wi-Fi hotspot and cell-tower database. Network location is therefore only one input into a final result.

Strong outdoor GPS, Bluetooth beacons, app permission, and Precise Location can change the final result.
A target app may add cache, IP region, account state, and server-side risk decisions.
A successful patch does not mean every app must display the target.

Paper and historical record

BSSIDs act as landmarks; the service returns coordinates for on-device computation

A 2024 IEEE S&P paper reports an experimental Apple WPS model in which a device submits nearby Wi-Fi access-point BSSIDs, receives coordinates for those and nearby landmarks, and computes or caches the result locally. Apple's archived 2010 letter also described devices receiving known nearby cell-tower and Wi-Fi access-point locations and combining them with GPS when available.

A BSSID identifies a Wi-Fi access point radio interface; it is not the network name or SSID.
The 2010 letter is historical disclosure, not a complete or immutable 2026 private-protocol specification.
The paper also documents serious privacy and mass-collection risks around Wi-Fi location databases.

WLOC implementation

Patch compatible coordinate records when a target exists; pass through when it does not

WLOC's response script recognizes compatible Wi-Fi, cell, and location records inside an Apple WPS binary response, then replaces latitude, longitude, and accuracy fields with the current target or route node. Clearing the target stops replacement and leaves the response untouched.

An independent experiments repository presents /clls/wloc, protobuf framing, and Wi-Fi or cell queries as reverse-engineering findings.
That endpoint is not an Apple public API promised stable for third-party use; fields and behavior may change without notice.
WLOC cannot change satellite signals, clear the system locationd cache, or override a target app's server decisions.

High-trust operation

Why CA trust is required—and why it is sensitive

Apple WPS traffic uses HTTPS. To inspect and change that response on-device, the compatible client must decrypt HTTPS for the scoped hosts, which requires generating a local CA, installing its profile, and manually granting full trust in iOS. That is a high-privilege operation, not a risk-free switch.

Use only on devices, accounts, apps, and networks you own or have explicit permission to test.
Keep the hostname scope to gs-loc.apple.com and gs-loc-cn.apple.com; never enable catch-all decryption for convenience.
Do not install an unknown certificate, share the CA private key, or retain it on a primary device carrying sensitive production accounts.
After testing, clear the WLOC target, disable the profile and HTTPS inspection, revoke system trust, and remove the certificate or VPN configuration when no longer needed.
WLOC does not install or remove a third-party client's CA and cannot audit how that client handles other traffic.

Diagnostics

Match each symptom to the layer that can cause it

Separating client, certificate, rule, WPS response, and target-app failures is more useful than repeatedly toggling everything.

Symptom	Likely layer	Next check
No VPN indicator or the client is disconnected	The local network path is not running.	Check the selected client's connection, active profile, and iOS VPN permission.
The HTTP status bridge works but HTTPS says Not found	The profile loaded, but HTTPS decryption, CA trust, or hostname scope is inactive.	Check the client switch, full system certificate trust, and the two scoped hosts.
No /clls/wloc request is observed	The rule missed, a resource is stale, the host bypasses the client, or the scenario did not trigger WPS.	Refresh the profile, inspect bypass rules, then trigger a low-risk map lookup.
The patch succeeds but the target app stays real	GPS, permission, cache, IP, account, or server rules dominate the network-location result.	Review target-app permission and timing, reopen the app, and test IP separately from coordinates.
The target is cleared but an app shows the old place	The target app or iOS still has cached state.	Confirm passthrough and fully reopen the target app; WLOC cannot clear locationd for iOS.

Common questions

Not working, restoring real location, and GPS dominance

Identify the failing layer before reopening an app, refreshing permission, or restarting the device. A VPN indicator alone is not proof of success.

Not working?

The log says “patched,” but Maps does not move

WLOC supports Apple Maps, Google Maps, Amap, and Baidu links plus direct coordinate text. Successful parsing only proves the target is usable; the device path must still confirm the client, HTTPS, a WLOC request, and a response patch in that order.

1
Check the client
Confirm the VPN indicator, selected profile, scripts, and scoped hosts are active.
2
Check the HTTPS bridge
If HTTP works but HTTPS says Not found, CA trust, HTTPS inspection, or the host list is not active.
3
Check the latest request
The latest WLOC request timestamp must change. Restarting cannot repair a rule that never matched.
4
Check the patch timestamp
Only a new coordinate-patch timestamp and statistics move the investigation to permission, cache, and GPS.

Method one · Permission and app refresh

Turn off Location Services and fully quit the map or authorized target test app.
Choose and save the point in WLOC, then confirm new target and request evidence.
Turn Location Services on. If iOS offers it for the target app, choose Ask Next Time Or When I Share on the next request.
Reopen the target app. Airplane Mode can isolate a test, but toggling it alone is not treated as a cache clear.

Method two · Patch confirmed but location is stale

Save the target and confirm both the latest WLOC request and coordinate-patch timestamps changed.
If permission refresh and reopening do not help, restart the authorized test device.
After boot, restore connectivity, start the compatible client, confirm its VPN indicator, and enable Location Services.
Open Maps or the target app and keep the diagnostic timeline as evidence.

Cancel the test target

How to restore real location

First stop and clear any active route in WLOC, then use Restore Real Location or clear the device target. This removes the persistent wloc_settings value. With no valid route or module fallback coordinate, the response script enters passthrough and leaves the Apple WPS response unchanged.

Recommended · Restore inside WLOC

Stop and clear any running route.
Use Restore Real Location or clear the device target.
Run diagnostics, confirm passthrough, and look for a new passthrough timestamp.
Reopen the target app; restart only if its display remains stale.

Alternative · Disable the complete profile

Disable or remove the WLOC profile, plug-in, module, or Override.
Turn off its HTTPS inspection and remove the CA or VPN configuration when no longer needed.
Reopen the target app and confirm real location.
On newer systems, restart after confirming the profile is inactive if stale state remains.

Advanced fallback: clear wloc_settings directly

Prefer WLOC's restore action. If the status bridge is unavailable, clear the static target inside the matching script environment:

Surge / Loon
$persistentStore.write(null, "wloc_settings")

Quantumult X
$prefs.removeValueForKey("wloc_settings")

These commands clear only the static target; they do not stop a running route. Shadowrocket, Stash, and Egern menus or script environments may vary by version, so prefer reimporting the official profile or restoring inside WLOC.

Capability boundary

Network location only; GPS hardware is unchanged

Easier to observe

Indoor or weak-sky-view environments where Wi-Fi or cellular positioning participates and the authorized target app uses Apple's network-location result.

May be overridden

Strong outdoor GPS, Bluetooth beacons, app cache, account or server rules, or an app that does not use this network response.

Testing note

Keep a usable network connection when testing Wi-Fi WPS. Turning Wi-Fi off may reduce network-location triggers and is not a universal success step.

Primary · research · experimental

Sources, separated by what they can prove

These sources answer different questions. Current Apple documentation defines the public boundary; the archived letter and paper explain the model's evolution; GitHub is independent experimental evidence only.

Current primary source

Apple: About privacy and Location Services (May 25, 2026)

Open the source ↗

Current troubleshooting source

Apple: If Maps isn't working on your Apple device (May 15, 2026)

Open the source ↗

Historical primary source

Apple response to Representatives Markey and Barton (July 12, 2010, archived)

Open the source ↗

Peer-reviewed research

Rye and Levin: Surveilling the Masses with Wi-Fi-Based Positioning Systems (IEEE S&P 2024)

Open the source ↗

Independent reverse engineering

acheong08/apple-corelocation-experiments on GitHub

Open the source ↗

Research boundary: WLOC cites independent reverse engineering to explain a possible private-protocol structure. It does not describe /clls/wloc as an Apple public API or promise future compatibility.

Authorized testing only

Before-you-start checklist

01
Confirm that the device, network, app, and account are yours or explicitly authorized for testing.
02
Choose one compatible client and obtain it from its official App Store listing.
03
Use a public, low-risk point for the first static-target run in WLOC.
04
Limit certificate inspection to the two Apple WPS hosts and record how to revoke it.
05
Verify one active state, one passthrough state, and real location after reopening the target app.

FAQ

Compatible apps and principles FAQ

Is WLOC itself a VPN?

No. WLOC manages coordinates, profiles, diagnostics, and recovery. A compatible third-party client creates the iOS network path.

Do I need Shadowrocket, Surge, Quantumult X, and every other listed app?

No. Choose one currently supported client and use its matching wloc.module, wloc.sgmodule, wloc.conf, wloc.lpx, or wloc.stoverride output.

Do I need a remote VPN or proxy subscription?

WLOC itself does not require a remote VPN subscription. The selected client may have its own purchase, feature, or service terms; WLOC needs its on-device rule loading, scoped HTTPS inspection, and script runtime.

Why does iPhone show a VPN icon?

A compatible client may process local rule traffic through the iOS VPN or Network Extension path. The icon shows that a network path is active; it does not prove that the WPS rule, certificate, or patch succeeded.

Does the VPN icon mean my public IP location changed?

Not necessarily. WLOC provides no remote network exit and does not change IP. Only a separately configured remote service might affect public IP.

Why must I trust a certificate?

The target response is HTTPS. Inspecting and changing that encrypted response for scoped hosts requires a local CA and system trust. This is sensitive access: restrict the hosts, use a test device, and revoke it after testing.

Which map links and coordinate input does WLOC support?

WLOC supports Apple Maps, Google Maps, Amap, and Baidu links plus direct latitude-longitude text. It identifies the source coordinate system and normalizes the internal target to WGS84.

Why does Maps stay unchanged on iOS 26 or iOS 27 after the log says patched?

First confirm that both the latest WLOC request and patch timestamps changed. A VPN icon or status bridge alone is not proof, and restarting cannot repair an inactive profile, certificate, or rule. If the patch is confirmed, refresh the target-app permission and reopen it; restart the authorized test device only if stale state remains. Apple does not publish a WLOC-specific iOS 26/27 cache or mandatory-restart rule, so this is troubleshooting guidance, not a version guarantee.

How do I cancel the test target and restore real location?

Stop and clear any active route, use WLOC's restore action to remove wloc_settings, and confirm passthrough. The current official profile does not use 113.94114, 22.544577 as a pass-through sentinel; a valid fallback coordinate in module arguments or a running route can keep replacement active.

Will this make every app show the same location?

No guarantee. GPS, Bluetooth, cellular, permission, cache, IP, account, and server rules still matter, and some apps may not use this network-location result at all.

How do I remove the complete setup?

Clear the WLOC target and confirm passthrough; disable or remove the client profile and HTTPS inspection; revoke and delete its CA profile; remove the VPN configuration if no longer needed; then reopen the target app and verify real location.

WLOC

Choose one compatible client, then start with a low-risk test you can reverse

Install WLOC, choose a public point, follow the in-app steps for your selected client, and complete one save, diagnose, clear, and certificate-revocation cycle.

Open WLOC in the App Store Continue to the complete technical model →