
핵심 발견
우리는 미국, 유럽, 일본에서 11개 서비스의 실제 리디렉션 링크 12개가 응답하는 데 걸리는 시간을 측정했습니다. 가장 느린 것은 평균 388ms, 도쿄에서는 823ms가 걸렸고, 가장 빠른 것은 17ms였습니다. 두 가지 교훈이 두드러집니다. 방문자가 어디에 있는지가 어떤 서비스를 사용하는지 못지않게 중요하다는 점, 그리고 링크 하나만으로는 전체 서비스의 속도를 알 수 없다는 점입니다. 이 글의 끝에서 여러분의 링크를 무료로 직접 테스트할 수 있습니다.
첫 번째 바이트가 도착하기까지 823ms. 우리가 도쿄에서 테스트한 Cuttly 링크의 중앙값이 바로 그것이었으며, 프랑크푸르트에서는 129ms, 워싱턴 DC에서는 212ms였습니다. 아무도 그 숫자를 보지 못하지만, 실제 페이지가 로딩을 시작하기 전까지 모든 방문자는 그 시간을 기다립니다.
그래서 우리는 측정했습니다. 2026년 10월 16일, 무료 리디렉션 속도 테스트를 사용해 11개 서비스에 걸친 12개의 리디렉션 링크 시간을 측정했습니다. 아래에는 순위가 있고, 그다음에는 각 링크를 가장 느린 것부터 가장 빠른 것까지 하나씩 살펴보며, 마지막에 이 모든 것이 의미하는 바를 정리합니다.

Average of the three regional medians, first response only. RedirHub test, Oct 16, 2026.
한눈에 보는 순위#
시간은 밀리초(ms)로 표시되며(1,000ms는 1초), 방문자가 다음 단계로 이동하기 전에 리디렉션이 응답하는 데 걸리는 시간을 나타냅니다. 기술적인 이름은 TTFB(time to first byte, 첫 바이트까지의 시간)입니다. 더 낮을수록 좋습니다. redirect.pizza는 두 개의 링크를 테스트했기 때문에 두 번 나타납니다. 그중 첫 번째만 순위가 매겨집니다.
| Rank | 서비스 및 URL 유형 | DC / 프랑크푸르트 / 도쿄(ms) | Average (ms) | Status |
|---|---|---|---|---|
| 1 | Cuttly · 공개 단축 링크 | 212 / 129 / 823 | 388.0 | 301 |
| 2 | redirect.pizza · URL A | 303 / 43 / 735 | 360.3 | 301 |
| — | redirect.pizza · URL B, 동일 서비스(공식 예시) | 30 / 12 / 111 | 51.0 | 301 |
| 3 | urllo / EasyRedir · 기존 도메인 마이그레이션(2회 경유) | 179 / 428 / 298 | 301.7 | 301 |
| 4 | Rebrandly · 공개 단축 링크(3회 경유) | 29 / 298 / 466 | 264.3 | 301 |
| 5 | Bitly · 공개 단축 링크(2회 경유, 1회는 HTTP 경유) | 26 / 119 / 205 | 116.7 | 301 |
| 6 | Vercel · 우리가 설정한 리디렉션 규칙 | 70 / 73 / 89 | 77.3 | 301 |
| 7 | Short.io · 공개 단축 링크 | 15 / 15 / 109 | 46.3 | 302 |
| 8 | Dub · 공식 단축 링크 | 39 / 35 / 40 | 38.0 | 302 |
| 9 | TinyURL · 공개 단축 링크 | 29 / 29 / 44 | 34.0 | 301 |
| 10 | Cloudflare · 우리가 설정한 리디렉션 규칙 | 30 / 35 / 25 | 30.0 | 301 |
| 11 | RedirHub · redirhub.com에서 www로 | 15 / 17 / 18 | 16.7 | 301 |
아래 각 링크 아래에는 속도 테스트에서 해당 페이지 자체의 스크린샷이 있습니다. 따라서 이를 열어 다시 실행할 수 있습니다. 우리는 세 지역 모두에서 모든 페이지를 다시 실행했으며, 표에서 사용하는 동일한 평균값을 사용했습니다. 실시간 수치는 실행할 때마다 달라지므로, 각 캡션에는 재실행 결과와 랭킹 라운드 수치가 모두 포함됩니다. 여러 홉이 있는 체인의 경우 첫 번째 홉만 측정했으며, 추가 홉은 방문자에게 그만큼 더 비용을 발생시킵니다.
1. Cuttly: 388 ms#
Google Colab 노트북을 가리키는 공개 Cuttly 단축 링크입니다. 세 지역 모두에서 단일 301을 반환했으므로 설정에는 문제가 없습니다. 비용은 거리입니다: 프랑크푸르트에서 129 ms, 워싱턴 DC에서 212 ms, 도쿄에서 823 ms로, 같은 링크인데도 6배 차이가 납니다.

