← Quay lại blog
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

Tại sao trình phân tích hiển thị sai khu vực của trang web: Accept-Language, tiền tệ và cookie địa lý

Tại sao trình phân tích cú pháp tải xuống phiên bản trang không phải là phiên bản mà người dùng thực thấy, và cách khắc phục điều này thông qua tiêu đề, cookie và lựa chọn proxy đúng.

📅22 tháng 10, 2026

Parser được khởi động, mã không bị lỗi, dữ liệu đến — nhưng giá bằng đô la thay vì rúp, văn bản bằng tiếng Anh, và các sản phẩm khác với những gì người dùng thực thấy từ Nga. Đây là một trong những vấn đề phổ biến và khó chịu nhất trong việc phân tích: về mặt kỹ thuật mọi thứ đều hoạt động, nhưng nội dung “không đúng”. Chúng ta sẽ phân tích lý do tại sao điều này xảy ra và cách tạo ra một yêu cầu nhận đúng phiên bản trang mà bạn cần.

Triệu chứng: làm thế nào để hiểu rằng parser thấy không đúng phiên bản

Trước khi sửa vấn đề, điều quan trọng là phải chẩn đoán đúng. Có ba kịch bản điển hình mà parser nhận được dữ liệu khác với những gì người dùng thông thường trong trình duyệt thấy:

  • Ngôn ngữ nội dung không khớp — bạn mong đợi văn bản tiếng Nga, nhưng nhận được phiên bản tiếng Anh hoặc tiếng Ukraina của trang.
  • Tiền tệ và giá khác nhau — trang web hiển thị giá bằng USD hoặc EUR, trong khi trong trình duyệt từ Nga bạn thấy rúp, hoặc các con số đơn giản là khác nhau (định giá theo khu vực).
  • Danh mục sản phẩm/nội dung khác — sự sẵn có của sản phẩm, khuyến mãi, cửa hàng hoàn toàn phụ thuộc vào khu vực mà trang web “nhìn thấy” từ bạn.

Nguyên nhân gần như luôn là một trong ba điều (hoặc sự kết hợp của chúng): tiêu đề Accept-Language, cookie thiếu hoặc không chính xác, hoặc địa chỉ IP mà yêu cầu được gửi từ đó. Chúng ta sẽ phân tích từng điều một.

Accept-Language: cách máy chủ chọn ngôn ngữ phản hồi

Trình duyệt gửi tiêu đề Accept-Language trong mỗi yêu cầu, trong đó liệt kê các ngôn ngữ ưa thích của người dùng với trọng số (giá trị q). Ví dụ về những gì thực sự được gửi bởi Chrome với ngôn ngữ Nga: 

Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7

