jedliuai/vps-proxy-skill

VPS Proxy Builder · Point d'entrée d'exécution Codex

Laissez la configuration, la vérification et le dépannage à Codex, afin que l'utilisateur n'ait à gérer que l'achat, la connexion au compte, les autorisations nécessaires et la validation côté client qui ne peut être faite à distance. Communiquez dans la langue de l'utilisateur ; n'exigez pas qu'il comprenne les paramètres de protocole, et ne prétendez pas qu'un plugin ou une exécution unique de script garantisse le succès.

D'abord se localiser, puis agir

Cette compétence dépend de l'ensemble du dépôt vps-proxy-skill, ce n'est pas un paquet d'installation indépendant. À partir du répertoire de travail actuel, localisez le dépôt contenant deploy/server-bootstrap.sh, deploy/preflight.py, cloudflare-worker/. Si la compétence a été copiée seule dans un répertoire personnel de compétences, obtenez d'abord le dépôt complet accessible à l'utilisateur et basculez-y ; n'exécutez pas le déploiement par rapport au répertoire personnel. Enregistrez la révision Git actuelle. Les noms de domaine, IP, alias SSH, ID Cloudflare et noms US-* historiques sont des enregistrements d'instances d'origine, pas des configurations utilisateur.

Choisissez le mode en fonction de la demande :

• Lecture/planification/documentation uniquement : expliquez, n'exécutez pas de SSH, de déploiement, d'écriture DNS ou d'installation de plugin.
• Nouveau : lisez Prérequis et outils, puis Étapes de déploiement.
• Un nœud existant est en panne : lisez Diagnostic et récupération, faites d'abord une vérification en lecture seule ; n'utilisez pas le bootstrap complet comme bouton de réparation.
• Validation ou livraison : lisez Validation et livraison.

Avant toute modification, lisez les Règles de sécurité du dépôt. Ne chargez que les références nécessaires à l'étape en cours, ne lisez pas tout l'historique.

Le contrat de cette automatisation

Clarifiez avec un plan court : l'alias/hôte SSH cible, le système d'exploitation, s'il s'agit d'un VPS dédié, la propriété du domaine, la connexion directe ou via Cloudflare, les services et pare-feu autorisés à être modifiés, les limites budgétaires et le point de repli. Si l'objectif n'est pas clair, ne demandez que l'information minimale manquante.

Une fois ce plan autorisé, exécutez en continu les vérifications, configurations et tests dans le périmètre défini, sans redemander pour chaque commande ordinaire. L'achat, l'extension, la création de nouvelles VM, les produits payants, le changement d'IP, la suppression de services existants, la désactivation de la surveillance, la publication du dépôt, la rotation des identifiants déjà utilisés ou la modification du périmètre d'impact doivent faire l'objet d'une nouvelle autorisation. Lorsqu'une connexion humaine est nécessaire, faites une pause à cette étape, expliquez où cliquer/autoriser quoi ; il est interdit de contourner les permissions ou de désactiver les limites de sécurité de Codex.

Ligne de base d'automatisation : Debian 13 dédié / x86_64 / systemd / SSH 22 / IPv4 public / Nom de domaine contrôlé par l'utilisateur. ARM, Ubuntu, port SSH personnalisé, NAT-only, IPv6 only, serveur partagé sont des tâches d'adaptation, ne peuvent pas sauter la porte d'entrée. Les modèles existants sont conçus pour le routage du réseau domestique chinois ; la région et la stratégie doivent être expliquées à l'utilisateur, ne collez pas l'étiquette américaine à d'autres pays.

Invariants à maintenir

