VPS Proxy Builder · Entrada de ejecución de Codex
Deja la configuración, verificación y resolución de problemas a Codex, permitiendo que el usuario solo se encargue de la compra, el inicio de sesión, las autorizaciones necesarias y la validación del cliente que no se puede realizar de forma remota. Comunícate en el idioma del usuario; no le exijas entender parámetros de protocolo ni finjas que un plugin o una sola ejecución de script garantiza el éxito.
Primero localizar, luego actuar
Esta habilidad depende de todo el repositorio vps-proxy-skill, no es un paquete independiente. Desde el directorio de trabajo actual, localiza el repositorio que contiene deploy/server-bootstrap.sh, deploy/preflight.py, cloudflare-worker/. Si la habilidad se copió por separado a un directorio de habilidades personal, primero obtén el repositorio completo accesible por el usuario y cambia a él; no ejecutes la implementación en relación con el directorio de habilidades personal. Registra esta revisión de Git. Los nombres de dominio, IPs, alias SSH, ID de Cloudflare y nombres US-* históricos son registros de la instancia original, no configuración del usuario.
Selecciona el modo según la solicitud:
- Solo lectura/planificación/documentación: Explica, no ejecutes SSH, despliegues, escrituras DNS ni instalaciones de plugins.
- Nuevo despliegue: Lee Prerrequisitos y herramientas, luego lee Pasos de despliegue.
- Nodo existente averiado: Lee Diagnóstico y recuperación, primero haz una comparación de solo lectura; no uses el bootstrap completo como botón de reparación.
- Validación o entrega: Lee Validación y entrega.
Antes de realizar cambios, lee las Reglas de seguridad del repositorio. Solo carga las referencias necesarias para la etapa actual, no es necesario leer todo el historial.
Contrato de esta automatización
Define con un breve plan: alias SSH/host objetivo, sistema, si es VPS dedicado, propiedad del dominio, conexión directa o suscripción Cloudflare, servicios y firewall que se pueden modificar, límite de presupuesto y punto de retroceso. Si el objetivo no está claro, pregunta solo la información mínima faltante.
Una vez confirmada la autorización de este plan, ejecuta de forma continua las comprobaciones, configuraciones y pruebas dentro del alcance, sin preguntar por cada comando normal. Compra, escalado, creación de nuevas VM, productos de pago, cambio de IP, eliminación de servicios existentes, desactivación de monitoreo, repositorios públicos, rotación de credenciales ya utilizadas o cambios en el alcance afectado requieren autorización adicional. Cuando se necesite inicio de sesión manual, pausa en ese paso, indica dónde hacer clic/qué autorizar; está prohibido eludir permisos o desactivar las restricciones de seguridad de Codex.
Línea base de automatización: Debian 13 dedicado / x86_64 / systemd / SSH 22 / IPv4 pública / dominio controlado por el usuario. ARM, Ubuntu, puerto SSH personalizado, solo NAT, solo IPv6, hosts de servicios compartidos son tareas de adaptación, no se puede omitir la comprobación inicial y ejecutar a ciegas. La plantilla existente está diseñada para el escenario de división de tráfico de una red doméstica china; la región y la estrategia deben explicarse al usuario, no etiquetar a EE. UU. para otros países.
Invariantes que deben mantenerse
- No bloquear al usuario: Primero, con una nueva sesión, demuestra que el administrador no root puede iniciar sesión con clave y usar sudo, conservando la sesión/consola original.
ADMIN_SSH_VERIFIED=1es una declaración del resultado de la comprobación, no una prueba automática; el script posteriormente deshabilitará las contraseñas y el SSH root, y solo mantendrá el puerto 22. - No sobrescribir otros servicios: Enumera los procesos en escucha, Nginx, nftables/UFW, Docker y el estado de systemd. Bootstrap reconstruirá la configuración de esta pila, reemplazará el sitio predeterminado de Nginx, endurecerá las reglas de entrada, instalará versiones fijas y reiniciará. Prepara la instantánea/consola de recuperación del host dedicado antes de implementar.
- No reutilizar la configuración del autor: El nombre de dominio/alias real debe ser proporcionado por el usuario o verificado dentro de una cuenta autorizada; la configuración de Cloudflare debe usar su propia cuenta/zone/KV. Las nuevas entradas no incorporarán los valores predeterminados del autor.
- No filtrar credenciales: Las claves se generan en el servidor; la URL de suscripción en sí misma es una credencial de portador, Base64 no es cifrado. Las claves privadas/contraseñas/URI/YAML/tokens no deben entrar en Git, registros, chat ni sitios de conversión públicos. Solo entrega archivos exclusivos para el usuario, consulta la sección de entrega.
- No tomar la instalación como validación:
active, alcanzable por TCP, TLS exitoso, protocolo completo utilizable y red del usuario utilizable son diferentes evidencias. Prueba con clientes temporales independientes uno por uno, no sobrescribas su configuración actual. - No probar errores infinitamente: Si el script falla la primera vez, guarda primero la evidencia desinfectada y localiza la etapa, no repitas la instalación completa ni implementes en paralelo. Cuando el nodo original empeore, primero restaura la configuración conocida. Las actualizaciones y los reintentos de emisión de certificados deben abordar la causa raíz, no uses prueba y error para consumir cuotas de ACME.
Las dependencias se verifican por capacidad, no por nombre de plugin
- Codex debe poder leer el repositorio completo, ejecutar terminal local y conectarse por SSH a la red, y tener los permisos correspondientes. El VPS no necesita instalar Codex.
- El plugin/conector de GitHub se puede usar para acceder al repositorio; Git/
ghautorizados también funcionan. Los plugins no siempre otorgan credenciales de clonación en la terminal. - Al elegir Cloudflare, se recomienda su plugin oficial y verificar las herramientas y autorizaciones disponibles; si faltan capacidades de DNS/Workers/KV/secret, usa la API autorizada o Wrangler bloqueado. La instalación del plugin no significa que todos estos permisos estén disponibles.
- El control del navegador se usa solo cuando el usuario desea ayuda con operaciones de consola; el inicio de sesión, MFA y pagos quedan para el usuario. No solicites otros plugins irrelevantes ni instales automáticamente dependencias completas.
La instalación de herramientas y la entrada a la documentación oficial se encuentran en la referencia de prerrequisitos. No se requiere un modelo fijo; si la capacidad es insuficiente, se pierde el contexto o las herramientas están limitadas, guarda el progreso recuperable, no prometas "cualquier modelo completará sin supervisión".
Definición de finalización y continuación
Entrega dos enlaces de entrada etiquetados por cliente: Clash y v2rayN/v2rayNG/Shadowrocket; si Cloudflare no está configurado, entrega solo el enlace de conexión directa verificado. Explica que los tres protocolos son el mismo servidor, no salidas de múltiples países; la suscripción URI no contiene grupos de división de Clash.
Informa sobre lo probado/fallido/pendiente de prueba del usuario, conserva la versión, fecha, punto de reversión, estado de renovación del certificado y límite de costos. Si no es posible probar en la red doméstica del usuario, indica claramente "Implementación del servidor completada, validación en red doméstica pendiente", no se puede escribir como validación exitosa total.
Para cada etapa completa, escribe en chino worklog/YYYY-MM-DD-título.md: qué se hizo, por qué, decisiones/dificultades, un aspecto destacado en una frase. Para reanudar una tarea larga, lee solo los registros desinfectados y el estado actual, luego continúa con los pasos incompletos; no implementes desde cero, no registres credenciales. Incorpora las condiciones, evidencia y correcciones reutilizables de nuevas fallas en las referencias, no generalices un caso particular como conclusión universal.