One short link, three regions. Median of 5 runs each.

Speed test page for cutt.ly/rgdfBIa, re-run from all three regions on October 16, 2026: 378 ms (ranking round: 388 ms).
이 테스트 열기: cutt.ly/rgdfBIa
2. redirect.pizza: 360 ms and 51 ms#
가장 놀라운 결과입니다. 같은 라운드에서 redirect.pizza 링크 두 개를 테스트했습니다. 둘 다 유효한 인증서와 함께 하나의 301을 반환했습니다. URL A인 test.redirect.pizza는 평균 360.3 ms였고 도쿄에서는 735 ms가 걸렸습니다. URL B인 공식 예제 도메인은 평균 51.0 ms였습니다.
redirect.pizza
URL A
360.3 ms
303 / 43 / 735 ms (DC / 프랑크푸르트 / 도쿄)

Speed test page for test.redirect.pizza, re-run from all three regions on October 16, 2026: 351 ms (ranking round: 360.3 ms).
이 테스트 열기: test.redirect.pizza

Speed test page for redirect-pizza-example.com, re-run from all three regions on October 16, 2026: 50 ms (ranking round: 51 ms).
이 테스트 열기: redirect-pizza-example.com
이 둘 중 하나만 선택하면 서비스에 대해 잘못된 이야기를 하게 되므로, 두 항목 모두 순위에 유지합니다.
3. urllo (EasyRedir): 302 ms#
urllo의 이전 자체 도메인인 easyredir.com은 새 브랜드로 리디렉션됩니다. 이는 고객 링크가 아닌 사이트 이전 리디렉션입니다: 워싱턴 DC에서 179 ms, 프랑크푸르트에서 428 ms, 도쿄에서 298 ms가 걸렸습니다. 또한 최종 페이지에 도달하기 전에 리디렉션이 두 번 발생하며(easyredir.com, 그다음 www.easyredir.com, 그다음 www.urllo.com), 우리는 첫 번째 것만 측정했습니다.

Speed test page for easyredir.com, re-run from all three regions on October 16, 2026: 307 ms (ranking round: 301.7 ms).

The chain behind it: two redirects before the final page.
이 테스트 열기: easyredir.com
4. Rebrandly: 264 ms#
공개 Rebrandly 짧은 링크입니다. 워싱턴 DC에서는 빠르지만(29 ms), 프랑크푸르트(298 ms)와 도쿄(466 ms)에서는 훨씬 느립니다. 또한 테스트에서 가장 긴 연결 체인으로, 가격 페이지에 도달하기 전에 클릭 ID가 포함된 두 개의 무료 체험 URL을 거치는 세 번의 리디렉션이 있습니다.

Speed test page for rbnd.ly/booked, re-run from all three regions on October 16, 2026: 258 ms (ranking round: 264.3 ms).

Three redirects before the final page, each one a round trip.
이 테스트 열기: rbnd.ly/booked
5. Bitly: 117 ms#
Bitly의 공개 예시 링크입니다. 첫 번째 홉은 워싱턴 DC에서는 빠르고(26 ms), 프랑크푸르트(119 ms)와 도쿄(205 ms)에서는 더 느렸습니다. 이 체인에는 약한 부분이 있습니다. 링크가 방문자를 http:// YouTube 주소로 보낸 뒤, 다시 https://로 리디렉션되어야 합니다.

