IP 로테이션 아키텍처: 실용 가이드

Your IP address is the first signal every platform checks and the easiest to get wrong. A misconfigured rotation setup doesn't just fail — it burns IPs, triggers cascading blocks, and contaminates your entire proxy pool.

This guide covers the architecture of production-grade IP rotation: how platforms use IP signals against you, which rotation strategies survive scrutiny, and how to build infrastructure that scales without collapsing under detection pressure.

Why IP Rotation Matters

Platforms don't just log your IP address. They build behavioral profiles around it.

Rate limiting is the most obvious use. Send 500 requests from one IP in an hour and you'll hit rate limits on any major platform. But modern rate limiting goes beyond simple request counting — it tracks request patterns, endpoint diversity, and session behavior per IP.

Geographic consistency matters more than most operators realize. If an account logs in from New York, then London, then Tokyo within 24 hours, that's a red flag even if each IP is clean. Platforms track geographic velocity — the physical impossibility of moving between locations faster than air travel allows.

ASN reputation is the silent killer. Internet Service Provider (ISP) assignments, datacenter ranges, and known proxy subnets are catalogued in databases like MaxMind, IP2Location, and IPinfo. When your traffic comes from AS14061 (DigitalOcean) or AS16276 (OVH), platforms know it's not a residential user. See our residential vs datacenter comparison for why this matters.

Subnet patterns reveal multi-account operations. If accounts A, B, and C all use IPs in the 45.67.89.0/24 range, even with different specific addresses, the correlation is detectable. Platforms track subnet proximity as a linkage signal.

IP history and reputation persist across users. An IP previously associated with spam, fraud, or bot activity carries that reputation to every new user who gets assigned it. Cheap proxy providers recycle IPs aggressively, which means you inherit the previous user's contamination.

Rotation Strategies

There's no universal rotation strategy. The right approach depends on your use case, your proxy pool quality, and the detection sophistication of your target platforms.

Sticky Sessions

Assign one IP to one account or session and maintain it for hours or days. The IP changes infrequently and only to a geographically consistent alternative.

Use when: Operating persistent accounts that require login sessions, building trust scores, or interacting with platforms that track IP stability as a trust signal.

Implementation:

const stickyPool = new Map();

function getProxy(accountId) {
  if (stickyPool.has(accountId)) {
    const entry = stickyPool.get(accountId);
    if (Date.now() - entry.assigned < 24 * 60 * 60 * 1000) {
      return entry.proxy;
    }
  }
  const proxy = assignGeoConsistentProxy(accountId);
  stickyPool.set(accountId, { proxy, assigned: Date.now() });
  return proxy;
}

Risk: If the sticky IP gets flagged, it directly affects the account. Mitigation: rotate to a new IP in the same geographic region when health checks detect degradation.

Round-Robin

Cycle through a pool of IPs sequentially, distributing requests evenly across the pool.

Use when: High-volume scraping where no single IP needs to persist, and the goal is maximizing throughput while distributing load.

Risk: Predictable patterns. If your pool has 100 IPs and you cycle through them in order, detection systems can identify the pattern by correlating request timing with IP sequences. Randomized round-robin with jitter mitigates this.

Geographic Targeting

Route each request through an IP that matches the target's expected geography. A French user account routes through a French IP; a German account through a German IP.

Use when: Operating accounts tied to specific regions, accessing geo-restricted content, or ensuring timezone-locale-IP consistency for anti-detect setups.

Implementation consideration: Your proxy provider needs actual geographic coverage, not just geo-labeled IPs. Verify by checking the IP's ASN and physical geolocation against independent databases — providers sometimes mislabel datacenter IPs as being in regions they only route through.

Session-Aware Rotation

The most sophisticated approach. Rotation decisions are driven by session context: rotate on new sessions, maintain IP through a session, and rotate to geographically consistent alternatives when session duration exceeds thresholds.

Use when: Operating at scale across platforms with sophisticated detection. This is what we run for production stealth infrastructure.

Building the Infrastructure

A production IP rotation system has five components: the proxy gateway, the pool manager, the health checker, the assignment engine, and the monitoring layer.

Proxy Gateway

