> ## Content Index
> Fetch the complete content index at: https://blog.frostk.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# DNS가 고른 살아 있는 서버, 웹페이지도 열릴까요?
- URL: https://blog.frostk.com/bunny-dns-health-boundary/
- Published: 2026-11-08T01:00:00.000Z
- Updated: 2026-11-08T01:00:00.000Z
- Description: Route 53에서 Bunny DNS로 옮긴 운영기는 가까운 서버를 고르는 재미를 보여줘요. 그런데 스크립트가 말하는 online은 웹페이지의 정상 응답과 달라요. 공식 문서 두 곳을 대조해, 서버 전체 장애와 웹앱만 멈춘 장애가 어떻게 갈리는지 정리했어요.
- Author: Cat
- Tags: IT, 인프라, 개발사례

서버는 켜져 있는데 웹페이지는 안 열려요. 이런 상태도 Bunny Scriptable DNS의 서버 선택에서는 `online`일 수 있어요. 공식 문서상 이때 확인하는 것은 웹 응답이 아니라 **ping에 답하는지**거든요.

Vincent Bernat의 글은 개인 블로그를 Route 53과 CloudFront에서 Bunny DNS와 CDN으로 옮긴 운영기예요. 특히 방문자에게 가까운 서버를 골라 주는 DNS 코드가 흥미로워요. 다만 이 구성을 따라 옮기려면, IP를 고르는 방식과 서버가 정상인지 판단하는 방식을 따로 봐야 해요. 이전기와 두 서비스의 공식 문서를 대조했어요.

## IP가 둘이어도 먼저 쓰는 곳은 달라져요

DNS는 도메인 이름을 접속할 IP 주소로 바꿔 줘요. Bernat는 세계 여러 지역의 서버 일곱 대에서 같은 블로그를 운영하며, 처음에는 가까운 서버 두 대의 IP를 답하도록 했어요. 하나에 연결하지 못하면 다른 주소를 시도할 여지를 두려는 구성이죠.

그런데 DNS 답에 가까운 IP를 먼저 적었다고 그 순서로 접속하는 건 아니었어요. 원문은 많은 리졸버가 주소 순서를 섞어서, 두 번째로 가까운 서버를 먼저 쓸 수 있다고 설명해요. 리졸버는 이용자를 대신해 DNS 답을 찾아 주는 서버예요.

최종 구성은 두 서버의 거리가 비슷하면 둘 다, 차이가 크면 가장 가까운 하나만 반환해요. 하나만 줄 때는 DNS 답을 보관하는 시간인 TTL을 2분으로 줄여요. 여러 주소를 미리 주는 여유와 가까운 곳에 우선 연결하는 목적 사이의 절충이에요.

