MCP-server và API proxy: tự động thay đổi IP cho đại lý AI

Trình phân tích cổ điển nhận danh sách proxy, đơn giản lặp lại nó theo vòng tròn và bị ngã ngay khi hệ thống chống bot phát hiện mẫu. AI-agent hoạt động khác: nó thấy bị chặn, tự quyết định thay đổi IP, thay đổi tiêu đề, làm chậm các yêu cầu - và tất cả điều này mà không cần sự tham gia của bạn. Chúng ta sẽ tìm hiểu cách kết nối agent, MCP-server và API proxy thành một bộ làm việc, giữ cho các phiên hoạt động ngay cả trên các trang web bảo mật.

MCP-server là gì và tại sao nó cần thiết cho trình phân tích

MCP (Model Context Protocol) - là một giao thức mở cho phép AI-agent (ví dụ như dựa trên Claude hoặc bất kỳ LLM nào hỗ trợ tool-calling) truy cập các công cụ bên ngoài thông qua một giao diện duy nhất. Trước đây, để cung cấp cho mô hình quyền truy cập vào API bên ngoài, cần phải viết một lớp bao bọc tùy chỉnh cho mỗi nhiệm vụ. MCP-server giải quyết vấn đề này theo cách khác: nó mô tả một tập hợp các "công cụ" (tools) - các chức năng mà agent có thể gọi khi nhận ra rằng chúng cần thiết.

Trong bối cảnh phân tích, điều này diễn ra như sau: agent nhận nhiệm vụ "thu thập giá cho 500 sản phẩm từ thị trường". Nó bắt đầu thực hiện các yêu cầu thông qua công cụ fetch_page, thấy phản hồi 403 hoặc captcha, tự gọi công cụ rotate_proxy, nhận IP mới và lặp lại yêu cầu - mà không cần sự can thiệp của người điều hành. MCP-server ở đây đóng vai trò là "cây cầu" giữa logic của agent và hạ tầng proxy thực tế.

Sự khác biệt chính so với một kịch bản thông thường với việc thay đổi theo thời gian: agent quyết định thay đổi IP dựa trên ngữ cảnh - mã phản hồi, nội dung trang, tốc độ chặn của miền cụ thể. Nó có thể giữ một IP cho phiên xác thực và chỉ thay đổi IP cho các yêu cầu "lạnh" thu thập dữ liệu, kết hợp các chiến lược ngay lập tức.

Tại sao AI-agent cần thay đổi IP, chứ không chỉ là danh sách proxy

Nếu chỉ đơn giản cung cấp cho agent một danh sách tĩnh gồm 50 proxy và yêu cầu nó lặp lại theo vòng tròn, bạn sẽ nhận được chính xác điều tương tự như với một kịch bản thông thường: mẫu yêu cầu nhanh chóng bị hệ thống chống bot tính toán dựa trên khoảng thời gian, tiêu đề và trình tự IP. Wildberries, Ozon, Avito và các nền tảng lớn khác sử dụng phân tích hành vi - họ không chỉ nhìn vào IP mà còn xem cách thay đổi User-Agent, cookies, dấu vân tay TLS và tốc độ yêu cầu kết hợp với địa chỉ cụ thể.

AI-agent giải quyết nhiệm vụ này theo cách hoàn toàn khác. Nó có thể:

Xác định qua mã phản hồi (403, 429, chuyển hướng đến captcha) rằng IP hiện tại đã "bị cháy", và yêu cầu một cái mới cho miền này;
Giữ phiên "dính" (sticky session) trên một IP cho các kịch bản nhiều bước - ví dụ, xác thực + phân tích tài khoản cá nhân;
Điều chỉnh tần suất yêu cầu theo phản ứng của trang web, thay vì làm việc theo một bộ hẹn giờ cứng;
Kết hợp việc thay đổi IP với việc thay đổi tiêu đề và mô phỏng trình duyệt thông qua các công cụ chống phát hiện như Dolphin Anty hoặc AdsPower, nếu việc phân tích diễn ra qua trình duyệt headless.

Chính vì vậy, bộ kết nối "agent + MCP-server + API proxy" giảm đáng kể tỷ lệ bị chặn so với việc thay đổi tĩnh: quyết định thay đổi IP được đưa ra dựa trên thực tế bị chặn, chứ không phải theo lịch trình.

