iwinv 국제 트래픽 초과 및 해법 가이드 | 원인 분석·Nginx 차단·절감 실전 사례 2026








실무 점검 가이드 · 2026 최신

iwinv 국제 트래픽 초과
원인 분석 & 완전 절감 가이드

SSH 명령어 · Nginx 차단 설정 · 핫링크 억제 · 실전 사례 · 체크리스트 · WordPress 특화

iwinv VPS
국제 트래픽
크롤러 차단
핫링크 차단
Nginx 캐시
wp-json 제한
WordPress
SSH 로그 분석


iwinv 단독서버나 VPS를 운영하다 보면 어느 날 갑자기 국제 트래픽이 치솟는 경우가 있습니다.
국내 방문자는 늘지 않았는데 월간 송신량이 예상치의 3~10배를 초과하면,
단순 방문 증가가 아니라 아래 네 가지 원인 중 하나일 가능성이 높습니다.

⚠️
먼저 로그를 확인하세요.
국가 IP 차단은 가장 마지막 수단입니다. 원인도 모르고 차단하면 정상 검색봇까지 막혀 SEO 손해를 볼 수 있습니다.

대표 원인 4가지

01

무한 파라미터 크롤링

?query-44-page=700 처럼 파라미터 조합이 끝없이 달라지는 URL을 봇이 반복 호출합니다. 상태코드 200이면 실제 데이터가 매번 전송됩니다.

02

이미지 핫링크

외부 블로그·SNS가 이미지 원본 URL을 그대로 삽입하면, 트래픽 비용은 내 서버가 전부 부담합니다. /wp-content/uploads/가 특히 취약합니다.

03

검색봇·AI 크롤러 집중 수집

/post-sitemap.xml, /wp-json/wp/v2/posts 경로를 AI 크롤러가 단기간에 집중 수집하면 수 GB가 순식간에 소진됩니다.

04

정적 파일 캐시 미적용

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

💡
로그 컬럼 기본값: Nginx combined 포맷 기준으로 $10이 바이트 수입니다. Apache나 커스텀 포맷은 컬럼 번호가 다를 수 있으니 head -1 파일명으로 먼저 확인하세요.

실전 사례 분석

Case 01

무한 파라미터 크롤링으로 하루 18 GB 발생

실제 운영 사례에서 aaaa.com 도메인에서 하루 18 GB 이상이 발생했고,
로그를 분석해보니 전체의 99%가 아래 형태의 URL에서 기인했습니다.

/cafe/page/123/?query-44-page=700
/cafe/page/456/?query-44-page=1201
/cafe/page/12/?query-44-page=33

봇은 페이지 번호와 쿼리 문자열을 무작위로 바꾸며 실질적으로 무한한 조합의 URL을 요청합니다.
각 요청마다 상태코드 200이 반환되면 실제 HTML 데이터가 전송되어 트래픽이 누적됩니다.

✓ 차단 전: HTTP 200 → 데이터 전송 중
✗ 차단 후: 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"

Case 02

이미지 핫링크 + 정적 파일 캐시 미적용

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"

Case 03

WordPress 사이트맵·REST API 집중 수집

WordPress 사이트에서 특히 집중 수집 대상이 되는 경로들이 있습니다.
검색 노출이 중요하다면 무조건 차단보다 트래픽 비중을 계산 후 선택적으로 제한하는 것이 중요합니다.

/post-sitemap.xml
/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;
}

⚠️
주의: wp-json 차단은 Gutenberg 에디터, WooCommerce, 일부 플러그인의 프런트엔드 기능에 영향을 줄 수 있습니다. 차단 전 스테이징 환경에서 먼저 테스트하세요.

점검 체크리스트

