A configuração básica de proxy reverso exige apenas três decisões, e este guia oferece ajuda com cada uma: o nome do host, o caminho e o backend. Uma busca por proxy HTTP pode significar um proxy forward ou um proxy reverso, e aqui você planeja e verifica um servidor que você mesmo administra. O agente nunca decide por você qual host ou caminho é o correto. Ele escreve o que você pede, mostra cada alteração como um diff e relata o resultado real de cada comando, para que você possa ver o efeito de cada decisão antes da próxima. Percorra os quatro passos abaixo na ordem e trate o plano de roteamento como o documento que você e o agente seguem juntos, desde o primeiro comando até o último pedido.
Inicie o Segment Route e abra a pasta de trabalho que contém suas configurações e arquivos de rota. As ferramentas de arquivo atuam nesta pasta, portanto, uma pasta limpa com apenas os arquivos relevantes para este domínio mantém os diffs curtos e os resultados da busca legíveis. Se seus arquivos ativos estiverem em um servidor que você possui, copie-os para a pasta primeiro, ou escolha o ambiente SSH para os comandos e mantenha o plano na pasta.
Peça ao agente para escrever o routing-plan.txt com suas rotas, seus redirecionamentos e o código de status esperado para cada um. O plano é texto simples, editável, e serve como a lista contra a qual você compara os resultados reais no final. Defina uma expectativa para cada rota e cada redirecionamento, para que nenhuma regra fique sem verificação. Mantenha o arquivo curto e legível.
Aprove o diff para cada regra, depois deixe o Shell executar seu comando de teste de configuração antes de qualquer recarga. No modo Ask first, o agente pausa antes de cada alteração, e o cartão do teste mostra o código de saída real e a saída completa. Nunca recarregue antes que o teste tenha passado, e mantenha o backup do arquivo anterior até que o novo comportamento seja confirmado.
Solicite cada endereço com seu comando de requisição, leia o código de status e o cabeçalho Location, e compare-os com seu plano. Se um valor diferir, restaure o backup, recarregue e altere uma regra novamente. Repita até que todas as expectativas do plano correspondam ao resultado, então mantenha o plano final como registro do que a configuração deve fazer.
.3 arquivosroutes.confloadedrouting-plan.txtsavedyour request commandrecorded# routing plan for my own domain
# one line per rule, written before any change
route 1: host app, path /api, goes to service api
route 2: host app, path /, goes to service web
route 3: host admin, path /, goes to service admin
redirect 1: old page to new page, code 301
redirect 2: www host to bare host, code 301
redirect 3: http to https, code 301
# status to expect after the change
expect 1: app path /api answers with a success code
expect 2: old page answers 301 and gives the new address
# keep the old configuration file as a backup
# end of routing planCada linha é uma regra ou uma expectativa. Escrito primeiro, o plano lhe dá algo para comparar os códigos de status reais contra após cada alteração, e uma alteração que quebre uma expectativa é fácil de detectar. Hosts, caminhos e serviços são apenas exemplos; substitua-os pelos seus próprios e mantenha o plano ao lado da configuração que ele descreve. A palavra redirect com um código é suficiente para o agente saber o que escrever.
Este guia de self hosting com um servidor proxy reverso na frente dos seus serviços começa encontrando onde as regras vivem. list_dir mostra a pasta de trabalho, glob lista os arquivos que parecem listas de rotas, e grep os pesquisa pelas palavras route e redirect. O resultado é uma lista curta com nomes de arquivos e números de linha. Nada muda ainda. Escolha o arquivo que contém as regras para o seu domínio, abra-o com read_file e solicite cada endereço com seu comando de requisição para anotar o código de status atual. Revise a lista no modo Plan only se quiser que o agente proponha a ordem de trabalho primeiro, e salve as anotações ao lado do seu plano de roteamento para que os primeiros status codes fiquem registrados.
Altere uma regra por vez, porque um diff pequeno é fácil de avaliar. edit_file lê o arquivo, propõe a nova linha e mostra um diff com as linhas adicionadas e removidas. Quando surge uma dúvida sobre uma regra de redirecionamento de subdomínio, o agente mostra a regra ao lado do código que ela deve retornar, e você decide. No modo Ask first, nada é salvo até que você aceite. Auto-run salvaria imediatamente, então use-o apenas em arquivos que você pode restaurar. Mantenha o arquivo antigo como backup, aceite o diff e passe para a próxima etapa. Rejeite o diff se uma linha surpreender você e peça uma alteração menor.
Uma recarga com um arquivo quebrado pode tirar um site funcional do ar, então teste primeiro. Shell executa seu comando de teste de configuração, e o sucesso é julgado pelo código de saída real: um código de aprovação significa que o arquivo foi parseado, qualquer outro código significa que você permanece na configuração antiga. O cartão se expande para a saída completa, incluindo o número da linha de um erro. Corrija-o com outro diff pequeno. Após um teste aprovado, recarregue, solicite o endereço novamente e compare os status codes http das execuções antiga e nova. Revise a saída você mesmo, pois um teste aprovado diz apenas que a sintaxe é válida e não que a rota está correta.
Os status codes são agrupados pelo primeiro dígito: 2xx sucesso, 3xx redirecionamento, 4xx erro do cliente, 5xx erro do servidor. Para um proxy, 502 significa uma resposta inválida do backend, 503 significa que o serviço não está disponível, 504 significa que o backend demorou demais para responder, e 404 significa not found. http_get busca uma página do seu serviço próprio, e seu comando de requisição mostra o novo endereço de um redirecionamento. Se um código diferir do seu plano, restaure o arquivo de backup, recarregue e teste novamente. Então altere o plano ou a regra e repita, uma regra por rodada. Um plano de roteamento curto e um arquivo de backup são tudo o que você precisa para o rollback.
