배포 직후 같은 주소가 200과 301을 번갈아 답했다

/about, /contact, /privacy 세 페이지를 새로 붙였다. 빌드는 정상이었다. 여섯 페이지가 나왔다.

배포하고 확인했더니 셋 다 301 로 튕겼다.

첫 번째 원인

이 도메인은 원래 다른 앱이 쓰던 주소다. 검색 유입이 살아 있어서, 옛 경로만 골라 하위 도메인으로 넘기는 Worker 가 앞에 있다.

그 목록에 about, privacy, contact 가 들어 있었다. 옛 앱에도 같은 이름의 페이지가 있었기 때문이다. 새로 만든 페이지가 자기 이름 때문에 밀려났다.

셋을 목록에서 뺐다. 특히 개인정보처리방침은 이 도메인에서 열려야 한다. 광고 심사 요건이다.

두 번째가 이상했다

다시 배포하고 확인했다.

200  /
200  /about
200  /contact
301  /privacy
200  /blog

둘은 되는데 하나만 안 됐다. 같은 수정, 같은 배포인데.

캐시를 의심했다. 쿼리 문자열을 붙여 캐시를 우회하고 다시 요청했다.

200 301 301

같은 주소가 요청마다 다르게 답했다.

원인

Cloudflare 는 엣지가 전 세계에 흩어져 있다. 배포한 버전이 모든 엣지에 동시에 반영되지 않는다. 갱신되는 동안 어떤 엣지는 새 Worker 를, 어떤 엣지는 옛 Worker 를 돌린다.

내 요청이 매번 같은 엣지로 가지 않으니, 같은 주소가 200 과 301 을 오갔다. /about 과 /contact 가 먼저 200 을 준 것도 우연이다. 그때 걸린 엣지가 이미 갱신돼 있었을 뿐이다.

확인 방법

4초 간격으로 12번, 이어서 연속 10번을 찍었다.

200 200 200 200 200 200 200 200 200 200 200 200
200 200 200 200 200 200 200 200 200 200

안정됐다. 처음 확인한 시점이 전파 중이었던 것뿐이다.

여기서 배운 것

배포 직후 한 번 찍고 판단하면 안 된다. 특히 실패가 나왔을 때 그렇다.

성공이 나오면 그 엣지는 갱신됐다는 뜻이니 정보가 확실하다. 실패가 나오면 두 가지가 겹쳐 있다. 진짜 안 고쳐졌거나, 아직 안 퍼졌거나. 이 둘을 한 번의 요청으로는 구분할 수 없다.

이번엔 하필 진짜 버그(Worker 목록)와 전파 지연이 연달아 왔다. 첫 번째를 고치고 나서 두 번째를 만나니, 수정이 안 먹은 줄 알고 코드를 다시 뒤졌다. 그게 시간 낭비였다.

지금 하는 방식

배포 뒤 검증은 이렇게 한다.

1. 캐시 우회용 쿼리를 붙여 요청한다
2. 한 번이 아니라 10회 이상 반복한다
3. 전부 같은 답이 나올 때까지는 판단을 미룬다
4. 섞여 나오면 전파 중이다. 몇십 초 기다린다

배포가 끝났다는 명령줄 출력과 전 세계에서 그 버전이 돈다는 것은 다른 얘기다.

남은 것

전파가 언제 끝나는지 알려주는 신호가 있는지는 못 찾았다. 응답 헤더에 버전이 실려 있으면 좋겠는데, 지금은 그냥 여러 번 찍어보는 것 말고는 방법을 모른다.