중국 본토 안에서 측정한 280개 사이트: 3분의 1은 끝내 로드를 마치지 못했다

사람들이 검색하는 질문은 어떤 사이트가 중국에서 차단되는가입니다. 그것은 잘못된 질문이며, 이것이 그 이유를 보여 주는 측정입니다.

저희는 중국 본토 안 탐침에서 280개 엔터프라이즈 소프트웨어·인프라 사이트를, 각 시도에 60초 상한을 두고 각각 세 번씩 요청했습니다. 840건의 요청. 한 실행은 페이지가 로드를 마친 경우에만 완료로 집계됩니다; 60초에도 여전히 진행 중인 실행은 폐기가 아니라 실패로 기록됩니다.

결과

결과	사이트	비율
모든 시도 완료	162	58%
어느 것도 완료 못 함	96	34%
일부 시도 완료	22	8%

조금이라도 응답한 모든 사이트에서, 첫 바이트까지의 중앙값은 742ms였습니다(90번째 백분위수 1,093ms). 완료한 사이트 중에서, LCP(최대 콘텐츠풀 페인트) 중앙값은 2.1초였습니다(90번째 백분위수 4.7초).

그다음, 그 어느 것보다 더 중요한 숫자:

끝내 완료하지 못한 96개 사이트 중, 66개는 응답했습니다. 첫 바이트가 도착했고, 대부분의 경우 페인트가 기록되었지만, 페이지는 끝내 완료되지 않았습니다. 오직 30개만이 아무런 응답도 내지 않았습니다.

같은 결과를 쓴 서로 다른 두 실패

두 그룹 모두 사용자에게는 동일하게 보입니다 — 페이지가 작동하지 않는다 — 그리고 그것들은 전혀 다른 문제입니다.

아무것도 내지 않은 30개가 사람들이 “차단”이라고 할 때 가리키는 것입니다. 그 목록은 두 회사가 지배합니다: 열 개의 Google 자산(Maps, Docs, reCAPTCHA, Tag Manager, Analytics, Cloud Functions, Hosted Libraries, Fonts 탐색 사이트, YouTube, 지원 페이지)과 Meta·X의 넷(Facebook, Instagram, Twitter, X). Snapchat도 거기 있습니다. 이것은 중국에서 운영하는 데 있어 잘 이해된 부분이며, 전송 문제가 아닙니다 — 응답하지 않는 목적지로의 요청은 그것이 어디서 오는지를 옮긴다고 해서 응답하게 되지 않습니다.

유용한 대조가 같은 데이터셋 안에 있습니다: bing.com/maps는 280개 사이트 전체에서 첫 바이트가 제일 빨랐습니다, 66ms로. 범주로서의 지도가 문제가 아닙니다. 특정 호스트가 문제입니다.

응답했지만 끝내 완료하지 못한 66개는 아무도 대비하지 않는 것이며, 두 배로 많습니다. 연결 확인은 통과합니다. 속도 테스트는 시간을 보고합니다. 200을 핑하는 모니터링은 초록으로 유지됩니다. 그런데 방문자가 여는 페이지는 끝내 사용 가능해지지 않습니다.

그 간극이 얼마나 벌어질 수 있는지 몇 가지 예:

사이트	첫 바이트	페인트	완료
Authentisign	108ms	2.6s	3 중 0
Framer	339ms	2.6s	3 중 0
AWS Route 53 콘솔	375ms	4.0s	3 중 0
Contentstack	1,104ms	28.0s	3 중 0
Freshdesk	718ms	14.2s	3 중 0

Authentisign은 센서스의 다른 어떤 사이트보다 빠르게 응답했지만 그 실행 중 어느 것도 완료하지 못했습니다. Contentstack은 28초 뒤에 페인트했습니다 — 누군가가 기다려서가 아니라 측정 도구가 계속 기다렸기 때문에만 존재하는 숫자입니다.

첫 바이트까지의 시간은 페이지가 작동하는지 알려 주지 않습니다. 그것이 이 데이터셋에서 가장 유용한 단 하나이며, 중국 밖에서 취한 속도 테스트나 어디서든 취한 첫 바이트 수치가 구매자가 실제로 묻는 질문에 답할 수 없는 이유입니다.

단일 사이트로는 보여 줄 수 없었던, 우리가 배운 것

공개 자산 CDN: 다섯 중 둘이 작동했다

