jedliuai/vps-proxy-skill

Construtor de Proxy VPS · Ponto de Entrada para Execução no Codex

Deixe a configuração, verificação e resolução de problemas para o Codex, permitindo que o usuário lide apenas com compras, login na conta, autorizações necessárias e validação do cliente que não pode ser feita remotamente. Comunique-se no idioma do usuário; não exija que ele entenda parâmetros de protocolo e não finja que um plugin ou uma única execução de script garanta sucesso.

Primeiro, Localize, Depois Aja

Este skill depende de todo o repositório vps-proxy-skill, não é um pacote de instalação independente. A partir do diretório de trabalho atual, localize o repositório que contenha deploy/server-bootstrap.sh, deploy/preflight.py, cloudflare-worker/. Se o skill foi copiado isoladamente para um diretório pessoal de skills, primeiro obtenha o repositório completo acessível ao usuário e mude para ele; não execute a implantação em relação ao diretório pessoal de skills. Registre a revisão Git atual. Nomes de domínio históricos, IPs, aliases SSH, IDs Cloudflare e nomes US-* são registros de instâncias originais, não configurações do usuário.

Com base na solicitação, selecione o modo:

• Apenas leitura/planejamento/documentação: Explique, não execute SSH, implantação, escrita DNS ou instalação de plugins.
• Nova implantação: Leia Pré-requisitos e depois Passos de Implantação.
• Nó existente com problema: Leia Diagnóstico e Recuperação, primeiro faça uma comparação somente leitura; não use o bootstrap completo como um botão de reparo.
• Validação ou Entrega: Leia Validação e Entrega.

Antes de qualquer alteração, leia o Acordo de Segurança do repositório. Carregue apenas as referências necessárias para o estágio atual; não é necessário ler o histórico completo.

O Contrato desta Automação

Defina claramente em um breve plano: alias/host SSH alvo, sistema, se é um VPS dedicado, titularidade do domínio, se é conexão direta ou assinatura via Cloudflare, serviços e firewall que podem ser modificados, limite de orçamento e ponto de retorno. Se o alvo não estiver claro, pergunte apenas as informações mínimas faltantes.

Após confirmar que este plano foi autorizado, execute de forma contínua verificações, configurações e testes dentro do escopo, sem repetir a pergunta para cada comando comum. Compras, upgrades, criação de novas VMs, produtos pagos, mudança de IP, exclusão de serviços existentes, desativação de monitoramento, exposição de repositórios públicos, rotação de credenciais já em uso ou alteração do escopo afetado exigem nova autorização. Quando for necessário login manual, pause nessa etapa, explicando onde clicar/o que autorizar; é proibido contornar permissões ou desativar as restrições de segurança do Codex.

Linha de base da automação: Debian 13 dedicado / x86_64 / systemd / SSH 22 / IPv4 público / domínio controlado pelo usuário. ARM, Ubuntu, porta SSH personalizada, apenas NAT, apenas IPv6, servidores compartilhados são tarefas de adaptação e não podem pular a verificação de segurança. O modelo existente assume roteamento de rede doméstica chinesa; a região e a estratégia devem ser explicadas ao usuário, não aplique rótulos dos EUA a outros países.

Invariantes que Devem Ser Mantidas

1. Não bloquear o usuário: Primeiro, use uma nova sessão para provar que o login por chave do administrador não root e o sudo estão disponíveis, mantendo a sessão original/console. ADMIN_SSH_VERIFIED=1 é uma declaração do resultado da verificação, não uma prova automática; o script posteriormente desabilitará a senha e o SSH root, e manterá apenas a porta 22.
2. Não sobrescrever outros serviços: Liste o status de listeners, Nginx, nftables/UFW, Docker e systemd. O bootstrap irá reconstruir a configuração atual, substituir o site padrão do Nginx, restringir regras de entrada, instalar versões fixas e reiniciar. Prepare snapshots/console de recuperação do host dedicado antes de implantar.
3. Não reutilizar a configuração do autor: Domínios/alias reais são fornecidos pelo usuário ou verificados dentro de uma conta autorizada; a configuração do Cloudflare deve usar a conta/zone/KV dele. Novas entradas não devem mais incorporar valores padrão do autor.
4. Não vazar credenciais: As chaves são geradas no servidor; a própria URL de assinatura é uma credencial bearer, Base64 não é criptografia. Chaves privadas/senhas/URIs/YAML/tokens não entram em Git, logs, chat ou estações de conversão públicas. Entregue apenas arquivos exclusivos para o usuário, consulte a seção de entrega.
5. Não tratar instalação como validação: active, TCP acessível, TLS bem-sucedido, protocolo completo funcional e rede do usuário funcional são evidências diferentes. Teste individualmente com um cliente temporário independente, não sobrescreva a configuração atual do usuário.
6. Não tentar infinitamente: Na primeira falha de um script, salve evidências anonimizadas e identifique o estágio; não repita a instalação completa, não implante em paralelo. Quando um nó original piorar, primeiro restaure a configuração conhecida. As tentativas de upgrade e reemissão de certificados devem mirar a causa raiz, não use tentativas e erros para consumir a cota do ACME.

Verifique as Dependências pela Capacidade, Não pelo Nome do Plugin

• O Codex deve ser capaz de ler o repositório completo, executar o terminal local, conectar-se via SSH à rede, e ter obtido as permissões correspondentes. O VPS não precisa ter o Codex instalado.
• O plugin/conector do GitHub pode ser usado para acesso ao repositório; Git/gh autorizados também funcionam. Plugins não garantem necessariamente credenciais de clone no terminal.
• Ao escolher Cloudflare, recomende seu plugin oficial e verifique as ferramentas e autorizações disponíveis; se faltar capacidade DNS/Workers/KV/secret, use a API autorizada ou Wrangler bloqueado. Apenas instalar um plugin não significa que todas essas permissões estão disponíveis.
• O controle do navegador só deve ser usado quando o usuário deseja assistência em operações de console; login, MFA, pagamento devem ser deixados para o usuário. Não solicite outros plugins irrelevantes, não instale automaticamente dependências completas.

Consulte a referência de pré-requisitos para informações de instalação de ferramentas e materiais oficiais. Não exija um modelo fixo; em caso de capacidade insuficiente, perda de contexto ou limitações de ferramentas, salve o progresso recuperável, não prometa "qualquer modelo conclui sem supervisão".

Definição de Conclusão e Continuação

Entregue duas entradas de link marcadas por cliente: Clash e v2rayN/v2rayNG/Shadowrocket; se o Cloudflare não estiver configurado, entregue apenas a entrada de conexão direta verificada. Explique que os três protocolos são o mesmo servidor, não saídas de múltiplos países; a assinatura URI não contém grupos de roteamento do Clash.

Relate o que foi testado/falhou/aguardando teste do usuário, mantendo versão, data, ponto de reversão, status de renovação do certificado e limites de custo. Se não for possível testar na rede doméstica do usuário, deve-se declarar claramente "Implantação do servidor concluída, validação na rede doméstica pendente", não escrever como se tudo tivesse sido aceito com sucesso.

Escreva para cada estágio completo worklog/YYYY-MM-DD-título.md em chinês: o que foi feito, por quê, decisões/armadilhas, um destaque em uma frase. Para recuperar tarefas longas, leia apenas o registro anonimizado e o estado atual, depois continue os passos não concluídos; não implante do zero, não registre credenciais. Incorpore as condições da nova falha, evidências e reparos reutilizáveis nas referências, em vez de transformar um caso isolado em uma conclusão geral.