iwinv 국제 트래픽 초과
원인 분석 & 완전 절감 가이드
SSH 명령어 · Nginx 차단 설정 · 핫링크 억제 · 실전 사례 · 체크리스트 · WordPress 특화
iwinv 단독서버나 VPS를 운영하다 보면 어느 날 갑자기 국제 트래픽이 치솟는 경우가 있습니다.
국내 방문자는 늘지 않았는데 월간 송신량이 예상치의 3~10배를 초과하면,
단순 방문 증가가 아니라 아래 네 가지 원인 중 하나일 가능성이 높습니다.
국가 IP 차단은 가장 마지막 수단입니다. 원인도 모르고 차단하면 정상 검색봇까지 막혀 SEO 손해를 볼 수 있습니다.
대표 원인 4가지
무한 파라미터 크롤링
?query-44-page=700 처럼 파라미터 조합이 끝없이 달라지는 URL을 봇이 반복 호출합니다. 상태코드 200이면 실제 데이터가 매번 전송됩니다.
이미지 핫링크
외부 블로그·SNS가 이미지 원본 URL을 그대로 삽입하면, 트래픽 비용은 내 서버가 전부 부담합니다. /wp-content/uploads/가 특히 취약합니다.
검색봇·AI 크롤러 집중 수집
/post-sitemap.xml, /wp-json/wp/v2/posts 경로를 AI 크롤러가 단기간에 집중 수집하면 수 GB가 순식간에 소진됩니다.
정적 파일 캐시 미적용
CSS, JS, 폰트, 이미지에 Cache-Control 헤더가 없으면 같은 파일을 방문마다 재전송합니다. 반복 방문이 많을수록 누적 트래픽이 폭증합니다.
실전 로그 분석 명령어
분석은 도메인 → URL → IP → User-Agent 순서로 범위를 좁혀가는 것이 가장 효율적입니다.
① 도메인별 총 송신량 확인
어느 도메인이 트래픽의 주범인지 전체 그림을 먼저 파악합니다.
bash — 도메인별 송신량 정렬
# 오늘 날짜(16/Mar/2026) 기준 도메인별 바이트 합계
for f in /data/hosting/logs/*.access.log; do
bytes=$(awk '/\[16\/Mar\/2026:/{s+=$10} END{print s+0}' "$f")
echo "$bytes $f"
done | sort -nr | head -15
② URL별 송신량 상위 30개
특정 URL 패턴이 집중적으로 나타나는지 확인합니다. 사이트맵, 파라미터형 URL, REST API 경로에 주목하세요.
bash — URL별 송신 바이트 집계
awk '/\[16\/Mar\/2026:/{sum[$7]+=$10} END{for (u in sum) print sum[u], u}' \
/data/hosting/logs/aaaa.com.access.log | sort -nr | head -30
③ IP별·User-Agent별 상위 집계
특정 IP나 크롤러 이름이 반복되면 차단 대상으로 검토합니다.
bash — IP·UA 상위
# IP별 송신량 awk '/\[16\/Mar\/2026:/{sum[$1]+=$10} END{for (ip in sum) print sum[ip], ip}' \ /data/hosting/logs/aaaa.com.access.log | sort -nr | head -30 # User-Agent 상위 awk -F'"' '/\[16\/Mar\/2026:/{print $6}' \ /data/hosting/logs/aaaa.com.access.log \ | sort | uniq -c | sort -nr | head -30
$10이 바이트 수입니다. Apache나 커스텀 포맷은 컬럼 번호가 다를 수 있으니 head -1 파일명으로 먼저 확인하세요.
실전 사례 분석
무한 파라미터 크롤링으로 하루 18 GB 발생
실제 운영 사례에서 aaaa.com 도메인에서 하루 18 GB 이상이 발생했고,
로그를 분석해보니 전체의 99%가 아래 형태의 URL에서 기인했습니다.
/cafe/page/456/?query-44-page=1201
/cafe/page/12/?query-44-page=33
봇은 페이지 번호와 쿼리 문자열을 무작위로 바꾸며 실질적으로 무한한 조합의 URL을 요청합니다.
각 요청마다 상태코드 200이 반환되면 실제 HTML 데이터가 전송되어 트래픽이 누적됩니다.
✗ 차단 후: HTTP 444 → 연결 즉시 끊김
Nginx 차단 설정
nginx.conf — 파라미터 패턴 차단
# server 블록 또는 location / 블록 안에 추가 if ($args ~* "(^|&)query-44-page=") { return 444; # 444 = 응답 없이 연결 종료 (Nginx 전용) } # 더 넓게: 숫자형 page 파라미터 전체를 차단할 경우 # if ($args ~* "page=[0-9]{3,}") { return 444; }
bash — 적용 및 검증
nginx -t && systemctl reload nginx # 차단 확인: curl이 응답을 받지 못하면 성공 curl -I "https://aaaa.com/?query-44-page=123" # 실시간 로그 확인 tail -f /data/hosting/logs/aaaa.com.access.log | grep "query-44-page"
이미지 핫링크 + 정적 파일 캐시 미적용
URL별 송신량 상위에 .jpg, .woff2, .css 파일이 반복적으로 나타난다면
두 가지 원인이 겹쳐 있을 가능성이 높습니다.
첫째는 외부 사이트가 이미지 원본 경로를 그대로 링크한 핫링크, 둘째는 브라우저 캐시 헤더 미적용으로 인한 반복 전송입니다.
nginx.conf — 핫링크 차단 + 정적 파일 캐시
# 이미지: 핫링크 차단 + 7일 캐시 location ~ \.(?:jpe?g|png|gif|webp|avif)$ { expires 7d; add_header Cache-Control "public, immutable"; valid_referers none blocked aaaa.com www.aaaa.com; if ($invalid_referer) { return 403; } } # CSS·JS·폰트·아이콘: 캐시 적용 + 불필요한 로그 제거 location ~ \.(?:svg|css|js|woff|woff2|ttf|eot|ico)$ { expires 7d; add_header Cache-Control "public, immutable"; access_log off; log_not_found off; try_files $uri =404; }
bash — 캐시 헤더 적용 확인
# Cache-Control, Expires 헤더 확인 curl -I "https://aaaa.com/wp-content/uploads/2026/03/sample.png" # 외부 Referer로 핫링크 차단 확인 (403이어야 성공) curl -I -e "https://external-site.com/" \ "https://aaaa.com/wp-content/uploads/2026/03/sample.png"
WordPress 사이트맵·REST API 집중 수집
WordPress 사이트에서 특히 집중 수집 대상이 되는 경로들이 있습니다.
검색 노출이 중요하다면 무조건 차단보다 트래픽 비중을 계산 후 선택적으로 제한하는 것이 중요합니다.
/post-sitemap2.xml
/wp-json/wp/v2/posts
/feed/
/search/…/feed/
| 경로 | 주요 수집 주체 | 차단 여부 | 권장 조치 |
|---|---|---|---|
/post-sitemap.xml |
Google, AI 크롤러 | ⚠️ 신중 | robots.txt Crawl-delay 설정 |
/wp-json/wp/v2/posts |
스크래퍼, AI 크롤러 | ✅ 권장 | 비로그인 요청 차단 또는 rate limit |
/feed/ |
RSS 리더, 봇 | ⚠️ 신중 | 트래픽 비중 확인 후 결정 |
/search/.../feed/ |
봇 크롤러 | ✅ 권장 | 검색 feed URL 전체 차단 |
nginx.conf — wp-json 비로그인 차단 예시
location ~ ^/wp-json/ { # 인증 쿠키 없는 요청 차단 (WordPress 기본 쿠키명 기준) if ($http_cookie !~* "wordpress_logged_in") { return 403; } try_files $uri $uri/ /index.php?$args; } # 검색 피드 URL 차단 location ~ ^/search/.+/feed/ { return 444; }
점검 체크리스트
순서대로 따라가면 대부분의 원인을 30분 안에 좁힐 수 있습니다.
- 도메인별 총 송신량 확인 — 어느 도메인이 주범인지 파악
- URL별 송신량 상위 30개 확인 — 파라미터형 URL, 사이트맵, wp-json 경로 집중 점검
- IP별·User-Agent별 상위 확인 — 특정 봇 이름이나 IP 집중 여부 확인
- 정적 파일(
.jpg .woff2 .css) 응답 헤더 확인 —Cache-Control있는지curl -I로 확인 - Nginx 설정 작성 후
nginx -t문법 검사 실행 systemctl reload nginx무중단 적용curl -I와tail -f access.log로 차단 결과 실시간 검증- 직전 24시간 대비 송신량 증감률 재확인 — 효과가 없으면 다른 원인 URL 반복 점검
자주 묻는 질문 (FAQ)
국제 트래픽이 많으면 무조건 해외 공격인가요?
가장 먼저 확인해야 할 로그는 무엇인가요?
query 형태 URL을 차단해도 되나요?
curl -I로도 정상 URL이 영향받지 않는지 테스트하세요. Nginx의 444 응답은 서버가 아무 응답도 보내지 않고 연결을 끊기 때문에 봇 재시도도 막습니다.
정적 파일 캐시만 넣어도 효과가 있나요?
검색봇은 꼭 막아야 하나요?
robots.txt 또는 Nginx에서 선택적으로 제한하세요.
iwinv에서 트래픽 사용량을 실시간으로 확인하는 방법은?
vnstat -d (vnstat 설치 필요) 또는 iftop으로 실시간 네트워크 사용량을 볼 수 있습니다.
마무리
iwinv 국제 트래픽 초과는 막연히 “해외 접속이 많아서”가 아니라,
대개 특정 URL 패턴, 정적 파일 캐시 부재, 크롤러 수집 방식에서 원인이 드러납니다.
무조건 국가 차단부터 시도하기보다 로그 분석으로 원인을 좁히고,
파라미터 차단 → 정적 파일 캐시 → 핫링크 억제 → 결과 검증 순서로 접근하면
비용과 운영 안정성을 동시에 잡을 수 있습니다.