A VLESS Tunnel for Your California Mobile Proxy

HTTP(S) and SOCKS5 cover most of what people do with a Los Angeles line, but some setups want a tunnel instead: a phone that should route everything through the line, a machine on a network that interferes with plain proxy ports, or a workflow built around an Xray client. For those, every California Proxies line can be exposed as a VLESS endpoint, and any Xray-compatible client turns it into a local SOCKS or HTTP listener, or a full-device tunnel on mobile. This guide shows the link format, a minimal client config, the client steps on each platform and the checks that prove the traffic is leaving from Los Angeles.

What VLESS gives you here

VLESS is the lightweight protocol used by Xray and its clients. On our side, the line's VLESS endpoint carries your traffic to the same SIM in the same Los Angeles device as the HTTP(S) and SOCKS5 ports; nothing about the exit changes. What changes is the client side: an Xray client speaks VLESS to the endpoint and presents a local proxy or a system-wide tunnel to your apps, so programs that cannot be given a proxy setting still exit through the line.

The pieces you need are in your dashboard on the line's page: a VLESS link that encodes the host, port, UUID and transport settings, and the same values listed separately in case your client wants them typed in. Treat the UUID as a password. If it leaks, regenerate it from the dashboard and the old link stops working.

The link, with placeholders

A VLESS link from the dashboard looks like the sample below. The parts in angle brackets are the values your dashboard shows for your line; nothing in the sample is a real host. Most clients accept the whole link pasted in or scanned from the QR code on the same page.

vless://<uuid>@<host>:<port>?encryption=none&security=<security>&type=<transport>&sni=<sni>#California-Proxies-LA

Minimal Xray client config

If you run Xray-core directly, for instance on a Linux box or a server that should forward a local SOCKS port through the line, a small config is enough. It opens a SOCKS listener on the local machine and sends everything to the VLESS endpoint. Replace the placeholders with your dashboard values and keep the file private because it contains the UUID.

1. Save the config as config.json next to the xray binary.
2. Start it with xray run -c config.json and leave it running.
3. Point an app or a browser at SOCKS5 127.0.0.1 port 10808.
4. Fetch an IP-echo page through it and confirm the address is a carrier address in Los Angeles or California.

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": { "udp": true }
    }
  ],
  "outbounds": [
    {
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "<host>",
            "port": <port>,
            "users": [ { "id": "<uuid>", "encryption": "none" } ]
          }
        ]
      },
      "streamSettings": {
        "network": "<transport>",
        "security": "<security>"
      }
    }
  ]
}

Client steps by platform

Graphical clients wrap the same config. The names differ by platform but the flow is identical: import the link, turn the connection on, choose whether the tunnel covers everything or only selected apps, then check the exit address.

1. Windows: install v2rayN, choose Add server from clipboard after copying the VLESS link from your dashboard, select the new entry, and enable the system proxy from the tray icon. Apps that honour the system proxy now exit through the line; others can be pointed at the local SOCKS port shown in the client.
2. Android: install v2rayNG, tap the plus icon and choose Import config from clipboard or scan the QR code from the dashboard, then tap the connect button. The app creates a VPN-style tunnel so every app on the phone exits through the line. Use the per-app setting if only some apps should go through it.
3. iOS: install Shadowrocket or Streisand from the App Store, add the server from the clipboard or the QR code, and toggle the connection on. As on Android, the device routes through the line.
4. macOS and Linux desktops: use the Xray-core config above, or a graphical Xray client of your choice that accepts a VLESS link, and point apps at the local listener.
5. On every platform, confirm the exit address once the connection is up before doing anything that matters.

Checks that prove it is working

The tunnel is only as good as the exit it produces, so verify the exit rather than trusting the client's connected status. Three checks cover it.

1. IP: load an IP-echo page. The address should be an AT&T, T-Mobile or Verizon address with a cellular connection type, placed in Los Angeles or California. If you see your own address, the client is connected but the app you used is not going through it.
2. DNS: run a DNS leak check. Resolution should happen through the tunnel, not through your local resolver. In Xray-core, add a dns section that routes queries through the outbound if the check shows your local resolver.
3. Rotation: trigger a rotation from the dashboard or the rotation link, reload the IP-echo page, and confirm the address changed while the tunnel stayed up. The tunnel does not need to reconnect for a rotation.

When to use VLESS and when not to

Use the tunnel when you need whole-device routing on a phone, when an app has no proxy setting, or when a network between you and the line mangles plain proxy ports. Use the ordinary HTTP(S) or SOCKS5 ports when an antidetect browser or a script can take a proxy directly, because that is simpler and one fewer moving part. Both paths exit from the same SIM; there is no trust or speed difference between them, and typical throughput stays at 20 to 45 Mbps on 4G and 50+ Mbps on 5G either way.

The consistency rule applies in full. A phone tunnelled through the Los Angeles line should have its clock on Pacific time and its language set to en-US like any other profile on the line. And the fair-use line is the same: the tunnel is for proxy work, not for moving bulk files, and there is no data limit for that work. If anything in this guide does not match what your dashboard shows, write to [email protected] or message @CaliforniaProxiesBot and we will walk you through it.

Frequently asked