VPS-Proxy-Automatisierung

VPS Proxy Builder · Codex Einstiegspunkt

Überlasse Codex die Konfiguration, Überprüfung und Fehlerbehebung, sodass der Nutzer sich nur um den Kauf, die Kontoanmeldung, notwendige Autorisierungen und die clientseitige Abnahme kümmern muss. Kommuniziere in der Sprache des Nutzers; verlange nicht, dass er Protokollparameter versteht, und täusche nicht vor, dass ein Plugin oder eine einmalige Skriptausführung Erfolg garantiert.

Erst orientieren, dann handeln

Dieser Skill ist auf das gesamte vps-proxy-skill-Repository angewiesen und kein eigenständiges Paket. Navigiere vom aktuellen Arbeitsverzeichnis zum Repository, das deploy/server-bootstrap.sh, deploy/preflight.py und cloudflare-worker/ enthält. Falls der Skill separat in ein persönliches Skill-Verzeichnis kopiert wurde, besorge dir zuerst das vollständige, vom Nutzer zugängliche Repository und wechsle dorthin; führe keine Befehle relativ zum persönlichen Skill-Verzeichnis aus. Notiere die Git-Revision. Historische Domains, IPs, SSH-Aliase, Cloudflare-IDs und US-*-Namen sind Aufzeichnungen vorheriger Instanzen, nicht die Konfiguration des Nutzers.

Wähle je nach Anfrage den Modus:

• Nur lesen/planen/dokumentieren: Erklären, kein SSH, keine Bereitstellung, kein DNS-Schreiben oder Plugin-Installation.
• Neu erstellen: Lies Voraussetzungen und Werkzeuge, dann Bereitstellungsschritte.
• Vorhandener Knoten defekt: Lies Diagnose und Wiederherstellung, führe zunächst einen Nur-Lese-Vergleich durch; verwende nicht das vollständige Bootstrap als Reparaturknopf.
• Abnahme/Übergabe: Lies Abnahme und Übergabe.

Lies vor Änderungen die Sicherheitsvereinbarung des Repositories. Lade nur die für den aktuellen Schritt benötigten Referenzen, nicht die gesamte Historie.

Vertrag dieser Automatisierung

Erstelle einen kurzen Plan mit den folgenden Punkten: Ziel-SSH-Alias/Host, Betriebssystem, ob es sich um einen dedizierten VPS handelt, Domain-Zugehörigkeit, direkte Verbindung oder Cloudflare-Abonnement, erlaubte zu ändernde Dienste und Firewalls, Budgetgrenzen und Rückfallebene. Frage nur nach den minimal fehlenden Informationen, wenn das Ziel unklar ist.

Sobald dieser Plan autorisiert ist, führe die Überprüfungen, Konfigurationen und Tests im Rahmen des Umfangs kontinuierlich durch, ohne für jeden gewöhnlichen Befehl erneut zu fragen. Für Käufe, Upgrades, das Erstellen neuer VMs, kostenpflichtige Produkte, IP-Änderungen, das Löschen bestehender Dienste, das Deaktivieren von Monitoring, das Veröffentlichen von Repositories, das Rotieren verwendeter Anmeldedaten oder das Ändern des betroffenen Bereichs ist eine separate Genehmigung erforderlich. Wenn ein manuelles Login erforderlich ist, halte an diesem Schritt inne und erkläre, wo geklickt/ autorisiert werden muss; umgehe keine Berechtigungen und deaktiviere keine Codex-Sicherheitsbeschränkungen.

Automatisierungsbasislinie: Dediziertes Debian 13 / x86_64 / systemd / SSH 22 / öffentliche IPv4 / vom Nutzer kontrollierte Domain. ARM, Ubuntu, benutzerdefinierte SSH-Ports, reines NAT, nur IPv6, gemeinsam genutzte Geschäftshosts sind Anpassungsaufgaben und dürfen die Sicherheitsprüfung nicht überspringen. Das vorhandene Template ist auf das chinesische Heimnetzwerk-Splitting ausgelegt; die Region und Strategie müssen dem Nutzer erklärt werden, und US-Etiketten dürfen nicht auf andere Länder übertragen werden.

Unveränderliche Invarianten

