양쪽 서버 다 정상, DNS도 정상, 그런데 도메인 하나만 계속 안 됐다. 원인을 끝까지 좁혀갔지만 결국 답을 못 찾은 채로 우회를 택한, 조금 다른 종류의 마무리 이야기다.

블로그를 옮길 때 썼던 것과 완전히 같은 구조 — 같은 토큰으로 두 기기에 커넥터를 하나씩 띄우는 방식 — 을 API용 도메인과 SSH용 도메인에도 그대로 적용했다. 블로그 때는 문제없이 됐던 방식인데, 이번엔 그 도메인만 응답이 아예 오지 않았다.

원인을 하나씩 지워나갔다. 새 기기의 origin(uvicorn 8000번 포트)은 로컬에서 직접 curl로 확인하니 즉시 정상 응답했다. 기존 기기(quantum2)의 origin도 마찬가지로 멀쩡했다. DNS 레코드도 API로 직접 조회해서 정확한 CNAME이 해당 터널을 가리키고 있는 걸 확인했다. Cloudflare Access 같은 접근 정책이 이 도메인에 걸려 있는지도 확인했지만 없었다. 심지어 같은 계정, 같은 방식으로 구성된 blog.mhub.uk는 그 사이에도 계속 200을 잘 돌려주고 있었다 — 즉 이 패턴 자체가 근본적으로 안 되는 게 아니라, 이 특정 터널 하나만 문제였다.

터널 로그를 보면 더 이상했다. curl 요청을 보내면 TLS 핸드셰이크까지 완전히 성공하고 HTTP/2 요청도 나가는데, 정작 그 요청이 커넥터에 도달한 흔적 자체가 로그에 없었다. 요청이 어딘가로는 가고 있는데, 두 커넥터 중 어느 쪽에도 잡히지 않는 상태였던 셈이다. 양쪽 origin이 멀쩡하다는 걸 이미 확인했으니, 이건 origin 문제가 아니라 이 터널 자체의 라우팅 어딘가에서 요청이 사라지고 있다는 뜻이었다.

여기서 원인을 계속 붙잡고 있을지, 다른 길을 낼지 결정해야 했다. 이미 이 프로젝트에서 한 번 써본 선택지가 있었다 — hts-project를 옮길 때, 기존 도메인과 씨름하는 대신 그 기기가 이미 쓰고 있던 다른 터널에 새 서브도메인(myhts.mhub.uk)을 얹는 방식으로 문제를 우회했던 적이 있다. 같은 방법을 여기에도 적용했다. 새로 발급받은 토큰이 필요 없었다 — 이미 그 기기에서 연결되어 있던 다른 터널에 API용 주소와 SSH용 주소 경로만 새로 추가했다. Cloudflare가 대시보드에서 추가한 라우트를 이미 연결된 커넥터에 그 자리에서 바로 반영해주는 방식이라, 커넥터를 재시작할 필요도 없었다.

검증은 두 가지 방식으로 했다. API용 주소는 curl로 바로 200과 정상 JSON 응답을 확인했다. SSH 프로토콜을 쓰는 SSH용 주소는 curl로는 검증할 수 없어서, cloudflared access tcp로 로컬 포트에 프록시를 띄운 뒤 그 포트로 실제 SSH 접속을 시도했다 — 존재하지 않는 계정으로 접속해서 “Permission denied"가 뜨면, 이건 인증이 거부됐다는 뜻이지 터널이 막혔다는 뜻이 아니다. 즉 엣지부터 커넥터, origin의 sshd까지 전체 경로가 살아있다는 증거로는 충분했다.

원인 불명인 채로 남겨둔 터널이 하나 있다는 게 찜찜하긴 하지만, 모든 미스터리를 끝까지 풀어야만 앞으로 나아갈 수 있는 건 아니다. 동작하는 새 경로가 있다면, 안 되는 원인을 계속 붙잡기보다 그 경로로 옮겨가는 것도 충분히 합리적인 선택이다.