Wie deployt man eine Gatsby-Site in China: Inland-Auslieferung und die ICP-Beian

Eine Gatsby-Site zu deployen, ist der Teil, über den sich Teams am wenigsten sorgen, sobald sie es einmal getan haben: Gatsby kompiliert Ihr Projekt zu statischen Dateien, und statische Dateien gehen fast überallhin. Was tatsächlich entscheidet, ob diese Site Festlandchina bedienen kann, ist nicht der Build-Befehl — es ist, wohin Sie das Deploy richten. In dem Augenblick, in dem diese Dateien von innerhalb des Festlands ausgeliefert werden, öffnen sich zwei Tore zugleich, und sie sind die eigentliche Arbeit. Dieser Leitfaden behält die praktischen Schritte, verankert sie aber an der Frage, die jede Deploy-Konfiguration überdauert: Ist die Site zum Betrieb in China lizenziert, und wird sie von innerhalb ausgeliefert?

Hier ist der ehrliche Ausgangspunkt, und er ist ausnahmsweise eine gute Nachricht. Gatsby ist ein Static-Site-Generator, keine gehostete Plattform — es gibt keine „Gatsby-Region“, die fehlen könnte, und kein Konto zu migrieren. Die Build-Ausgabe ist gewöhnlicher statischer Inhalt, und genau deshalb kann eine Gatsby-Site auf Infrastruktur innerhalb Festlandchinas laufen, wie es ein rein gehosteter Dienst nicht kann. Was aus dieser Freiheit folgt, ist Verantwortung: eine ICP-Beian auf dem Festland-Host, Inland-Auslieferung, um die Grenzüberquerung zu beseitigen, und eine PIPL-Prüfung für alles, was Ihre Seiten erheben. Nachstehend finden Sie Gatsbys eigene Beschreibung seiner Ausgabe, die eigene Meldungsregel eines Festland-Hosts und das Recht, das jedes Tor auslöst, sodass Sie es Ihrem Rechtsbeistand vorlegen können.

Gatsby in China auf einen Blick

Was „Gatsby deployen“ tatsächlich ist

Jedes Gatsby-Deployment reduziert sich auf einen Befehl und einen Ordner. gatsby build auszuführen, kompiliert Ihr Projekt — in Gatsbys eigenen Worten “the output is static content: HTML, CSS, JavaScript, images, etc.” — in ein public/-Verzeichnis, und deployen ist nichts weiter, als den Inhalt dieses Ordners von einem Webhost auszuliefern. Eine typische Static-Site-Konfiguration sieht überall gleich aus, wo sie läuft:

Weil nichts davon an eine bestimmte Plattform gebunden ist, ist die eine Entscheidung, nach der die Kommandozeile nie fragt, die wichtigste: welcher Host public/ ausliefert. Richten Sie es auf einen Offshore-Host, so haben Sie eine globale Site, die lediglich zufällig von China aus über die Grenze erreichbar ist. Richten Sie es auf einen Host innerhalb des Festlands, so haben Sie eine Inland-Site — und, im selben Zug, eine ICP-Pflicht. Diese eine Wahl, nicht das Framework, ist das, worum es in diesem Artikel wirklich geht.

Tor 1: Auslieferung von innerhalb des Festlands

Ein Gatsby-Build, der von außerhalb Festlandchinas ausgeliefert wird, ist nicht kaputt; er liegt schlicht auf der anderen Seite einer Grenze, die überlastet und gefiltert ist. Das Symptom, das Teams berichten, ist selten ein sauberer Ausfall — es ist Unbeständigkeit. Dieselbe Seite ist morgens schnell und abends unzuverlässig, und die Assets, die Ihr Build einzieht (eine Web-Schrift, ein eingebettetes Video, ein Drittanbieter-Skript), scheitern jeweils nach ihrem eigenen Zeitplan. Eine Content-Delivery-Schicht hilft hier nur, wenn ihre Points of Presence wirklich innerhalb des Festlands liegen; Hongkong und Singapur fühlen sich auf einer Karte nah an und sitzen auf der falschen Seite der Überquerung. Den Build von innerhalb Festlandchinas auszuliefern, ist das, was den Grenz-Roundtrip beseitigt. Das ist Tor 1, und für sich genommen ist es eine Performance-Frage — aber es bleibt nicht allein, denn der Akt, der es behebt, öffnet auch das nächste Tor.

Tor 2: die ICP-Beian, die der Host nun braucht