1. Nutzer nicht aussperren: Beweise zuerst mit einer neuen Sitzung, dass der nicht-root-Administrator per Schlüssel einloggen und sudo verwenden kann, und behalte die ursprüngliche Sitzung/Konsole bei. ADMIN_SSH_VERIFIED=1 ist eine Deklaration des Prüfergebnisses, kein automatischer Beweis; das Skript deaktiviert anschließend Passwort- und Root-SSH und behält nur Port 22.
2. Andere Dienste nicht überschreiben: Liste die laufenden Dienste, Nginx, nftables/UFW, Docker und den systemd-Status auf. Das Bootstrap wird die Stack-Konfiguration neu aufbauen, die Nginx-Standardseite ersetzen, eingehende Regeln verschärfen, feste Versionen installieren und neu starten. Stelle sicher, dass für dedizierte Hosts ein Snapshot/Wiederherstellungs-Kontrollzentrum bereitsteht, bevor du bereitstellst.
3. Konfiguration des Autors nicht wiederverwenden: Echte Domains/Aliase werden vom Nutzer bereitgestellt oder innerhalb eines autorisierten Kontos verifiziert; Cloudflare-Konfigurationen müssen dessen account/zone/KV verwenden. Neue Einstiegspunkte enthalten keine Standardwerte des Autors mehr.
4. Keine Anmeldedaten preisgeben: Schlüssel werden auf dem Server generiert; die Abonnement-URL selbst ist ein Bearer-Token, Base64 ist keine Verschlüsselung. Private Schlüssel/Passwörter/URIs/YAMLs/Tokens dürfen nicht in Git, Logs, Chats oder öffentliche Konverter gelangen. Liefere nur Dateien aus, die exklusiv für den Nutzer bestimmt sind (siehe Übergabekapitel).
5. Installation nicht als Abnahme betrachten: aktiv, TCP erreichbar, TLS erfolgreich, vollständiges Protokoll nutzbar, Nutzernetzwerk nutzbar sind unterschiedliche Nachweise. Teste jeden Punkt mit einem unabhängigen temporären Client, ohne dessen aktuelle Konfiguration zu überschreiben.
6. Nicht unbegrenzt Fehler versuchen: Wenn ein Skript beim ersten Mal fehlschlägt, speichere zuerst die entidentifizierten Beweise und identifiziere die Phase; wiederhole nicht die gesamte Installation und führe keine parallelen Bereitstellungen durch. Wenn sich ein bestehender Knoten verschlechtert, stelle zuerst die bekannte Konfiguration wieder her. Upgrade- und Zertifikatserneuerungsversuche müssen auf die Grundursache abzielen und ACME-Kontingente nicht durch Trial-and-Error verschwenden.

Abhängigkeiten anhand der Fähigkeiten prüfen, nicht nach Plugin-Namen raten

• Codex muss in der Lage sein, das vollständige Repository zu lesen, lokale Terminalbefehle auszuführen, eine SSH-Verbindung über das Netzwerk herzustellen und über die entsprechenden Berechtigungen zu verfügen. Der VPS muss Codex nicht installiert haben.
• GitHub-Plugins/Konnektoren können für den Repository-Zugriff verwendet werden; autorisiertes Git/gh ist ebenfalls möglich. Plugins gewähren nicht unbedingt Terminal-Klon-Berechtigungen.
• Bei Auswahl von Cloudflare werden die offiziellen Plugins empfohlen, und die verfügbaren Tools und Berechtigungen müssen überprüft werden; bei fehlenden DNS/Workers/KV/secret-Fähigkeiten verwende die autorisierte API oder einen gesperrten Wrangler. Die Installation eines Plugins allein bedeutet nicht, dass alle diese Berechtigungen vorhanden sind.
• Browserkontrolle nur, wenn der Nutzer bei Konsolenoperationen helfen möchte; Login, MFA und Zahlungen bleiben dem Nutzer überlassen. Fordere keine anderen irrelevanten Plugins an und installiere nicht automatisch ganze Abhängigkeitspakete.

Die Referenzen für Tool-Installation und offizielle Quellen findest du in den Voraussetzungen. Kein festes Modell erforderlich; bei unzureichenden Fähigkeiten, Kontextverlust oder eingeschränkten Tools speichere den wiederherstellbaren Fortschritt und versprich nicht, dass "jedes Modell dies unbeaufsichtigt abschließen kann".

Abschlussdefinition und Fortführung

Übergib zwei nach Client markierte Einstiegslink: einen für Clash und einen für v2rayN/v2rayNG/Shadowrocket; wenn Cloudflare nicht konfiguriert ist, übergib nur den verifizierten Direktlink. Erkläre, dass die drei Protokolle auf demselben Server laufen und nicht mehrere Länderausgänge darstellen; URI-Abonnements enthalten keine Clash-Routing-Gruppen.

Berichte über getestete/fehlgeschlagene/vom Nutzer zu testende Punkte, behalte Version, Datum, Rollback-Position, Zertifikatsverlängerungsstatus und Kostengrenzen bei. Wenn ein Test im Heimnetz des Nutzers nicht möglich ist, schreibe deutlich "Serverbereitstellung abgeschlossen, Abnahme im Heimnetz ausstehend" und formuliere nicht, als ob die gesamte Abnahme erfolgreich gewesen sei.

Schreibe für jede vollständige Phase eine chinesische worklog/YYYY-MM-DD-Titel.md: was getan wurde, warum, Entscheidungen/Stolperfallen, ein prägnantes Highlight. Stelle bei langen Aufgaben den entidentifizierten Datensatz und den aktuellen Status wieder her und fahre mit den unvollständigen Schritten fort; führe keine Neuinstallation durch und protokolliere keine Anmeldedaten. Ergänze die Bedingungen, Beweise und wiederverwendbaren Reparaturen neuer Fehler in den Referenzen, anstatt Einzelfälle zu allgemeinen Schlussfolgerungen aufzublähen.