XRay in Google Cloud Run: Umgehung von Subnetz-Sperren

XRay auf Google Cloud Run deployen – Umgehung von Subnetz-Sperren

Das Sperren ganzer Provider-Subnetze erleichtert DPI, verursacht aber massive Kollateralschäden. Statt raffinierter Erkennung greifen Provider zu Pauschalsperren von /16- und /8-Bereichen, frieren Verbindungen nach 16 KB ein oder killen TLS komplett. Analysen zeigen Auswirkungen auf Hunderte ASNs und Millionen IPs. Workarounds: Deployment in ungesperrten Subnetzen großer Provider oder Domain Fronting.

Realität und einfache Alternativen

XTLS-Reality ist Overkill ohne aktives Probing: VLESS mit selbstsigniertem Zert und Domain-Spoofing erzeugt denselben Effekt. Funktioniert sogar mit CDNs, die Custom-Zerts unterstützen. Bei TLS-Blockaden: gRPC für VLESS oder XHTTP mit Multiplexing.

Deployment auf Google Compute Engine

Starten Sie eine e2-micro-Instanz (0,25 vCPU, 1 GB RAM) in Compute Engine:

• Wählen Sie die günstigste Region.
• Standard-Disk ohne Backups.
• HTTP/HTTPS-Traffic erlauben.
• Ephemere IPv4 nutzen.

Installieren Sie XRay und konfigurieren Sie VLESS Enc mit Reality Seed gegen Paketgrößen-Analyse. SNI google.com kommt durch, da die IP aus Googles AS stammt.

Kostenoptimierung mit Cloud Run: On-Demand-Container

Wechseln Sie zu serverless mit Cloud Run, um Kosten zu senken:

• Gehen Sie zu Cloud Run > Services > Web-Service deployen.
• Image: docker.io/teddysun/xray.
• Region: Tier 1, nächstgelegene.
• Container-Port: 8080.
• Ressourcen: 128 MB RAM, 1 CPU (Minimum für >1 Verbindung).
• Skalierung: 0–1 Instanz, abrechnungsbasiert pro Request.
• Ingress: all, Timeout 3600s, Concurrency 100+.

Konfiguration mounten

Erstellen Sie ein Secret im Secret Manager mit Ihrer config.json und mounten Sie es als /etc/xray/config.json.

Beispielkonfig für XHTTP (Sniffing deaktiviert):

{
  "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"
    }
  ]
}

Auf dem Client: XHTTP mit XMUX (maxConnections=1, maxConcurrency=0). Container-Start dauert 1–2 Sekunden.

Domain Fronting in Googles Infrastruktur

Verbindung zu google.com löst sich zu einer Google-IP auf, aber Host zeigt auf Ihre *.run.app – Requests routen intern im AS. Zerts werden korrekt für jeden Google-Service (HTTPS/QUIC) ausgestellt. Das ist kein Spoofing wie bei Reality: Traffic fließt durch echte Google-Infrastruktur.

Client-Konfig: server=google.com, SNI=google.com, Host=xxxxxxxxx.run.app.

Einschränkungen und Skalierung

• Erfordert Auslandskarte und Wohnsitzverifizierung.
• Teuer: Notfalloption für 1–2 User.
• Test: 200 $ für 3 Monate.

Bei >1 Verbindungslast: Deployen Sie einen Proxy wie praveenkarunarathne/Google-Cloud-Run-Proxy mit Env V2RAY_SERVER_IP=your_VPS.

| Parameter | Compute Engine | Cloud Run |

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

| Startup | Immer an | On-Demand (0–1 Instanz) |

| Abrechnung | Fix/Stunde | Pro Request |

| Skalierung | Manuell | Auto |

| Latenz | Niedrig | 1–2s |

Wichtige Erkenntnisse

• /16–/8-Subnetz-Sperren treffen >225 Mio. IPs – Umgehung über Googles AS.
• XHTTP auf Cloud Run harmoniert mit Load Balancern; Reality Seed schützt Pakete.
• Domain Fronting nutzt Google-Infra ohne Sperren.
• Minimale Ressourcen: 128 MB/1 CPU für ein paar Clients.
• Konfig im Secret Manager, Sniffing aus für Speed.

— Editorial Team