호스트	결과
cdnjs	3 중 3 완료
Microsoft Ajax CDN	3 중 3 완료
Google Hosted Libraries	전혀 응답 없음
BootstrapCDN	3 중 0 완료
Font Awesome	3 중 0 완료

다섯 모두 보통 문서 head에서 참조되며, 거기서는 그것들이 해석될 때까지 브라우저가 페인트하지 않습니다. 그 위치가 그것들을 불균형하게 해롭게 만듭니다 — 실패하는 스크립트 CDN을 참조하는 페이지는 느리게 로드되는 것이 아니라, 멈춥니다.

사람들이 집어 드는 규칙 — “공개 CDN은 중국에서 작동하지 않는다” — 은 뒷받침되지 않습니다. 다섯 중 셋이 실패했고 둘은 괜찮았습니다. 실행 가능한 조언은 더 좁고 더 유용합니다: 실제로 의존하는 호스트를 측정하거나, 라이브러리를 자체 빌드에 번들링하여 그 질문을 제거하십시오. 번들링은 보통 어떤 전송 작업보다 작은 변경입니다.

한 벤더 전반의 공유된 실패 시그니처 — 그러나 그 전부는 아닌

네 개의 Adobe 자산이 타임아웃이 아니라 ERR_HTTP2_PROTOCOL_ERROR로 실패했습니다: Adobe Commerce, Magento, Marketo, Adobe Dynamic Tag Management. 프로토콜 수준의 실패는 혼잡과는 다른 진단입니다 — 그것은 연결이 전송 중에 중단되고 있음을 시사하며, 대역폭이나 PoP를 추가한다고 개선되지 않습니다.

같은 실행에서 측정된 Adobe Fonts는 모든 시도를 완료했습니다. 벤더 수준의 일반화는 측정을 견디지 못하며, 이것이 이 센서스가 브랜드가 아니라 호스트를 테스트하는 이유입니다.

같은 제품 범주, 반대의 결과

아홉 개의 팟캐스트 호스트 중, 다섯은 사용 가능한 로드를 내지 못했고 넷은 모든 시도를 완료했습니다. 같은 스토어프런트 플랫폼용 두 개의 로열티 앱 중, 하나는 모든 실행을 완료했고 다른 하나는 어느 것도 완료하지 못했습니다. 학습 플랫폼도 같은 식으로 갈렸습니다: 하나는 1.6초 페인트로 세 번의 시도를 모두 마쳤고, 다른 하나는 어느 것도 마치지 못했습니다.

여기에는 범주 수준의 답이 없습니다. 그것은 수사적 요점이 아닙니다 — “헤드리스 CMS를 써라”나 “임베드 영상을 피하라” 같은 형태의 조언이 실행 가능하지 않으며, 그것을 해결하는 유일한 것은 특정 호스트를 측정하는 것임을 뜻합니다.

한 벤더 자신의 호스트들조차 엇갈릴 수 있다

Google Fonts가 가장 깔끔한 예입니다. 페이지가 호출하는 스타일시트 엔드포인트 fonts.googleapis.com은 별도의 12시간 샘플링 실행에서 중앙값 111ms로 73번 중 73번 응답했습니다. 디자이너가 서체를 고르러 둘러보는 사이트 fonts.google.com은 세 번의 시도 중 어느 것도 완료하지 못했습니다. 방문자는 폰트를 받습니다; 디자이너는 새 폰트를 사러 갈 수 없습니다.

무엇을 제외했고, 왜

다섯 개의 호스트가 280개에 들어 있지 않습니다.

그중 셋 — fauna.com, stepzen.com, thin.dev — 은 중국 밖에서도 해석되지 않습니다. 그 서비스들은 더 이상 존재하지 않습니다. 넷째는 잘못된 벤더 URL을 담은 저희 자체 지식 베이스의 한 페이지였습니다; 그것이 가리킨 도메인은 어디에도 등록되어 있지 않습니다.

다섯째는 곱씹을 가치가 있는데, 거의 게시될 뻔했기 때문입니다. edg.io는 중국 안에서 ERR_CERT_COMMON_NAME_INVALID로 실패했습니다 — 실행에서 유일한 인증서 실패였고, 진정으로 진단적으로 보이는 시그니처였습니다. 저희는 이미 그것을 별개의 발견으로 정리해 두었는데, 그때 중국 밖에서의 확인이 같은 오류를 반환했습니다. Edgecast를 인수했던 Edgio는 2024년 9월 Chapter 11을 신청했고 그 콘텐츠 전송 네트워크는 2025년 1월 15일에 오프라인이 되었습니다; Akamai는 고객 계약을 샀지만 네트워크는 사지 않았습니다. 그 호스트의 인증서는 아무도, 어디서도 유지보수하지 않기 때문에 유지보수되지 않습니다.