Kiến trúc kết nối: agent → MCP → API proxy → trình phân tích

Sơ đồ hoạt động bao gồm bốn lớp, và điều quan trọng là hiểu rõ trách nhiệm của từng lớp:

AI-agent (LLM với tool-calling) - đưa ra quyết định: trang nào sẽ phân tích tiếp theo, có cần thay đổi IP không, có nên làm chậm lại không;
MCP-server - cung cấp cho agent một tập hợp các công cụ: get_page, rotate_ip, check_proxy_status;
API của nhà cung cấp proxy - cung cấp IP mới theo yêu cầu, hiển thị vị trí địa lý, loại kết nối (cư trú, di động, trung tâm dữ liệu);
Trình phân tích/HTTP-client - thực hiện yêu cầu thực tế đến trang web mục tiêu với các tham số proxy đã nhận.

Một điểm quan trọng: MCP-server không tự phân tích trang web - nó chỉ cung cấp cho agent các khả năng. Logic "phải làm gì khi gặp 403" vẫn thuộc về mô hình, trong khi MCP-server chỉ thực hiện các lệnh và trả về kết quả. Sự phân chia này cho phép thay đổi nhà cung cấp proxy hoặc trình phân tích mà không cần viết lại logic của agent - chỉ cần cập nhật cách thực hiện công cụ trên MCP-server.

Lời khuyên thực tiễn

Đừng cho agent quyền truy cập trực tiếp vào API "thô" của nhà cung cấp proxy - hãy bọc nó trong một công cụ MCP riêng với tập hợp tham số hạn chế (quốc gia, loại IP, session_id). Điều này giảm thiểu rủi ro mà mô hình vô tình tạo ra yêu cầu không chính xác và "đốt cháy" giới hạn.

Loại proxy nào nên chọn cho phân tích của agent

Loại proxy ảnh hưởng trực tiếp đến tần suất agent phải gọi rotate_ip và số lượng yêu cầu được thực hiện mà không bị chặn. Dưới đây là so sánh theo các nhiệm vụ, phù hợp với phân tích của agent.

Loại proxy	Khi nào sử dụng cho agent	Ưu điểm	Nhược điểm
Proxy cư trú	Phân tích các thị trường, trang web với bảo vệ chống bot (Wildberries, Ozon)	IP thực của người dùng, tỷ lệ chặn thấp	Đắt hơn so với trung tâm dữ liệu, tốc độ phụ thuộc vào nút
Proxy di động	Làm việc với mạng xã hội và các bảng điều khiển quảng cáo trong quy trình của agent	Tối đa độ tin cậy từ các trang web, IP như của nhà mạng	Chi phí cao hơn, tốc độ thay đổi hạn chế
Proxy trung tâm dữ liệu	Thu thập dữ liệu hàng loạt từ các trang web không có bảo vệ chống bot nghiêm ngặt	Tốc độ cao, giá thấp cho IP	Dễ bị phát hiện, thường yêu cầu thay đổi qua agent

Trong thực tế, agent có thể kết hợp các loại: bắt đầu phiên qua proxy cư trú để "làm nóng", và cho việc vượt qua giới hạn tỷ lệ kỹ thuật, chuyển sang proxy trung tâm - nếu công cụ MCP cho phép chỉ định loại IP như một tham số yêu cầu.

Hướng dẫn từng bước để thiết lập MCP-server với việc thay đổi proxy

Chúng ta sẽ xem xét một bộ làm việc tối thiểu trên Python. MCP-server mô tả hai công cụ: lấy trang và thay đổi IP thông qua API của nhà cung cấp proxy.

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("proxy-parser-agent")

# Kho lưu trữ phiên proxy hiện tại
current_session = {"proxy_url": None, "country": "ru"}

def get_new_proxy(country: str = "ru") -> str:
    """Yêu cầu IP mới từ nhà cung cấp proxy thông qua API của họ"""
    response = httpx.get(
        "https://api.proxycove.com/v1/get-endpoint",
        params={"country": country, "type": "residential"},
        headers={"Authorization": "Bearer YOUR_API_KEY"},
    )
    data = response.json()
    return f"http://{data['username']}:{data['password']}@{data['host']}:{data['port']}"