순서대로 따라가면 대부분의 원인을 30분 안에 좁힐 수 있습니다.

  • 1도메인별 총 송신량 확인 — 어느 도메인이 주범인지 파악
  • 2URL별 송신량 상위 30개 확인 — 파라미터형 URL, 사이트맵, wp-json 경로 집중 점검
  • 3IP별·User-Agent별 상위 확인 — 특정 봇 이름이나 IP 집중 여부 확인
  • 4정적 파일(.jpg .woff2 .css) 응답 헤더 확인 — Cache-Control 있는지 curl -I 로 확인
  • 5Nginx 설정 작성 후 nginx -t 문법 검사 실행
  • 6systemctl reload nginx 무중단 적용
  • 7curl -Itail -f access.log로 차단 결과 실시간 검증
  • 8직전 24시간 대비 송신량 증감률 재확인 — 효과가 없으면 다른 원인 URL 반복 점검

자주 묻는 질문 (FAQ)

국제 트래픽이 많으면 무조건 해외 공격인가요?
꼭 그렇지는 않습니다. 검색봇(Googlebot, GPTBot, Bingbot), AI 학습 크롤러, 소셜 미리보기 봇(Facebook, Slack 등), 이미지 핫링크, RSS 리더도 국제 트래픽을 크게 만들 수 있습니다. 로그에서 User-Agent를 먼저 확인하세요.
가장 먼저 확인해야 할 로그는 무엇인가요?
도메인별 총 송신량 → URL별 상위 송신량 → IP별 상위 → User-Agent 상위 순서로 범위를 좁혀가는 것이 가장 빠릅니다. 네 가지를 동시에 비교하면 원인의 80%는 30분 안에 나타납니다.
query 형태 URL을 차단해도 되나요?
실제 사이트 기능에 필요한 파라미터가 아니라면 효과가 매우 큽니다. 다만 차단 전 반드시 브라우저에서 정상 페이지가 깨지지 않는지, curl -I로도 정상 URL이 영향받지 않는지 테스트하세요. Nginx의 444 응답은 서버가 아무 응답도 보내지 않고 연결을 끊기 때문에 봇 재시도도 막습니다.
정적 파일 캐시만 넣어도 효과가 있나요?
단독으로 폭발적 트래픽을 즉시 제거하는 수준은 아니지만, 반복 방문자가 많고 이미지·폰트 파일이 큰 사이트에서는 전체 송신량을 20~50% 줄이는 효과를 기대할 수 있습니다. 다른 차단 설정과 함께 적용하면 효과가 배가됩니다.
검색봇은 꼭 막아야 하나요?
아닙니다. Googlebot, Bingbot 등 주요 검색봇은 SEO와 직결되므로 차단이 역효과를 낳을 수 있습니다. GPTBot, Anthropic-AI 같은 AI 학습 크롤러는 트래픽 비중을 계산한 뒤, 감당 불가할 때만 robots.txt 또는 Nginx에서 선택적으로 제한하세요.
iwinv에서 트래픽 사용량을 실시간으로 확인하는 방법은?
iwinv 콘솔 → 서버 선택 → 모니터링 탭에서 네트워크 인/아웃바운드 그래프를 확인할 수 있습니다. 서버 내부에서는 vnstat -d (vnstat 설치 필요) 또는 iftop으로 실시간 네트워크 사용량을 볼 수 있습니다.

마무리

iwinv 국제 트래픽 초과는 막연히 “해외 접속이 많아서”가 아니라,
대개 특정 URL 패턴, 정적 파일 캐시 부재, 크롤러 수집 방식에서 원인이 드러납니다.

무조건 국가 차단부터 시도하기보다 로그 분석으로 원인을 좁히고,
파라미터 차단 → 정적 파일 캐시 → 핫링크 억제 → 결과 검증 순서로 접근하면
비용과 운영 안정성을 동시에 잡을 수 있습니다.

핵심 키워드 요약: iwinv 국제 트래픽 절감 · 무한 파라미터 크롤링 차단 · Nginx 핫링크 차단 · WordPress 정적 파일 캐시 · wp-json 제한 · SSH 로그 분석 · 크롤러 봇 차단

© 2026 AutoAiSy · iwinv 국제 트래픽 완전 가이드 · 실무 점검 자료