Add a Pixel VPN by Google path as an OpenSurge outbound

Expose the phone VPN without replacing it

Google's current Pixel feature is named VPN by Google; the older VPN by Google One service was discontinued. On an eligible Pixel and account, enable the built-in VPN first, then run a LAN proxy app. Pixel Proxy Gateway is the recommended open-source, ad-free option for a monitored always-on gateway; Every Proxy is a simpler alternative.

Pixel Proxy Gateway intentionally does not implement Android VpnService, leaving the system VPN slot available. By default it listens on HTTP port 8080 and SOCKS5 port 1080 on all interfaces, with authentication disabled. Give the phone a stable LAN address and enable credentials when the LAN is not fully trusted.

Keep the phone outside its own proxy loop

Prefer a topology where the Mac can reach the Pixel but the Pixel does not depend on OpenSurge as its default gateway—for example, both on the Mac's upstream Wi-Fi with the Pixel on a DHCP reservation. If the phone sits inside the managed downstream LAN, keep its address and private networks DIRECT and verify the phone VPN's own control path does not return through the Pixel outbound.

• Reserve a stable Pixel IPv4 address.
• Confirm the Mac can reach the selected HTTP or SOCKS5 port.
• Keep the Pixel address and LAN/private ranges direct.
• If known, keep the phone VPN server or control endpoints outside the Pixel route.

Merge the LAN node into the imported mihomo profile

Export an editable copy of the current source from the OpenSurge Sources page, merge the proxy and group into its existing proxies and proxy-groups sections, and place targeted rules above the existing terminal MATCH rule. Replace the example Pixel address and candidate names; do not replace a working subscription with this abbreviated sample.

SOCKS5 is the better starting point when the workload may need UDP, but udp: true is a capability request, not proof that the app, VPN, and final exit carry every UDP or QUIC flow. HTTP is appropriate for TCP and CONNECT traffic and should not be described as a full UDP path.

proxies:
  - name: "Pixel-Google-VPN"
    type: socks5
    server: 192.168.1.23
    port: 1080
    udp: true
    # username: your-user
    # password: your-password

proxy-groups:
  - name: "Pixel-Egress"
    type: select
    proxies:
      - "Pixel-Google-VPN"
      - DIRECT

rules:
  # Keep the phone and private LAN reachable without a proxy loop.
  - IP-CIDR,192.168.1.23/32,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  # Put targeted rules above the existing terminal MATCH rule.
  - DOMAIN-SUFFIX,anthropic.com,Pixel-Egress
  - MATCH,DIRECT

proxies:
  - name: "Pixel-Google-VPN-HTTP"
    type: http
    server: 192.168.1.23
    port: 8080
    # username: your-user
    # password: your-password

Import, route, and prove the exit

Import the edited local YAML as a draft, require structural validation to pass, then set it for the next start or apply it with a controlled reload. The Pixel node can be used by a global group or selected as the fixed or switchable egress for the Claude Code device template from the companion guide.

First compare the Mac's direct public IP with a request sent explicitly through the phone proxy. Then generate real traffic from the intended downstream device and confirm the OpenSurge connection view reports the expected device route and Pixel outbound. A listener health check proves reachability; only the observed public IP or the real service path proves the VPN exit you expected.

curl --proxy socks5h://192.168.1.23:1080 https://api.ipify.org
# HTTP alternative:
curl --proxy http://192.168.1.23:8080 https://api.ipify.org