@mcp.tool()
def rotate_ip(country: str = "ru") -> str:
    """Công cụ cho agent: thay đổi địa chỉ IP sang mới từ quốc gia đã chỉ định"""
    current_session["proxy_url"] = get_new_proxy(country)
    current_session["country"] = country
    return f"IP đã được cập nhật, khu vực: {country}"

@mcp.tool()
def fetch_page(url: str) -> dict:
    """Công cụ cho agent: lấy trang thông qua proxy hiện tại"""
    if not current_session["proxy_url"]:
        current_session["proxy_url"] = get_new_proxy(current_session["country"])

    proxies = {"http://": current_session["proxy_url"], "https://": current_session["proxy_url"]}
    try:
        r = httpx.get(url, proxies=proxies, timeout=15)
        return {"status_code": r.status_code, "content": r.text[:3000]}
    except httpx.RequestError as e:
        return {"status_code": 0, "error": str(e)}

if __name__ == "__main__":
    mcp.run()

Logic rất đơn giản: agent gọi fetch_page, thấy trong phản hồi status_code: 403 và dựa trên điều này tự quyết định gọi rotate_ip. Không có quy tắc cứng "thay đổi IP sau 10 yêu cầu" - mô hình dựa vào phản hồi thực tế từ máy chủ.

Đối với sản xuất, mã này cần thêm: ghi lại mỗi lần thay đổi với dấu thời gian, giới hạn số lần thay đổi trong một phút (để mô hình không "lặp lại" việc thay đổi IP thay vì giải quyết vấn đề thực tế) và thời gian chờ ở cấp độ phiên, để IP "dính" không giữ lâu hơn cần thiết.

Tích hợp với Claude, LangChain và AutoGPT

MCP ban đầu được quảng bá như một giao thức cho Claude Desktop và Claude API, nhưng nhờ vào đặc tả mở, nó cũng được hỗ trợ bởi các framework bên ngoài. Nếu bạn xây dựng agent trên LangChain, MCP-server được kết nối thông qua bộ chuyển đổi langchain-mcp-adapters, biến các công cụ MCP thành các Công cụ LangChain thông thường - agent nhìn thấy chúng giống như bất kỳ chức năng nào khác.

Đối với các agent tương tự AutoGPT, nơi không có hỗ trợ gốc cho MCP, bạn có thể thiết lập một cầu HTTP cục bộ: MCP-server hoạt động như một dịch vụ REST thông thường, và agent gọi các điểm cuối thông qua cơ chế gọi hàm tiêu chuẩn của nó. Điều này ít thanh lịch hơn một chút, nhưng là một lựa chọn khả thi cho các nhóm đã gắn bó với một ngăn xếp cụ thể.

Riêng biệt, cần nói về kết nối với các trình duyệt chống phát hiện. Nếu việc phân tích không diễn ra qua các yêu cầu HTTP trực tiếp mà thông qua Chrome/Playwright headless (cần cho các trang web có bảo vệ JS nặng), MCP-server có thể quản lý không chỉ proxy mà còn cả hồ sơ trình duyệt - truyền cho agent công cụ để khởi động hồ sơ trong Dolphin Anty hoặc Octo Browser với proxy-endpoint đã được liên kết. Trong trường hợp này, agent chỉ cần chỉ định hồ sơ nào và quốc gia nào để sử dụng, trong khi toàn bộ phần kỹ thuật được ẩn sau công cụ MCP.

Các trường hợp thực tiễn: Wildberries, Ozon, phân tích SMM

Theo dõi giá trên Wildberries. Agent nhận danh sách 2000 SKU, duyệt qua các thẻ sản phẩm, khi nhận được captcha hoặc phản hồi trống, tự thay đổi IP thông qua proxy cư trú và lặp lại yêu cầu với độ trễ. Khác với kịch bản tĩnh với việc thay đổi cố định, bộ kết nối như vậy giữ tốc độ thu thập ổn định ngay cả khi bảo vệ được tăng cường từ phía nền tảng - agent chỉ "phản ứng chậm hơn" với các mẫu chặn, giảm tần suất yêu cầu thay vì chỉ đơn giản lặp lại IP cho đến khi tất cả đều bị chặn.