Speed test page for bit.ly/bitly, re-run from all three regions on October 16, 2026: 126 ms (ranking round: 116.7 ms).

A hop over plain HTTP: slower, and one step is unencrypted.
이 테스트 열기: bit.ly/bitly
6. Vercel: 77 ms#
Vercel에서 직접 설정한 리디렉션 규칙으로, 우리 사이트로 연결됩니다. 지역별로 매우 균일하지만(70, 73, 89 ms), 각 응답은 아래쪽의 엣지 기반 서비스보다 약간 더 오래 걸렸습니다.

Speed test page for vercel.urlredirectservice.com, re-run from all three regions on October 16, 2026: 42 ms (ranking round: 77.3 ms).
이 테스트 열기: vercel.urlredirectservice.com
7. Short.io: 46 ms#
콜롬비아 정부 기관이 사용하는 공개 Short.io 링크입니다. 워싱턴 DC와 프랑크푸르트에서는 매우 빠르고(각 15ms), 도쿄에서는 더 느립니다(109ms). 이 링크는 302를 사용하며, 이는 임시 이동을 의미합니다. 속도 테스트는 이동이 영구적일 경우 이를 표시합니다.

Speed test page for e436.short.gy/descarga-geoportal-ideam, re-run from all three regions on October 16, 2026: 46 ms (ranking round: 46.3 ms).

A 302 is temporary. For a permanent link, a 301 or 308 passes ranking signals on.
이 테스트 열기: e436.short.gy/descarga-geoportal-ideam
8. Dub: 38ms#
Dub의 GitHub 저장소로 연결되는 공식 짧은 링크입니다. 어디에서나 거의 동일합니다(39, 35, 40ms). 이는 엣지에서 제공되는 리디렉션의 모습입니다. Short.io와 마찬가지로 302로 응답합니다.

Speed test page for d.to/github, re-run from all three regions on October 16, 2026: 42 ms (ranking round: 38 ms).

One hop, but a temporary 302.
이 테스트 열기: d.to/github
9. TinyURL: 34ms#
YouTube 동영상으로 연결되는 공개 TinyURL 링크입니다. 워싱턴 DC와 프랑크푸르트에서는 29ms, 도쿄에서는 44ms입니다. 깔끔한 301 한 번만 사용하며, 추가 홉은 없습니다.

Speed test page for tinyurl.com/zs9flrt, re-run from all three regions on October 16, 2026: 34 ms (ranking round: 34 ms).
이 테스트 열기: tinyurl.com/zs9flrt
10. Cloudflare: 30ms#
Cloudflare에서 설정한 리디렉션 규칙으로, 자체 사이트를 가리킵니다: 30, 35, 25ms. 테스트에서 가장 고르게 나온 결과 중 하나이며, 세 지역 중 도쿄가 가장 빠릅니다.

Speed test page for cloudflare.urlredirectservice.com, re-run from all three regions on October 16, 2026: 34 ms (ranking round: 30 ms).
이 테스트 열기: cloudflare.urlredirectservice.com
11. RedirHub: 17 ms#
redirhub.com을 www.redirhub.com으로 리디렉션하는 우리 사이트 자체: 15, 17, 18 ms. 공정하게 말하자면, 이는 고객의 도메인이 아니라 우리 자신의 사이트이며, 테스트도 우리가 직접 실행했습니다. 하나의 데이터 포인트로 보고, 여러분의 링크로 직접 확인해 보세요.

Speed test page for redirhub.com, re-run from all three regions on October 16, 2026: 16 ms (ranking round: 16.7 ms).
이 테스트 열기: redirhub.com
우리가 배운 것#
- 방문자가 어디에 있는지가 중요합니다. 가장 느린 링크도 한 지역에서는 괜찮았지만 다른 지역에서는 느렸습니다. Cuttly는 129 ms에서 823 ms로, Rebrandly는 29 ms에서 466 ms로 변했습니다. 책상 앞이 아니라, 이용자가 있는 지역에서 테스트하세요.