1. Ne pas verrouiller l'utilisateur : prouvez d'abord la connexion par clé et sudo d'un administrateur non root avec une nouvelle session, conservez la session/console d'origine. ADMIN_SSH_VERIFIED=1 est une déclaration du résultat de la vérification, pas une preuve automatique ; le script désactivera ensuite le mot de passe et le SSH root, et ne conservera que le port 22.
2. Ne pas écraser d'autres services : listez l'état des services d'écoute, Nginx, nftables/UFW, Docker et systemd. Le bootstrap reconstruira la configuration de la pile, remplacera le site par défaut de Nginx, resserrera les règles entrantes, installera des versions fixes et redémarrera. Préparez un instantané/une console de récupération pour l'hôte dédié avant de déployer.
3. Ne pas réutiliser la configuration de l'auteur : le vrai nom de domaine/alias est fourni par l'utilisateur ou vérifié dans un compte autorisé ; la configuration Cloudflare doit utiliser son compte/zone/KV. Les nouvelles entrées n'intègrent pas les valeurs par défaut de l'auteur.
4. Ne pas divulguer d'identifiants : les clés sont générées sur le serveur ; l'URL d'abonnement est elle-même un identifiant bearer, Base64 n'est pas du chiffrement. Les clés privées/mots de passe/URI/YAML/tokens ne vont pas dans Git, les logs, le chat ou les convertisseurs publics. Livrez uniquement des fichiers exclusifs à l'utilisateur, référez-vous à la section de livraison.
5. Ne pas confondre installation et validation : active, TCP accessible, TLS réussi, protocole complet utilisable, réseau utilisateur accessible sont des preuves différentes. Testez avec des clients temporaires indépendants un par un, sans écraser leur configuration actuelle.
6. Ne pas essayer indéfiniment : si le script échoue la première fois, sauvegardez d'abord les preuves nettoyées et localisez l'étape, ne répétez pas l'installation complète, ne déployez pas en parallèle. En cas de détérioration du nœud d'origine, restaurez d'abord la configuration connue. Les tentatives de mise à niveau et de renouvellement de certificat doivent cibler la cause racine, sans gaspiller les quotas ACME par des essais et erreurs.

Vérifier les dépendances par capacité, pas par nom de plugin

• Codex doit pouvoir lire l'intégralité du dépôt, exécuter un terminal local, se connecter en SSH sur le réseau, et avoir reçu les autorisations correspondantes. Le VPS n'a pas besoin d'installer Codex.
• Le plugin/connexion GitHub peut être utilisé pour l'accès au dépôt ; Git/gh autorisé peut également être utilisé. Le plugin ne donne pas forcément les identifiants de clonage en terminal.
• Lorsque Cloudflare est choisi, il est recommandé d'utiliser son plugin officiel et de vérifier les outils et autorisations disponibles ; en cas d'absence de capacité DNS/Workers/KV/secret, utilisez l'API autorisée ou Wrangler verrouillé. Le simple fait d'installer le plugin ne signifie pas que toutes ces permissions sont disponibles.
• Le contrôle du navigateur n'est utilisé que lorsque l'utilisateur souhaite une assistance pour les opérations de la console ; la connexion, le MFA et le paiement sont laissés à l'utilisateur. Ne demandez pas d'autres plugins non pertinents, n'installez pas automatiquement des dépendances complètes.

Les références pour l'installation des outils et les entrées de documentation officielles se trouvent dans les prérequis. N'exigez pas un modèle fixe ; en cas de capacité insuffisante, de perte de contexte ou de limitations des outils, sauvegardez l'état récupérable, ne promettez pas qu'un modèle quelconque puisse terminer sans supervision.

Définition de la complétude et reprise

Livrez deux points d'entrée marqués par client : Clash et v2rayN/v2rayNG/Shadowrocket ; si Cloudflare n'est pas configuré, ne livrez que le point d'entrée direct vérifié. Expliquez que les trois protocoles sont sur le même serveur, pas des sorties vers plusieurs pays ; les URI d'abonnement ne contiennent pas de groupes de routage Clash.

Rapportez ce qui a été testé/échoué/à tester par l'utilisateur, conservez la version, la date, le point de restauration, l'état de renouvellement du certificat et les limites de coût. Si le test ne peut pas être effectué sur le réseau domestique de l'utilisateur, précisez clairement « déploiement du serveur terminé, validation sur le réseau domestique en attente », ne concluez pas à un succès total de la validation.

Pour chaque étape complète, écrivez en chinois worklog/YYYY-MM-DD-titre.md : ce qui a été fait, pourquoi, les décisions/difficultés, une phrase clé. Pour reprendre une longue tâche, lisez les enregistrements nettoyés et l'état actuel, puis continuez les étapes non terminées ; ne redéployez pas depuis le début, n'enregistrez pas d'identifiants. Ajoutez les conditions, preuves et correctifs réutilisables des nouvelles pannes aux références, plutôt que de généraliser un cas particulier en conclusion universelle.