XRay in Google Cloud Run: bypassing subnet blocks

Deploying XRay on Google Cloud Run to Bypass Subnet Blocks

Blocking entire provider subnets makes DPI easier but causes massive collateral damage. Instead of sophisticated detection, providers resort to blanket bans on /16 and /8 ranges, freezing connections after 16 KB or killing TLS entirely. Analysis reveals impacts on hundreds of ASNs, blocking millions of IPs. Workarounds include deploying in unblocked subnets of major providers or using domain fronting.

Reality and Simple Alternatives

XTLS-Reality is overkill without active probing: VLESS with a self-signed cert and domain spoofing delivers the same effect. It works even with CDNs that support custom certs. For TLS blocks, go with gRPC for VLESS or XHTTP with multiplexing.

Deployment on Google Compute Engine

Spin up an e2-micro instance (0.25 vCPU, 1 GB RAM) in Compute Engine:

• Pick the cheapest region.
• Use a standard disk without backups.
• Allow HTTP/HTTPS traffic.
• Stick with ephemeral IPv4.

Install XRay and configure VLESS Enc with Reality Seed to thwart packet size analysis. SNI google.com sails through since the IP is from Google's AS.

Cost Optimization with Cloud Run: On-Demand Containers

Switch to serverless with Cloud Run to cut costs:

• Head to Cloud Run > Services > Deploy web service.
• Image: docker.io/teddysun/xray.
• Region: Tier 1, closest one.
• Container port: 8080.
• Resources: 128 MB RAM, 1 CPU (minimum for >1 connection).
• Scaling: 0–1 instance, request-based billing.
• Ingress: all, timeout 3600s, concurrency 100+.

Mounting Configuration

Create a secret in Secret Manager with your config.json and mount it as /etc/xray/config.json.

Sample config for XHTTP (sniffing disabled):

{
  "log": {
    "loglevel": "info"
  },
  "inbounds": [
    {
      "port": 8080,
      "protocol": "vless",
      "tag": "pxy",
      "settings": {
        "clients": [
          {
            "id": "4c3fe585-ac09-41df-b284-70d3fbe27773",
            "email": "user1"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "xhttp",
        "xhttpSettings": {
          "path": "/secreturlxx"
        }
      },
      "sniffing": {
        "enabled": false
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ]
}

On the client: XHTTP with XMUX (maxConnections=1, maxConcurrency=0). Container startup takes 1–2 seconds.

Domain Fronting in Google's Infrastructure

Connecting to google.com resolves to a Google IP, but Host points to your *.run.app—requests route internally within the AS. Certs issue correctly for any Google service (HTTPS/QUIC). This isn't spoofing like Reality: traffic flows through real Google infrastructure.

Client config uses server=google.com, SNI=google.com, Host=xxxxxxxxx.run.app.

Limitations and Scaling

• Needs a foreign card and residency verification.
• Costly: emergency option for 1–2 users.
• Trial: $200 for 3 months.

For >1 connection load, deploy a proxy like praveenkarunarathne/Google-Cloud-Run-Proxy with env V2RAY_SERVER_IP=your_VPS.

| Parameter | Compute Engine | Cloud Run |

|----------|----------------|-----------|

| Startup | Always on | On-demand (0–1 instance) |

| Pricing | Fixed/hour | Request-based |

| Scaling | Manual | Auto |

| Latency | Low | 1–2s |

Key Takeaways

• /16–/8 subnet blocks hit >225 million IPs—bypass via Google's AS.
• XHTTP on Cloud Run plays nice with load balancers; Reality Seed shields packets.
• Domain fronting routes through Google infra without bans.
• Minimal resources: 128 MB/1 CPU for a couple clients.
• Config in Secret Manager, sniffing off for speed.

— Editorial Team