Basic reverse proxy setup needs only three decisions, and this guide offers help with each: the host name, the path and the backend. An http proxy search can mean a forward or a reverse proxy, and here you plan and check a server that you run yourself. The agent never decides for you which host or path is right. It writes what you ask for, shows each change as a diff, and reports the real result of every command, so you can see the effect of each decision before the next one. Work through the four steps below in order, and treat the routing plan as the document that you and the agent both follow from the first command to the last request.
Start Segment Route and open the working folder that holds your configuration and route files. The file tools work in this folder, so a clean folder with only the files that matter for this domain keeps the diffs short and the search results readable. If your live files sit on a server that you own, copy them into the folder first, or choose the SSH environment for the commands and keep the plan in the folder.
Ask the agent to write routing-plan.txt with your routes, your redirects and the status code you expect for each. The plan is plain text, you can edit it, and it is the list that you compare the real results against at the end. Name one expectation for every route and every redirect, so that no rule is left without a check. Keep the file short and readable.
Approve the diff for each rule, then let Shell run your config test command before any reload. In Ask first mode the agent pauses before every change, and the card for the test shows the real exit code and the full output. Never reload before the test has passed, and keep the backup of the previous file until the new behaviour is confirmed.
Request each address with your request command, read the status code and the Location header, and compare them with your plan. If one value differs, restore the backup, reload, and change one rule again. Repeat until every expectation in the plan matches the result, then keep the final plan as a record of what the configuration is supposed to do.
.3 filesroutes.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 planEach line is one rule or one expectation. Written first, the plan gives you something to compare the real status codes against after every change, and a change that breaks an expectation is easy to spot. Hosts, paths and services are examples only; replace them with your own, and keep the plan next to the configuration it describes. The word redirect with a code is enough for the agent to know what to write.
This self hosting guide with a reverse proxy server in front of your services starts by finding where the rules live. list_dir shows the working folder, glob lists the files that look like route lists, and grep searches them for the words route and redirect. The result is a short list with file names and line numbers. Nothing changes yet. Pick the file that holds the rules for your own domain, open it with read_file, and request each address with your request command to write down the current status code. Review the list in Plan only mode if you want the agent to propose the order of work first, and save the notes next to your routing plan so that the first status codes are on record.
Change one rule at a time, because a small diff is easy to judge. edit_file reads the file, proposes the new line and shows a diff with the added and removed lines. When a question about a subdomain redirect rule comes up, the agent shows the rule next to the code it should return, and you decide. In Ask first mode nothing is saved until you accept. Auto-run would save at once, so use it only on files you can restore. Keep the old file as a backup, accept the diff, and move to the next step. Reject the diff if one line surprises you, and ask for a smaller change.
A reload with a broken file can take a working site down, so test first. Shell runs your config test command, and success is judged by the real exit code: a passing code means the file parsed, anything else means you stay on the old configuration. The card expands to the full output, including the line number of a mistake. Fix it with another small diff. After a passing test, reload, request the address again and compare the http status codes of the old and the new run. Review the output yourself, since a passing test says only that the syntax is valid and not that the route is right.
Status codes are grouped by their first digit: 2xx success, 3xx redirection, 4xx client error, 5xx server error. For a proxy, 502 means an invalid answer from the backend, 503 means the service is unavailable, 504 means the backend answered too slowly, and 404 means not found. http_get fetches one page of your own service, and your request command shows the new address of a redirect. If a code differs from your plan, restore the backup file, reload and test again. Then change the plan or the rule and repeat, one rule per round. A short routing plan and a backup file are all the rollback you need.