In dem Augenblick, in dem Ihr public/-Ordner von einem Server innerhalb des Festlands ausgeliefert wird, bindet sich eine Lizenzpflicht an diesen Host. Ein Festland-Anbieter erklärt es unzweideutig: Eine Domain, die “resolving to servers in the Chinese mainland”, “must obtain an ICP filing before providing services,” und eine Domain ohne eine wird auf Netzebene blockiert, bis die Meldung abgeschlossen ist. Die ICP-Beian (备案), nach Staatsratserlass Nr. 292 und MIIT-Erlass Nr. 33, bindet sich an die lizenzierte Festland-Hosting-Ressource und an einen Festland-Rechtsträger — weshalb ein ausländisches Unternehmen meist nicht im eigenen Namen melden kann und weshalb „wir legen die Dateien einfach auf einen chinesischen Server“ sich als eine Aufgabe der Unternehmensstruktur ebenso wie eine technische erweist. Für die Mechanik siehe was die chinesische ICP-Lizenz ist und wie man sie erhält.

Das ist der Teil, den man sich vor der Wahl eines Hosts verinnerlichen sollte: Der Zug, der Tor 1 behebt, ist der Zug, der Tor 2 öffnet. Inland-Auslieferung beseitigt die Grenzüberquerung und macht, im identischen Schritt, die Meldung verpflichtend. Es gibt keine Einrichtung, die Ihnen Inland-Auslieferung kauft und Sie zugleich von der Meldung freihält — die Geschwindigkeit und die Lizenz werden in derselben Transaktion erworben, oder gar nicht.

Die PIPL-Frage — nur so groß wie das, was Ihre Seiten erheben

Hier unterscheidet sich eine statische Site tatsächlich von einer datenlastigen Anwendung, und es lohnt sich, dabei ehrlich zu sein, statt es aufzublasen. Ein broschürenartiger Gatsby-Build, der nichts erhebt, trägt wenig Exponierung bei personenbezogenen Daten, sodass für viele statische Sites die ICP-Beian und die Inland-Auslieferung die ganze Compliance-Geschichte sind. Das Bild ändert sich in dem Moment, in dem eine Seite beginnt, Daten über Festland-Besucher zu erfassen. Ein Kontaktformular, eine Newsletter-Anmeldung, ein Kommentar-Widget, ein Analytics-Beacon — jedes kann personenbezogene Daten erheben, und die echte IP-Adresse eines Besuchers zählt für sich genommen als personenbezogenes Datum. Etwas davon an einen Endpunkt außerhalb des Festlands zu senden, ist ein grenzüberschreitender Transfer personenbezogener Daten, den das PIPL regelt (Art. 38–43: Mitteilung, gesonderte Einwilligung und ein zulässiger Transfermechanismus). Die ehrliche Faustregel ist, Ihren PIPL-Aufwand mit dem skalieren zu lassen, was Ihre Gatsby-Seiten tatsächlich erheben, während die ICP-Beian und die Inland-Auslieferung so oder so die Grundlinie bleiben.

Dies ist eine Risikokarte zur Planung, kein rechtliches Urteil: Welches Tor zuerst bindet und wie weit das PIPL reicht, hängt von Ihrer Gesellschaft, Ihrem Host und den Daten, die Ihre Seiten erfassen, ab — alles wert, vor dem Start mit Rechtsbeistand zu klären.

Wo 21YunBox hineinpasst — eine rechtskonforme Overlay, keine Migration

Sie bauen und liefern weiter mit Gatsby genau wie heute — dasselbe gatsby build, dieselbe public/-Ausgabe, derselbe Workflow. Was 21YunBox hinzufügt, ist das einzige Stück, das ein Build-Tool von sich aus strukturell nicht liefern kann: ICP-gemeldete Auslieferung aus dem Inland, platziert vor Ihrer bestehenden Origin — kein Neuaufbau, keine zweite Codebasis und kein Wechsel weg vom Stack, den Sie bereits betreiben. Ihr Gatsby-Build bleibt die Quelle der Wahrheit; unser China-Team kartiert, welche Pflichten auf Ihre Gesellschaft und die Daten, die Ihre Seiten erheben, zutreffen, übernimmt die ICP-Beian auf der Inland-Hosting-Ressource und setzt die rechtskonforme Inland-Auslieferung auf, die Ihr Festland-Publikum bedient. Das Framework war nie der schwierige Teil — die Lizenz zum Betrieb und die Auslieferung, die diese Lizenz erlaubt, sind es, und genau diese Hälfte halten wir.

Compliance-Einschätzung anfordern →

Weiterführend:

• Was ist die chinesische ICP-Lizenz, und wie erhält man sie?
• Grenzüberschreitende Datentransfers nach PIPL