The gateway sits between your application and the proxy pool. Every outbound request routes through it. We use a combination of HAProxy for TCP-level routing and a custom Node.js service for application-level proxy selection.

Architecture:

Application → Proxy Gateway → Pool Manager → Selected Proxy → Target
                                  ↑
                            Health Checker
                            (continuous)

The gateway handles authentication to upstream proxy providers, connection pooling, retry logic on failed connections, and request timeout management. It should support both HTTP CONNECT (for HTTPS tunneling) and SOCKS5 protocols.

Pool Manager

The pool manager maintains the state of every IP in your rotation pool: current assignment, health status, geographic location, ASN, last rotation time, and usage metrics.

Key data per IP:

Field	Purpose
IP address	Routing
Port	Connection
Protocol	HTTP/SOCKS5
Provider	Cost tracking
ASN	Detection avoidance
Country/city	Geographic targeting
Health score	0-100, updated by health checker
Last assigned	Sticky session management
Request count	Rate limiting
Error rate	Quality monitoring
Flagged	Boolean, exclude from rotation

Health Checker

Continuous background process that tests every IP in the pool against:

1. Connectivity — TCP handshake within 3 seconds
2. Latency — response time under threshold (varies by provider type)
3. IP consistency — outbound IP matches expected IP (catches provider-side rotation)
4. Blacklist status — check against known blacklists (Spamhaus, SORBS)
5. Platform-specific checks — does this IP currently pass target platform's initial checks

IPs that fail health checks get flagged and removed from the active pool. They're retested on a 30-minute cycle and re-added if healthy.

Failover Logic

When a request fails through the primary proxy:

1. Retry once through the same proxy (network glitch)
2. If failed, mark proxy as degraded and route through next available proxy in the same geographic region
3. If three proxies in the same region fail, escalate to a different provider
4. If all providers in a region fail, alert and queue the request

Never retry more than three times total. Excessive retries against a platform that's actively blocking you accelerates detection.

Cost Optimization

IP rotation infrastructure has two cost drivers: the proxy bandwidth and the IP pool size.

Residential proxies charge by bandwidth — typically $5-15/GB. At scale, this is the dominant cost. Optimization means minimizing bytes transferred: block images and media when you don't need them, compress responses, and cache static assets locally.

Datacenter proxies charge per IP per month — typically $0.50-2/IP. The cost scales with pool size, not traffic volume. Optimization means right-sizing your pool: how many concurrent IPs do you actually need?

The cost-per-action calculation: If you're scraping product data and each page costs 50KB of residential bandwidth at $10/GB, that's $0.0005 per page. At 100,000 pages/day, that's $50/day or $1,500/month in proxy costs alone. If datacenter proxies work (lower-scrutiny target), the same volume costs $200-400/month for a pool of 200-400 IPs.

Pool sizing formula: Pool size = (concurrent sessions × session duration) / rotation interval. If you need 50 concurrent sessions, each lasting 30 minutes, rotating every 30 minutes, you need 50 IPs minimum. Add 30% headroom for health-check failures and geographic distribution requirements.

FAQ

Are IPv6 proxies a viable alternative? For platforms that support IPv6, yes — and they're dramatically cheaper because the address space is enormous. The catch: many platforms still don't properly support IPv6, or they treat IPv6 traffic with higher suspicion because the majority of real users still connect via IPv4. Test before committing.

Can my ISP detect proxy traffic? Your ISP can see that you're connecting to a proxy server, but cannot see what you're doing through the proxy (assuming HTTPS). If your ISP blocks proxy connections, route through a VPN first, then to the proxy. The ISP sees VPN traffic; the target sees the proxy IP.

How do mobile proxies fit in? Mobile IPs (4G/5G) have the highest trust scores because carriers use CGNAT, meaning thousands of legitimate users share the same IP. Platforms can't block mobile IPs aggressively without blocking real users. The downside: mobile proxies are expensive ($20-50/GB), slow, and limited in supply. Use them for high-value operations on high-scrutiny platforms.

What latency is acceptable? For scraping: 500ms-2s per request is fine. For interactive browser sessions: under 300ms or the user experience (and behavioral fingerprint) degrades noticeably. Geographic proximity between your infrastructure, the proxy, and the target reduces latency — route through proxies in the same region as the target platform's servers.