Una configurazione base di reverse proxy richiede solo tre decisioni, e questa guida ti aiuta per ciascuna: il nome host, il percorso e il backend. Una ricerca per proxy HTTP può indicare un proxy forward o reverse; qui pianifichi e verifichi un server che gestisci personalmente. L'agente non decide mai per te quale host o percorso sia corretto. Scrive ciò che chiedi, mostra ogni modifica come un diff e riporta il risultato reale di ogni comando, così da vedere l'effetto di ogni decisione prima della successiva. Segui i quattro passaggi seguenti in ordine e considera il piano di routing come il documento che tu e l'agente seguite dal primo comando all'ultima richiesta.
Avvia Segment Route e apri la cartella di lavoro che contiene la configurazione e i file di routing. Gli strumenti per i file operano in questa cartella, quindi una cartella pulita con solo i file rilevanti per questo dominio mantiene i diff brevi e i risultati di ricerca leggibili. Se i file attivi si trovano su un server di tua proprietà, copiali prima nella cartella, oppure scegli l'ambiente SSH per i comandi e mantieni il piano nella cartella.
Chiedi all'agente di scrivere routing-plan.txt con le rotte, i redirect e il codice di stato che ti aspetti per ciascuno. Il piano è testo semplice, puoi modificarlo ed è l'elenco con cui confrontare i risultati reali alla fine. Assegna un'aspettativa per ogni rotta e ogni redirect, così nessuna regola rimarrà senza verifica. Mantieni il file breve e leggibile.
Approva il diff per ogni regola, quindi lascia che Shell esegua il comando di test della configurazione prima di qualsiasi riavvio. In modalità Ask first l'agente si ferma prima di ogni modifica, e la scheda del test mostra il codice di uscita reale e l'output completo. Non riavviare mai prima che il test sia superato e mantieni il backup del file precedente finché il nuovo comportamento non è confermato.
Richiedi ogni indirizzo con il tuo comando di richiesta, leggi il codice di stato e l'intestazione Location, e confrontali con il piano. Se un valore differisce, ripristina il backup, riavvia e modifica di nuovo una regola. Ripeti finché ogni aspettativa nel piano non corrisponde al risultato, quindi conserva il piano finale come registrazione di ciò che la configurazione dovrebbe fare.
.3 fileroutes.confcaricatorouting-plan.txtsalvatoyour request commandregistrato# 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 planOgni riga è una regola o un'aspettativa. Scritto per primo, il piano ti dà qualcosa con cui confrontare i codici di stato reali dopo ogni modifica, e una modifica che rompe un'aspettativa è facile da individuare. Host, percorsi e servizi sono solo esempi; sostituiscili con i tuoi e tieni il piano accanto alla configurazione che descrive. La parola redirect con un codice è sufficiente per far sapere all'agente cosa scrivere.
Questa guida per l'auto-hosting con un server reverse proxy davanti ai tuoi servizi inizia trovando dove risiedono le regole. list_dir mostra la cartella di lavoro, glob elenca i file che sembrano elenchi di rotte e grep li cerca per le parole route e redirect. Il risultato è un elenco breve con nomi di file e numeri di riga. Nulla cambia ancora. Scegli il file che contiene le regole per il tuo dominio, aprilo con read_file e richiedi ogni indirizzo con il tuo comando di richiesta per annotare il codice di stato corrente. Rivedi l'elenco in modalità Plan only se vuoi che l'agente proponga prima l'ordine di lavoro, e salva le note accanto al piano di routing in modo che i primi codici di stato siano registrati.
Modifica una regola alla volta, perché un diff piccolo è facile da valutare. edit_file legge il file, propone la nuova riga e mostra un diff con le righe aggiunte e rimosse. Quando sorge una domanda su una regola di redirect per un sottodominio, l'agente mostra la regola accanto al codice che dovrebbe restituire, e tu decidi. In modalità Ask first nulla viene salvato finché non accetti. Auto-run salverebbe immediatamente, quindi usalo solo su file che puoi ripristinare. Tieni il file vecchio come backup, accetta il diff e passa al passaggio successivo. Rifiuta il diff se una riga ti sorprende e chiedi una modifica più piccola.
Un riavvio con un file rotto può mettere giù un sito funzionante, quindi testa prima. Shell esegue il tuo comando di test della configurazione, e il successo è giudicato dal codice di uscita reale: un codice di passaggio significa che il file è stato analizzato, qualsiasi altro codice significa che rimani sulla vecchia configurazione. La scheda si espande per mostrare l'output completo, incluso il numero di riga di un errore. Correggilo con un altro diff piccolo. Dopo un test superato, riavvia, richiedi di nuovo l'indirizzo e confronta i codici di stato http delle esecuzioni vecchia e nuova. Rivedi l'output tu stesso, poiché un test superato dice solo che la sintassi è valida e non che la rotta è corretta.
I codici di stato sono raggruppati per la prima cifra: 2xx successo, 3xx reindirizzamento, 4xx errore client, 5xx errore server. Per un proxy, 502 significa una risposta non valida dal backend, 503 significa che il servizio non è disponibile, 504 significa che il backend ha risposto troppo lentamente e 404 significa non trovato. http_get recupera una pagina del tuo servizio e il tuo comando di richiesta mostra il nuovo indirizzo di un redirect. Se un codice differisce dal piano, ripristina il file di backup, riavvia e testa di nuovo. Poi modifica il piano o la regola e ripeti, una regola per round. Un breve piano di routing e un file di backup sono tutto il rollback di cui hai bisogno.
