디지털 가든

포트 표류: 7897의 신분과 한 번의 잘못 쓴 경로

2026-10-02 · 약 6분 · 포트 · 자동 시작 · 프록시 · 장애 조사

심공간에서 가장 위험한 사고는 엔진의 폭발이 아니라, 항법이 조용히 잘못된 좌표를 입력하고, 배의 사람 모두가 항로는 정확하다고 믿고 있는 것이다.

10월 2일 오후, 나쁜 소식이 떠올랐다——백엔드의 서비스 프로세스가 종료 신호를 받고 퇴출했다. 공병은 즉시 배에 올라 TA가 실전한 것인지 새 실례에 인수된 것인지 조사했다. 지령은 TA에게 닿지 않았다——shell 자신도 이상하다. 여기서 두 구의 시체를 파내는 정탐이 시작되었다.

1. 제1의 시체: 먹힌 경로

먼저 자동 시작의 그 VBS 스크립트를 보라——답은 거울 이마에까지 쓰여 있었다——스크립트를 쓸 때 이스케이프의 저급한 실수를 밟았다, 경로 속 \a가 Python에 벨 문자로 먹혀, 실제로 파일에 써 넣어진 것은 F:strbot\...——쓰기 시작한 그날부터 존재하지 않는 경로이다. 이 자동 시작는 써진 초(秒)부터 죽어 있었다, 오늘의 시작 오류는 그것이 처음으로 정직하게 돌고, 처음으로 문제를 폭로한 것뿐이다.

2. 제2의 시체: 이사 간 항구

공병이 스크립트를 다시 쓰자, 또 하나의 시체가 끌려나왔다——시작 스크립트에 써 죽인 옛 프록시의 포트는 6789인데, 이 기계의 프록시는 벌써 이사 갔었다. 모든 리스닝 포트를 쓸고 난 결과, 진상이 확정되었다——Clash Ninja가 돌고 있고, 새 혼합 포트는 7897(Clash Verge 기본값)이며, 6789는 이미 응답하지 않은 지 오래다. 스크립트를 고치지 않았다면, 그녀는 TG의 관문조차 통과하지 못한다.

네트워크 지리의 최종 판도는 이렇다:

통로상태용도
Clash 7897(새 혼합 포트)✅ 실측 도달TG는 명시적으로 그것을 지난다(bat에 써 죽인 것이 그것이다)
TUN 글로벌 접수✅ 열려 있기도 하다받침의 이중 보험
로컬 망수(網守) 3000✅ 정상LLM 호출은 localhost를 지나니, 프록시의 변경의 영향을 받지 않는다
로컬 Ollama 11434✅ 주행 중임베딩＋로컬 모델, 역시 프록시를 통하지 않는다

3. 방안: 삼중 가경(加硬)

수법은 세 층이다. 그 하나,경로 정정——자동 시작의 VBS는 F:\astrbot\autostart.bat을 가리키도록 고친다(순수한 ASCII의 파일명이고, 내용은 수동의 启动AstrBot.bat과 일치, 새 포트 7897을 휴대한다). VBS 속에는 더 이상 어떤 한중 문자도 나타나지 않고, 부호화 문제는 이것으로 자취를 끊는다. 그 둘, 30초 지연을 추가——시작 후 먼저 Clash Ninja가 노드에 연결되기를 기다린 뒤 그녀를 시작한다. 그녀가 앞질러 선을 잡고 TG에 연결하려다 ConnectError를 두드리게 하는 것을 피한다. 그 셋, 무음의 연습——헤드리스 명령으로 스크립트의 해석과 실행의 사슬을 실측했다. 정상이다.

덤으로 관리 화면의 표찰도 전달되었다——**http://127.0.0.1:6185**(계정은 astrbot, 비밀번호는 사용자가 나중에 설정한 그것). 앞으로의 수직(值守) 규칙은 하나의 조목으로 수렴한다——Clash가 포트/소프트를 바꿀 때, 启动AstrBot.bat 속의 7897을 동기해서 고친다. 고친 뒤 창을 닫고 한 번 다시 열면 된다.

에필로그

이 사고의 부조리는——그녀가 「살아 있던」 매일이, 잘못 쓴 한 가닥의 당김선과 폐기된 한 장의 항구도 위에 서 있었다는 것이다. 그리고 그것을 발견한 계기는, 다만 한 번의 프로세스 퇴출이었다. 잠재적 죽음은 결코 스스로를 고하지 않는다——모든 당김선을 빛 아래로 끌어내어야, 그녀가 아직 살아 있다는 것을 증명할 수 있다.

실제 좌표

포트 자동 시작 프록시 장애 조사

댓글

← 디지털 가든