Darker cells are slower. Gap compares each link's slowest region with its fastest.
- 링크 하나가 서비스 전체를 대표하지는 않습니다. redirect.pizza의 두 링크는 같은 라운드에서 360 ms와 51 ms를 기록했습니다. 여기의 모든 수치는 특정 시점의 하나의 링크를 설명합니다. 여러분의 링크로 직접 테스트해 보세요.
- 리디렉션 횟수는 누적됩니다. Rebrandly는 세 번의 리디렉션을 거쳤고, urllo와 Bitly는 두 번이었으며, Bitly는 일반 HTTP를 통해 이동했습니다. 각 링크를 최종 https:// 페이지로 바로 연결하세요.
- 올바른 코드를 사용하세요. Short.io와 Dub는 302로 응답했는데, 이는 임시 이동을 위한 것입니다. 절대 바뀌지 않는 링크라면 301이 더 명확한 신호입니다.
- 가장 빠른 서비스는 어디서나 비슷합니다. TinyURL, Cloudflare, Dub, RedirHub는 세 지역 모두에서 몇 밀리초 이내의 차이만 보였습니다.
사용자와 SEO에 왜 중요한지에 대해서는 리디렉션 속도가 중요한 이유를 참고하세요. 체인과 깨진 리디렉션에 대해서는 301 리디렉션이 작동하지 않나요? 6가지 일반적인 원인과 해결 방법을 참고하세요.
리디렉션이 느린 편인가요?
URL을 붙여넣으면 워싱턴 DC, 프랑크푸르트, 도쿄에서의 첫 바이트 수신 시간과, 지난 7일 동안 테스트된 리디렉션과 비교한 순위, 그리고 체인의 모든 홉을 확인할 수 있습니다. 무료이며 가입이 필요 없습니다.
내 리디렉션 테스트테스트 방법#

The number in every chart is time to first byte of the redirect response.
- 날짜: 2026년 10월 16일. 주요 샘플은 UTC 09:18~09:22 사이에 테스트되었고, RedirHub는 UTC 09:31에, redirect.pizza의 쌍을 이룬 URL들은 UTC 09:33에 함께 테스트되었습니다.
- 지역: 워싱턴 DC, 프랑크푸르트, 도쿄. 지역별로 5회씩, 매번 새 연결로 실행했으며 중앙값을 보고합니다.
- 지표: 첫 응답의 첫 바이트 수신 시간만 측정합니다. 대상 페이지는 시간을 재지 않으므로, 대상이 느려도 리디렉션에는 불리하게 작용하지 않습니다.
- 순위: 세 지역 중앙값의 단순 평균이며, 각 지역은 동일한 비중으로 계산됩니다.
- URL: 공개 출처에서 찾은 공개 단축 링크, 공식 예시, 우리가 Cloudflare와 Vercel에 직접 설정한 두 개의 리디렉션 규칙, 그리고 redirhub.com입니다. 대상, 요금제, 설정은 서비스마다 동일하지 않았습니다.
- 제외됨: 세 지역 중 두 곳에서 403을 반환한 redirection.io 고객 배포(차단된 응답은 더 빠른 리디렉션이 아닙니다), 그리고 NGINX, Apache, Caddy, WordPress 플러그인과 같은 자체 호스팅 설정은 실행 중인 서버에 따라 속도가 달라집니다. 아직 등록기관 도메인 포워딩은 테스트하지 않았습니다.
- 실행한 곳: RedirHub. 이는 특정 URL에 대한 짧은 스냅샷일 뿐이며, 어떤 브랜드의 장기적인 성능 순위를 의미하지도 않고, SEO나 전환에 대해서도 단독으로는 아무것도 말해주지 않습니다.
30초 만에 직접 리디렉션을 확인하세요#
1단계. 리디렉션 속도 테스트를 열고 리디렉션 또는 짧은 링크를 붙여넣으세요.