Thu thập dữ liệu từ Ozon Seller API và giao diện web. Ở đây agent kết hợp hai chế độ: các yêu cầu đã xác thực đến tài khoản cá nhân diễn ra qua IP "dính" trong suốt cả ngày làm việc (để không kích hoạt xác thực hai yếu tố lại), trong khi việc phân tích công khai các thẻ sản phẩm - thông qua việc thay đổi cho mỗi yêu cầu.

Phân tích SMM về đối thủ trong Instagram và TikTok. Agent thu thập thống kê công khai (thích, bình luận, phạm vi tiếp cận) từ danh sách các tài khoản đối thủ, phân phối các yêu cầu qua proxy di động, để mô phỏng lưu lượng truy cập thông thường của người dùng ứng dụng, thay vì bot với IP từ trung tâm dữ liệu.

Trong cả ba trường hợp, tiết kiệm thời gian cho nhóm - không phải ở chính việc phân tích (có thể tự động hóa trước đây), mà là không cần phải viết và duy trì logic phức tạp cho việc thử lại, backoff và quy tắc thay đổi. Agent tự thích ứng với sự thay đổi bảo vệ của trang web mà không cần viết lại mã.

Những lỗi thường gặp khi kết nối AI-agent và proxy

Thay đổi quá thường xuyên. Nếu cho phép agent thay đổi IP với mỗi lần ho, trang web có thể bắt đầu chặn toàn bộ dải địa chỉ của subnet do tốc độ thay đổi địa chỉ bất thường từ một User-Agent.
Không có sự liên kết cookies với IP. Nếu agent thay đổi IP nhưng tiếp tục sử dụng cookies cũ của phiên, hệ thống chống bot ngay lập tức phát hiện sự không phù hợp giữa vị trí địa lý và phiên.
Không có giới hạn cho số lần thay đổi. Nếu không có giới hạn, mô hình trong vòng lặp lỗi có thể "đốt cháy" toàn bộ giới hạn lưu lượng cho những nỗ lực vô ích trong trường hợp có vấn đề hệ thống (ví dụ, trang web hoàn toàn không hoạt động, chứ không phải chỉ chặn IP cụ thể).
Bỏ qua dấu vân tay TLS. Thay đổi IP mà không thay đổi HTTP-client không giúp ích gì nếu trang web xác định bot qua chữ ký TLS handshake - ở đây cần có sự kết hợp với trình duyệt headless, không chỉ là các yêu cầu httpx.
Quyền truy cập trực tiếp của agent vào "thô" thông tin đăng nhập proxy. Bằng cách cho mô hình quyền truy cập vào tên đăng nhập/mật khẩu API proxy trực tiếp trong prompt, bạn có nguy cơ bị rò rỉ khi ghi lại các cuộc hội thoại - hãy sử dụng công cụ MCP như một lớp trung gian.

Kết luận

Kết nối AI-agent với MCP-server và API proxy thay đổi logic của việc phân tích: thay vì các quy tắc cứng về việc thay đổi theo thời gian, agent quyết định thay đổi IP dựa trên thực tế bị chặn, kết hợp các phiên "dính" và đơn lẻ, thích ứng với trang web cụ thể mà không cần viết lại mã. Điều này đặc biệt rõ ràng trên các nền tảng có bảo vệ chống bot tích cực - các thị trường, mạng xã hội, nền tảng quảng cáo.

Để phân tích các thị trường và trang web có bảo vệ nghiêm ngặt, tốt nhất là ngay từ đầu nên đưa vào kiến trúc proxy cư trú - chúng cung cấp cho agent nhiều "không gian" để điều chỉnh mà không bị cháy IP nhanh chóng. Nếu nhiệm vụ liên quan đến mạng xã hội và ứng dụng di động, hãy chú ý đến proxy di động - chúng ít gây nghi ngờ hơn đối với các hệ thống chống bot. Còn đối với việc thu thập dữ liệu kỹ thuật hàng loạt từ các nguồn ít bảo vệ hơn, các proxy trung tâm dữ liệu nhanh chóng và giá cả phải chăng sẽ phù hợp, mà agent có thể sử dụng kết hợp với IP cư trú để tối ưu hóa ngân sách.