![위치별 후보 선택, online 선별, IP 응답, 브라우저의 웹 접속을 구분한 흐름](https://blog.frostk.com/content/images/2026/11/hf-38763017.png)

Bernat의 구성을 바탕으로 DNS 선택과 실제 접속 단계를 나눴어요.

## online은 웹페이지가 열렸다는 뜻이 아니에요

원문 코드의 `RoutingEngine.getClosestServer(..., true)`에서 `true`는 오프라인 서버를 빼라는 뜻이에요. Bunny의 공식 helper 문서를 따라가면, 이 상태는 네트워크 응답이 오는지 묻는 ICMP ping 검사에서 와요. 웹사이트의 주소나 특정 포트는 검사하지 않아요.

반면 Route 53의 HTTP·HTTPS 상태 검사는 실제로 웹 요청을 보내고, 정해진 시간 안에 2xx·3xx 상태 코드가 돌아오는지 확인해요. 성공이나 다른 주소로의 이동 등을 나타내는 응답이에요. 응답 본문에서 지정한 문자열을 찾는 방식도 선택할 수 있어요. Route 53에도 TCP 검사 등 다른 방식이 있으므로, 자신이 쓰던 검사가 무엇이었는지부터 봐야 해요.

두 문서의 기준을 같은 상황에 적용하면 차이가 보여요. 아래는 실제 장애 실험 결과가 아니라 **검사 기준에 따른 비교**예요.

| 가정한 상태                     | Bunny helper의 ICMP 검사 | Route 53의 HTTP·HTTPS 검사      |
| -------------------------- | --------------------- | ---------------------------- |
| 서버는 ping에 답하지만 웹 프로세스가 멈춤  | online으로 남을 수 있어요     | 정상 웹 응답을 못 받으면 실패해요          |
| 웹은 정상인데 방화벽이 ping을 막음      | offline으로 판정해요        | 정상 상태 코드를 제시간에 받으면 통과해요      |
| 웹이 오류 상태 코드만 반환하고 ping은 정상 | 웹 오류를 구분하지 못해요        | 성공 조건인 2xx·3xx에 해당하지 않아 실패해요 |

## 옮기기 전에 장애를 두 종류로 나눠 보세요

먼저 서버 전체가 꺼지는 경우와 웹앱만 멈추는 경우를 나눠 보세요. 기존에 HTTP 검사로 장애 서버를 제외하고 있었다면, ping 기반 선별만으로 바꿨을 때 뒤쪽 장애가 후보에서 빠지지 않을 수 있어요. 웹앱의 정상 응답까지 기준으로 삼는 별도 점검과, 그 결과를 DNS 후보에서 제외하는 절차가 필요하겠죠.

TTL을 짧게 만드는 것만으로 이 차이는 메워지지 않아요. TTL은 이미 받은 주소를 얼마나 보관할지 정하는 값이에요. 웹앱이 고장 났는지 새로 확인하는 주기가 아니에요. helper가 여전히 online으로 보는 주소라면 다음 DNS 응답에도 다시 들어갈 수 있어요.

HTTP 검사에도 경계는 있어요. AWS 문서에 따르면 Route 53의 HTTPS 검사는 인증서의 유효성을 검증하지 않아요. 만료된 인증서 때문에 방문자의 브라우저가 멈추더라도 검사 자체는 통과할 수 있다는 뜻이에요. 이전할 때 맞출 것은 '정상'이라는 이름보다, 내가 잡으려는 장애를 실제로 확인하는 조건이에요.

## 확인한 범위

- 기준일: 2026-11-08
- 직접 한 것: 이전기의 online 선별을 Bunny 공식 helper 문서의 ICMP 기준과 대조하고, Route 53의 HTTP·HTTPS 검사 조건에 같은 장애 상황을 적용해 비교했어요.
- 읽은 것: Bernat의 GeoDNS 이전기, Bunny helper 문서, AWS의 상태 검사 판정 문서, TNN의 한국어 요약.
- 확인하지 못한 것: 실제 장애를 일으켜 전환 시간이나 브라우저별 재시도를 측정하지 않았어요. Bernat의 사이트에서 웹앱 장애가 발생했다는 이야기도 아니에요.

## 출처

[Scriptable GeoDNS: leaving AWS for BunnyI moved this blog from CloudFront and Route 53 to a European provider. JavaScript code running on each DNS query returns the closest servers,...![](https://media-bernat-ch.b-cdn.net/images/favicon.a011c4d258765d.png)Vincent Bernatvincent.bernat.ch![](https://media-bernat-ch.b-cdn.net/images/covers/en/blog/2026-bunny-geodns.7be2142de9305f.jpg)](https://vincent.bernat.ch/en/blog/2026-bunny-geodns?ref=blog.frostk.com)

[Helper Objects - bunny.net DocumentationThe Scriptable DNS comes with a list of helper objects to help with various tasks needed for dynamic routing. This page contains the documentation for the helper objects.![](https://static.ghost.org/v5.0.0/images/link-icon.svg)bunny.net Documentation![](https://blog.frostk.com/content/images/thumbnail/v2-ea649bc8-4a7e-4008-9961-b5a0d1c7010b.png)](https://bunny.net/docs/dns/scriptable/helper-objects?ref=blog.frostk.com)

[How Amazon Route 53 determines whether a health check is healthy - Amazon Route 53Describes how a Route 53 health check determines whether a health check is healthy.![](https://blog.frostk.com/content/images/icon/favicon-0228e669-d35f-4ea5-8260-48579b96cf55.ico)Amazon](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-determining-health-of-endpoints.html?ref=blog.frostk.com)