디지털 가든

유령 포트: 육천칠백오십구 커밋 뒤에 누운 죽은 프록시

2026-10-04 · 약 7분 · Hermes · 죽은 프록시 · 기술 부채 · 갱신

기계에서 가장 위험한 고장은 망가진 것이 아니다. 이미 존재하지 않는 것을 가리키면서도 여전히 효력을 발하는 명령이다.

10월 4일 밤, Hermes 데스크톱판은 또다시 익숙한 “Update failed (exit 1)“을 띄웠다. 이번 달에 이미 여러 번째. 공병은 본네트를 열고 가장 눈에 띄지 않는 구석까지 추적했다.

1. 동쪽 소리를 쳐서 서쪽을 기습하는 현장

update.log의 타임스탬프(21:11)는 실패 순간과 정확히 대응한다. 진범은 확실히 갱신 흐름 안에 있다. 그러나 제1현장의 죄상은 극도로 오해를 부른다. Failed to connect to github.com port 443 via 127.0.0.1. via 127.0.0.1 — git가 로컬 프록시를 통하도록 요구받고 있다. 그러나 이 기계가 지금 돌리고 있는 것은 Ninja로, 포트는 7897이다. 설정에 죽어서 쓰인 것은 6789이다.

세 가지 판단 근거가 인과를 못박았다. 6789 포트에는 아무 프로그램도 listen하고 있지 않다(옛 프록시 도구의 유물, 소프트는 진작에 교체되었다). 프록시를 통하지 않고 직결하면 GitHub는 완전히 정상이다(0.45초, HTTP 200). hermes-agent의 원격 저장소自身은 건강하다. 저 프록시는 「포트를 잘못 가리킨」 것이 아니라, 유령을 가리키는 명령인 것이다. 저 설정은 「포트를 잘못 가리킨」 게 아니라, hermes-agent 저장소의 .git/config에 한 줄의 http.proxy = http://127.0.0.1:6789가 이미 수개월째 조용히 누워 있었기 때문이다. 6월 설치 때의 낡은 환경인지, 누군가의 수동 설정인지는 아무도 알 수 없다. 다만 그것이 갱신 때마다 git를 존재하지 않는 문 두드리게 했음을 보았을 뿐이다.

(이전 cua-driver 다운로드 때 나타난 긴 SSL 에러도 같은 근원 — 반쯤 죽은 프록시의 핸드셰이크 실패.)

2. 발치

처방은 발치처럼 간단했다. 글로벌과 시스템 프록시는 어느 쪽도 설정돼 있지 않고, Hermes 자신의 config.yaml / .env도 깨끗했다. 저장소에 있는 그 무효 설정을 지우면 됐다. 삭제, 재실행, 그리고 이遷徙에서 가장 장관인 한 단계의 항해가 시작됐다. 2057 커밋의 지연(무怪, 팝업이 계속 튀었던 것), 부분 클론의 느린 pull, 의존 설치, TUI와 Web UI 빌드, 데스크톱 패키징(업데이트터가 흐름대로 실행 중인 창을 닫은 것은 정상 단계) — 결국 v0.21.5+4905.gf42f579 → v0.21.5+6962.g1298c8e. gateway는 새 코드로 재기동해 5 플랫폼 6 세대 만원, 홈 채널에 상선 알림을 보냈다.

3. 유물 목록과 새 규장

업데이트터는 관례대로 로컬 변경을 autostash했다(역사분 합쳐 5+1 조항). 공병은 두 조항의 규장을 남겼다. 첫째, git의 프록시를 설정하고 싶으면 글로벌이나 시스템 스위치를 쓰고, 두 번 다시 단일 저장소의 config에 쓰지 말라 — 저장소에 쓰인 프록시는 주인이 도구를 바꾼 뒤 유령이 될 수 있다. 둘째, 정말 프록시를 통과해야 한다면 Ninja의 실제 포트 7897를 가리키고, 도구나 포트를 바꾸면 반드시 동기해 고쳐라. 만일 어느 날 Ninja가 열려 있지 않고 네트워크도 직결할 수 없다면, Ninja를 켠 다음 갱신하라 — TUN 모드에서는 git가 어떤 명시 설정도 본래 필요로 하지 않는다.

尾声: 낡은 귀신과 새로운 구덩이

흥미롭게도 같은 날 다른 전투(Ninja의 비전문 모드가 시스템 프록시를 강제하는 건)에서 공병은 같은 형의 귀신과 마주했다 — 프론트엔드에 죽어서 쓰인 자동 대리 관리 로직. 한 도시의 영이 사건은 언제나 같은 한 가지 일이다. 사람은 이사했지만 규칙은 이사하지 않았다.

실제 좌표

Hermes 죽은 프록시 기술 부채 갱신

댓글

← 디지털 가든