Các thư viện phân tích (requests, httpx, scrapy) mặc định không gửi tiêu đề này, hoặc gửi một cái gì đó như */*. Trong trường hợp này, máy chủ sẽ gửi ngôn ngữ mặc định (thường là tiếng Anh), hoặc xác định ngôn ngữ theo IP — và đây là lúc phần geo tham gia, như sẽ được đề cập bên dưới.

Một điểm quan trọng: nhiều trang web sử dụng kết hợp “Accept-Language + địa lý IP”, chứ không phải chỉ một trong hai. Điều này có nghĩa là ngay cả khi bạn gửi tiêu đề ngôn ngữ chính xác, nhưng yêu cầu đến từ IP của một quốc gia khác, trang web có thể vẫn chuyển bạn sang phiên bản tiếng Anh hoặc phiên bản địa phương cho khu vực mà yêu cầu thực sự đến từ đó.

Tiền tệ và địa phương: trang web lấy giá từ đâu

Tiền tệ gần như không bao giờ được xác định trực tiếp bởi tiêu đề Accept-Language. Thường sử dụng một trong ba cơ chế (hoặc sự kết hợp của chúng):

  1. Cơ sở GeoIP — máy chủ xem IP đến từ quốc gia nào và tự động thay thế tiền tệ và địa phương tương ứng khi lần đầu truy cập.
  2. Cookie với khu vực đã chọn trước đó — nếu người dùng đã từng chọn quốc gia và tiền tệ bằng tay, trang web lưu điều này trong cookie và không kiểm tra IP nữa.
  3. Tham số trong URL hoặc tên miền phụ — một số trang web sử dụng các dấu hiệu rõ ràng như ?country=ru hoặc ru.example.com.

Trong thực tế, nếu bạn phân tích một cửa hàng trực tuyến và thấy giá bằng đô la thay vì rúp, trong 80% trường hợp vấn đề không nằm ở tiêu đề, mà chính là địa chỉ IP của yêu cầu. Trang web chỉ đơn giản là “nhìn thấy” một IP không phải của Nga và đã thay thế bằng cửa hàng quốc tế mặc định.

Sau khi trang web xác định khu vực của bạn một lần (qua IP hoặc qua lựa chọn thủ công trên banner “Chọn thành phố của bạn”), nó lưu quyết định này trong cookie — thường với các tên như region, geo_city, currency hoặc locale. Sau đó, tất cả các yêu cầu với cookie này sẽ được xử lý theo khu vực đã lưu — ngay cả khi IP bất ngờ thay đổi.

Điều này tạo ra một cái bẫy cho parser: nếu bạn một lần nhận được phiên bản “không đúng” và lưu cookie của phiên làm việc, tất cả các yêu cầu tiếp theo sẽ tái tạo cùng một lỗi, ngay cả khi bạn sửa tiêu đề hoặc proxy. Do đó, khi chẩn đoán, hãy luôn kiểm tra phân tích với một phiên làm việc sạch — không có cookie đã lưu từ các lần chạy trước.

Mặt trái của cùng một cơ chế là hữu ích: nếu bạn biết tên của cookie cần thiết và giá trị chính xác của nó cho khu vực mục tiêu (ví dụ, đã xem nó trong DevTools của trình duyệt ở vị trí cần thiết), bạn có thể ép buộc đặt giá trị này trong yêu cầu mà không cần thay đổi IP. Điều này hoạt động cho các trang web mà khu vực được xác định chỉ thông qua cookie flag, nhưng không hoạt động nếu máy chủ kiểm tra lại IP với cơ sở GeoIP mỗi lần yêu cầu.

Vai trò của địa chỉ IP và proxy trong việc xác định khu vực

Xác định GeoIP là cách đáng tin cậy nhất cho trang web để hiểu từ đâu thực sự đến yêu cầu, vì tiêu đề và cookie có thể bị giả mạo, nhưng địa chỉ IP thì không thể (chỉ có thể thay thế bằng một địa chỉ thực khác). Chính vì vậy, để nhận được phiên bản khu vực “đúng” của trang, không đủ chỉ với các tiêu đề HTTP — cần một IP thực sự thuộc về quốc gia cần thiết.

Ở đây có sự khác biệt đáng kể giữa các loại địa chỉ IP:

  • IP trung tâm dữ liệu — Các cơ sở GeoIP thường xác định chúng đúng theo quốc gia, nhưng nhiều trang web lớn (đặc biệt là thị trường và dịch vụ bảo vệ chống bot) đánh dấu các dải địa chỉ IP của trung tâm dữ liệu là đáng ngờ và có thể hiển thị phiên bản nội dung bị cắt giảm hoặc mặc định bất kể vị trí địa lý.
  • IP cư trú — thuộc về các nhà cung cấp thực và địa chỉ vật lý, vì vậy GeoIP xác định khu vực chính xác hơn, và trang web coi yêu cầu như của một người dùng bình thường từ quốc gia/thành phố đó.
  • IP di động — gắn liền với các nhà mạng di động của một quốc gia cụ thể, điều này đặc biệt quan trọng cho các trang web và ứng dụng hoạt động khác nhau với lưu lượng di động và máy tính để bàn.

Đối với các nhiệm vụ như giám sát giá trên Wildberries, Ozon hoặc Avito từ các thành phố cụ thể, tốt nhất là proxy cư trú — chúng cung cấp IP gắn liền với khu vực thực, và các cơ sở GeoIP của trang web xác định quốc gia và thành phố chính xác, không thay thế bằng cửa hàng quốc tế mặc định.

Thực hành: tạo yêu cầu đúng trên Python

Chúng ta sẽ tạo một yêu cầu, đồng thời giải quyết cả ba vấn đề: gửi Accept-Language chính xác, sử dụng phiên làm việc sạch với các cookie cần thiết và đi qua IP của khu vực cần thiết. 

import requests

proxies = {
    "http": "http://user:[email protected]:8080",
    "https": "http://user:[email protected]:8080",
}

headers = {
    "Accept-Language": "ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7",
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                  "AppleWebKit/537.36 (KHTML, like Gecko) "
                  "Chrome/124.0.0.0 Safari/537.36",
}

cookies = {
    "region": "ru",
    "currency": "RUB",
}

session = requests.Session()
response = session.get(
    "https://example.com/catalog",
    headers=headers,
    cookies=cookies,
    proxies=proxies,
    timeout=15,
)

print(response.status_code)
print(response.text[:500])

Một vài điểm quan trọng trong mã này:

  • Sử dụng requests.Session(), thay vì một requests.get() đơn lẻ, để máy chủ có thể thiết lập thêm cookie nếu cần, và chúng sẽ được lưu giữa các yêu cầu của một phiên phân tích.
  • Giá trị cookie region và currency — là điều kiện, tên và giá trị thực tế của chúng cần được xem trong DevTools của trình duyệt (tab Application → Cookies) trên trang web mục tiêu với vị trí cần thiết.
  • Proxy phải thực sự nằm trong quốc gia cần thiết — nếu không, ngay cả khi tiêu đề và cookie đúng, máy chủ có thể ghi đè chúng khi xác định lại vị trí địa lý.

Trang web JS: Playwright và quản lý tiêu đề/cookie

Nếu trang web hiển thị nội dung qua JavaScript (giá được tải qua một yêu cầu riêng sau khi tải trang), yêu cầu requests đơn giản là không đủ — cần một trình duyệt headless. Trong Playwright, ngôn ngữ, khu vực và proxy được thiết lập ở cấp độ ngữ cảnh của trình duyệt: 

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    context = browser.new_context(
        locale="ru-RU",
        timezone_id="Europe/Moscow",
        proxy={
            "server": "http://gate.proxycove.com:8080",
            "username": "user",
            "password": "pass",
        },
    )
    context.add_cookies([
        {"name": "region", "value": "ru", "domain": "example.com", "path": "/"},
        {"name": "currency", "value": "RUB", "domain": "example.com", "path": "/"},
    ])

    page = context.new_page()
    page.goto("https://example.com/catalog")
    page.wait_for_selector(".price")
    print(page.content()[:500])

    browser.close()

Lưu ý về tham số timezone_id — nhiều trang web kiểm tra thêm múi giờ của trình duyệt với múi giờ mong đợi cho khu vực, và sự khác biệt (ví dụ, IP từ Nga, nhưng múi giờ của trình duyệt là của Mỹ) có thể tự nó là tín hiệu cho hệ thống chống bot rằng yêu cầu là đáng ngờ, ngay cả khi ngôn ngữ và tiền tệ về mặt hình thức là đúng.

Những sai lầm điển hình và danh sách kiểm tra trước khi khởi động

Trước khi khởi động parser trong môi trường sản xuất, hãy đi qua một danh sách kiểm tra ngắn — điều này tiết kiệm hàng giờ gỡ lỗi:

  • ✅ Tiêu đề Accept-Language được thiết lập và khớp với khu vực mong đợi.
  • ✅ Phiên làm việc sạch — cookie không được kế thừa từ yêu cầu không thành công trước đó.
  • ✅ IP của proxy thực sự nằm trong quốc gia cần thiết (kiểm tra qua bất kỳ công cụ kiểm tra geo-IP nào trước khi phân tích).
  • ✅ User-Agent khớp với trình duyệt thực và không chứa dấu hiệu của chế độ headless.
  • ✅ Múi giờ và địa phương của trình duyệt (đối với Playwright/Selenium) khớp với quốc gia của IP.
  • ✅ Nếu trang web sử dụng lựa chọn khu vực thủ công trên banner — cookie của lựa chọn này được truyền tay.

Cần lưu ý về việc xoay vòng proxy: nếu bạn thay đổi IP cho mỗi yêu cầu, nhưng cookie của phiên làm việc vẫn giữ nguyên, trang web có thể thấy sự không nhất quán giữa “cookie khu vực A, nhưng IP khu vực B” và đặt lại phiên làm việc. Đối với các nhiệm vụ giám sát giá, tốt hơn là giữ một IP cho toàn bộ phiên phân tích của một khu vực cụ thể, thay vì xoay vòng nó giữa quá trình thu thập dữ liệu.

Loại proxy nào nên chọn cho nhiệm vụ

Việc chọn loại proxy ảnh hưởng trực tiếp đến độ chính xác mà trang web xác định khu vực của bạn và không nghi ngờ về tự động hóa. Đây là sự so sánh cho các nhiệm vụ phân tích phiên bản khu vực điển hình của các trang web:

Loại proxy Độ chính xác của vị trí địa lý Khi nào sử dụng
Proxy trung tâm dữ liệu Trung bình, quốc gia đúng, nhưng IP có thể bị đánh dấu là “không cư trú” Phân tích các trang web không có bảo vệ chống bot nghiêm ngặt, tốc độ và khối lượng yêu cầu cao
Proxy cư trú Cao, đến cả thành phố Giám sát giá trên các thị trường, nội dung khu vực, vượt qua các kiểm tra GeoIP
Proxy di động Cao, cộng với nhãn của nhà mạng di động Các trang web và ứng dụng hoạt động khác nhau với lưu lượng di động từ một quốc gia cụ thể

Nếu nhiệm vụ là giám sát danh mục và giá trên các thị trường từ các thành phố khác nhau, proxy cư trú thường mang lại kết quả dự đoán nhất: các cơ sở GeoIP thấy địa chỉ thực tế, không phải dải của trung tâm dữ liệu, mà một số trang web xử lý bằng logic riêng.

Kết luận

Vấn đề “parser thấy không đúng phiên bản của trang” gần như luôn bao gồm ba yếu tố: tiêu đề Accept-Language, xác định ngôn ngữ ưa thích của phản hồi; cookie, ghi nhớ khu vực và tiền tệ đã chọn trước đó; và vị trí địa lý của địa chỉ IP, mà máy chủ xác định quốc gia của yêu cầu khi lần đầu truy cập. Để nhận được đúng phiên bản của trang web mà người dùng thực thấy, cần phải đồng bộ hóa cả ba tham số cùng một lúc, chứ không phải sửa chữa chúng một cách riêng lẻ.

Nếu bạn thường xuyên phân tích các phiên bản khu vực của các trang web, giám sát giá của đối thủ trên các thị trường hoặc thu thập dữ liệu từ các quốc gia khác nhau, bạn nên bắt đầu từ việc chọn IP phù hợp — các cài đặt khác (tiêu đề, cookie, múi giờ) sẽ được xây dựng xung quanh nó. Để đạt được độ chính xác cao trong việc vào đúng khu vực, chúng tôi khuyên bạn nên thử proxy cư trú, cung cấp vị trí địa lý dự đoán và giảm thiểu rủi ro nhận được phiên bản quốc tế mặc định của trang web thay vì phiên bản địa phương.

Bài viết liên quan