Segment Route
워크플로우

계획 파일에서 확인된 결과로 이어지는 HTTP 프록시 라우팅

03
프록시 설정

도메인 하나에 라우팅 설정하기

기본적인 역방향 프록시 설정에는 세 가지 결정만 필요하며, 이 가이드는 각 단계에서 도움을 드립니다: 호스트 이름, 경로 및 백엔드입니다. HTTP 프록시 검색은 정방향 또는 역방향 프록시를 의미할 수 있으며, 여기서는 직접 운영하는 서버를 계획하고 확인합니다. 에이전트는 어떤 호스트나 경로가 적합한지 결정하지 않습니다. 요청한 내용을 기록하고, 변경 사항을 diff로 표시하며, 모든 명령어의 실제 결과를 보고하므로 다음 결정을 내리기 전에 각 결정의 효과를 확인할 수 있습니다. 아래 네 단계를 순서대로 진행하고, 라우팅 계획을 첫 번째 명령어부터 마지막 요청까지 에이전트와 함께 따르는 문서로 취급하세요.

01

폴더 열기

Segment Route를 시작하고 구성 파일과 라우팅 파일이 있는 작업 폴더를 엽니다. 파일 도구는 이 폴더에서 작동하므로, 이 도메인에 관련된 파일만 있는 깔끔한 폴더를 유지하면 diff가 짧아지고 검색 결과가 읽기 쉬워집니다. 라이브 파일이 소유한 서버에 있는 경우 먼저 폴더에 복사하거나, 명령어에 대한 SSH 환경을 선택하고 계획을 폴더에 유지하세요.

02

계획 작성하기

에이전트에게 라우팅, 리다이렉션 및 각 항목에 대한 예상 상태 코드가 포함된 routing-plan.txt를 작성하도록 요청하세요. 계획은 일반 텍스트이며 편집할 수 있으며, 최종적으로 실제 결과와 비교할 목록입니다. 모든 라우트와 리다이렉션마다 하나의 기대치를 명시하여 확인되지 않은 규칙이 없도록 하세요. 파일을 짧고 읽기 쉽게 유지하세요.

03

수정 및 테스트

각 규칙에 대한 diff를 승인한 후, 리로드 전에 Shell이 구성 테스트 명령어를 실행하도록 하세요. 'Ask first' 모드에서는 에이전트가 변경 전마다 일시 정지하며, 테스트 카드에는 실제 종료 코드와 전체 출력이 표시됩니다. 테스트가 통과하기 전에 리로드하지 마세요. 새 동작이 확인될 때까지 이전 파일의 백업을 유지하세요.

04

결과 확인하기

요청 명령어로 각 주소를 요청하고, 상태 코드와 Location 헤더를 읽은 후 계획과 비교하세요. 값이 하나라도 다르면 백업을 복원하고 리로드한 후 규칙을 하나 더 수정하세요. 계획의 모든 기대치가 결과와 일치할 때까지 반복한 후, 최종 계획을 구성이 수행해야 하는 내용을 기록하는 문서로 보관하세요.

일반 텍스트의 라우팅 계획

routing-plan.txt
# 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 plan

각 줄은 하나의 규칙 또는 하나의 기대치를 나타냅니다. 먼저 작성된 계획은 변경 후 실제 상태 코드와 비교할 기준을 제공하며, 기대치를 깨뜨리는 변경은 쉽게 발견할 수 있습니다. 호스트, 경로 및 서비스는 예시일 뿐이므로 자신의 것으로 대체하고, 설명하는 구성 파일 옆에 계획을 유지하세요. 코드와 함께 redirect라는 단어만 있으면 에이전트가 무엇을 작성해야 하는지 알 수 있습니다.

모든 HTTP 프록시 변경을 위한 안전한 순서

규칙이 포함된 파일 찾기

서비스 앞에 역방향 프록시 서버가 있는 이 셀프 호스팅 가이드는 규칙이 어디에 있는지 찾는 것으로 시작합니다. list_dir은 작업 폴더를 표시하고, glob은 라우트 목록처럼 보이는 파일을 나열하며, grep은 route와 redirect라는 단어를 검색합니다. 결과는 파일 이름과 줄 번호가 포함된 짧은 목록입니다. 아직 변경되지 않았습니다. 자신의 도메인에 대한 규칙이 포함된 파일을 선택하고 read_file로 연 다음, 요청 명령어로 각 주소를 요청하여 현재 상태 코드를 기록하세요. 에이전트가 작업 순서를 제안하도록 하려면 'Plan only' 모드에서 목록을 검토하고, 첫 번째 상태 코드가 기록되도록 계획을 옆에 저장하세요.

한 번에 하나의 규칙 수정하기

작은 diff는 판단하기 쉽기 때문에 규칙을 하나씩 변경하세요. edit_file은 파일을 읽고 새 줄을 제안하며 추가 및 제거된 줄이 표시된 diff를 보여줍니다. 서브도메인 리다이렉션 규칙에 대한 질문이 발생하면 에이전트는 반환해야 하는 코드 옆에 규칙을 표시하며, 최종 결정은 사용자의 몫입니다. 'Ask first' 모드에서는 승인할 때까지 저장되지 않습니다. 'Auto-run'는 즉시 저장하므로 복원 가능한 파일에만 사용하세요. 이전 파일을 백업으로 보관하고 diff를 승인한 후 다음 단계로 이동하세요. 한 줄이 놀라움을 주면 diff를 거부하고 더 작은 변경을 요청하세요.

리로드 전에 테스트하기

손상된 파일로 리로드하면 작동 중인 사이트가 다운될 수 있으므로 먼저 테스트하세요. Shell은 구성 테스트 명령어를 실행하며, 성공 여부는 실제 종료 코드로 판단합니다: 통과하는 코드는 파일이 구문 분석되었음을 의미하고, 그렇지 않으면 이전 구성에 머무릅니다. 카드는 오류의 줄 번호를 포함한 전체 출력으로 확장됩니다. 작은 diff로 수정하세요. 테스트가 통과한 후 리로드하고 주소를 다시 요청하여 이전 및 새 실행의 HTTP 상태 코드를 비교하세요. 테스트 통과는 구문이 유효함을 의미할 뿐 라우팅이 정확함을 의미하지 않으므로 출력을 직접 검토하세요.

코드 읽기 및 롤백하기

상태 코드는 첫 번째 숫자에 따라 그룹화됩니다: 2xx 성공, 3xx 리디렉션, 4xx 클라이언트 오류, 5xx 서버 오류. 프록시의 경우 502는 백엔드에서 유효하지 않은 응답을 의미하고, 503은 서비스를 사용할 수 없음을 의미하며, 504는 백엔드가 너무 느리게 응답했음을 의미하고, 404는 찾을 수 없음을 의미합니다. http_get은 자신의 서비스의 페이지 하나를 가져오고, 요청 명령어는 리다이렉션의 새 주소를 보여줍니다. 코드가 계획과 다르면 백업 파일을 복원하고 리로드한 후 다시 테스트하세요. 그런 다음 계획이나 규칙을 변경하고 라운드당 하나의 규칙으로 반복하세요. 짧은 라우팅 계획과 백업 파일이 필요한 모든 롤백 수단입니다.

Windows용 Segment Route

에이전트와 함께 다음 라우팅 변경을 계획하세요

Segment Route 다운로드 ↗