Paste a link, pick a region (or all three) and press Test speed.
2단계. 모든 세 지역을 선택해, 가장 가까운 한 곳만이 아니라 대륙 간 격차를 볼 수 있게 하세요.
3단계. 비교할 두 번째 URL을 추가하세요. 예를 들어 현재 제공업체와 테스트용 리디렉션을 비교할 수 있습니다. 두 URL은 같은 위치에서 동일한 실행 횟수를 번갈아 가며 받습니다.
4단계. 위 스크린샷처럼 결과 카드와 수정할 항목 목록을 읽어보세요. 예를 들어 불필요한 중간 경유, 301이어야 할 자리에 있는 302, 일반 HTTP를 거치는 경유, 또는 잘못된 대상 등이 있습니다.
5단계. 결과 페이지를 공유하거나 이미지를 다운로드하거나, curl 명령어를 복사해 자신의 기기에서 테스트를 다시 실행하세요.
터미널을 선호하시나요? 이는 DNS, 연결, TLS, 첫 바이트를 포함해 URL의 10회 실행 중앙값을 출력합니다. 결과는 실행 위치에 따라 달라지므로, 당신의 수치는 우리의 수치와 다를 것입니다.
bashfor u in 'https://your-redirect.example/'; do
for i in $(seq 10); do
curl -s -o /dev/null --max-redirs 0 --max-time 10 \
-w '%{time_namelookup} %{time_connect} %{time_appconnect} %{time_starttransfer} %{http_code}\n' "$u"
done | sort -n -k4 | awk -v u="$u" '{r[NR]=$0} END{split(r[int((NR+1)/2)],m," ");
printf "%-28s %s DNS %4.0f connect %4.0f TLS %4.0f first byte %4.0f ms\n", u, m[5], m[1]*1000, (m[2]-m[1])*1000, (m[3]>0?m[3]-m[2]:0)*1000, m[4]*1000}'
done느리거나 연쇄적인 리디렉션을 발견하셨나요? RedirHub로 이동한 후 다시 테스트하세요.
리디렉션 만들기출처
자주 묻는 질문
2026년 10월 16일 테스트에서 우리가 측정한 Cuttly 단축 링크가 가장 느렸으며, 워싱턴 DC, 프랑크푸르트, 도쿄 전반에서 평균 388 ms였고 도쿄에서는 823 ms였습니다. 이는 특정 시점의 하나의 URL에 대한 결과일 뿐, 모든 Cuttly 링크를 의미하지는 않습니다.
테스트에서 가장 빠른 네 개의 리디렉트는 세 지역 모두에서 15~44 ms 안에 응답했습니다. 가장 중요한 것은 지역 간 격차가 작고 홉이 하나뿐이라는 점입니다. 서버 근처에서는 빠르지만 서버에서 수백 밀리초 떨어진 곳에서는 느린 리디렉트는 일부 사용자에게 느리게 느껴질 수 있습니다.
리디렉트는 실제 페이지가 로드되기 전에 한 번의 요청을 추가하므로, 느린 리디렉트는 방문자에게 페이지를 더 느리게 만들고, 체인은 홉마다 요청을 하나씩 추가합니다. 이 테스트는 속도만 측정하며, 순위에 직접적인 영향을 보여주지는 않습니다.
서버와의 거리, 네트워크, DNS 캐싱이 모두 결과를 바꿉니다. 같은 장소에서 같은 시간에 테스트한 URL들을 비교하고, 절대값보다 그 차이를 보세요.
우리는 같은 라운드에서 그 서비스의 URL 두 개를 테스트했고 360.3 ms와 51.0 ms를 얻었습니다. 하나만 보여주면 서비스를 잘못 표현하게 되므로 둘 다 포함했고, 첫 번째 것만 순위를 가집니다.
우리가 직접 실행했으므로 그렇게 말합니다. RedirHub 샘플은 고객 설정이 아니라 우리 사이트 자체의 리디렉트이며, 방법, 시간, URL을 공개했기 때문에 누구나 무료 도구나 curl 명령으로 다시 테스트할 수 있습니다.

Leo Astarothman is the Brand & Content Lead at RedirHub, where he shapes the company's visual identity, educational content, product experiences, and marketing strategies. He also specializes in system design. Simplifying complex redirect infrastructure into practical resources, product experiences, and campaigns that help businesses understand and adopt modern redirect management.
관련 기사
모든 기사 보기