죽은 제품은 중국 발견이 아닙니다. 비정상적으로 깔끔한 시그니처를 가진 실패 — 해석되지 않는 이름, 즉시 닫히는 연결, 일치하지 않는 인증서 — 는 기록되기 전에 그 나라 밖에서 검증할 가치가 있습니다. 저희는 이런 식으로 다섯을 잡아냈으며, 그중 하나는 저희 자체 샘플링 데이터가 반대라고 말하는데도 Google Fonts가 중국에서 작동하지 않는다고 게시하게 만들 뻔했습니다.

한계

• 탐침 하나, 도시 하나. cn-zhangjiakou의 상용 클라우드 회선. 데이터센터에서의 국제 전송은 기업 광대역 연결에서보다 실질적으로 낫기 때문에, 여기의 모든 수치는 최악의 경우가 아니라 하한입니다. 실제 사무실은 더 나쁜 것을 보게 됩니다.
• 사이트당 세 번의 시도. “도착한다”와 “하지 않는다”를 안정적으로 구분하기에는 충분하지만; 정밀한 지연 수치가 되기에는 충분하지 않습니다. 하루 전체에 걸쳐 샘플링한 곳에서는 — 서드파티 요청의 12시간 — 한 호스트의 첫 바이트까지의 시간이 가장 조용한 시각의 중앙값 493ms에서 저녁 피크의 1,086ms까지 흔들렸는데, 이는 세 번 실행의 중앙값으로는 볼 수 없는 폭입니다.
• 벤더 사이트이지, 고객 배포가 아님. 벤더 자신의 사이트가 어떻게 동작하는지는 그 위에 구축된 사이트가 어떻게 동작하는지가 아닙니다. 그것은 호스트에 대한 신호이지, 제품에 대한 판결이 아닙니다.
• 60초 상한은 하나의 선택입니다. 이 페이지 중 일부는 90초에 완료될 수도 있습니다. 어떤 방문자도 그렇게 오래 기다리지 않으므로, 저희도 그러지 않았습니다.

왜 답이 전송만의 문제가 아닌가

여기서 끝내면 편할 것입니다. 위의 모든 것이 도달 가능성 문제이고, 도달 가능성은 바이트가 어디서 서비스되는지를 바꿔 고칠 수 있는 부분이기 때문입니다. 그러나 전송을 중국 본토 안으로 옮기는 것은 엔지니어링 결정만이 아닙니다. 본토 안에서 서비스하는 것이야말로 ICP 비안 요건을 촉발하는 것입니다 — 비안은 본토 법인에 발급되고, 귀사의 호스팅·접속 방식에 묶이며, 접속 제공자는 비안되지 않은 사이트를 운반하는 것이 금지됩니다.

그래서 두 질문은 함께 도착하며, 아키텍처 시점에 한 번에 결정됩니다: 페이지가 도착할 수 있는가, 그리고 그것이 도착하게 될 곳에서 귀하가 그것을 서비스하도록 허가받았는가. 저희는 가용한 각 방식이 첫 번째 질문에 대해 실제로 무엇을 사는지를 웹사이트를 중국으로 전송하는 네 가지 방법에서 측정했습니다 — 중국 안에 있고, 올바르게 비안되었는데도, 여전히 로드를 마치지 못한 방식을 포함하여.

다음에 측정할 것

데이터센터 회선이 아니라 중국 사무실 광대역 연결에서의 같은 센서스로, 이는 여기의 모든 숫자를 더 나쁘게 만들고 게시하기에 덜 보기 좋은 비교가 될 것으로 예상합니다. 그래도 저희는 게시할 것입니다. 처음에 틀렸던 여덟 가지 방식을 포함한 방법론은 별도로 정리되어 있습니다.

측정은 21YunBox 중국 엔지니어링 팀이 2026년 8월 28~29일 중국 본토 안 탐침에서 수행했습니다. 모든 사이트의 결과 — 완료율, 첫 바이트까지의 중앙값, 페인트 중앙값, 실패 유형 — 는 호스트별로 기록됩니다.