Lỗi 410 Gone khi crawl và cách cập nhật kho URL

lỗi 410 Gone khi crawl báo rằng tài nguyên không còn sẵn có và tình trạng có thể kéo dài. Anh em cần xác định đúng response, dừng vòng thử lại vô ích và cập nhật trạng thái URL. Việc thu thập bằng chứng nên tách khỏi quyết định xóa dữ liệu đã lưu. ProxyVN hướng dẫn anh em kiểm đúng lớp gây lỗi và giữ bằng chứng trước khi thay cấu hình.

Lỗi 410 Gone khi crawl và ý nghĩa của tài nguyên đã gỡ

Mã 410 cung cấp một tín hiệu về vòng đời tài nguyên, khác việc đường truyền đang tạm lỗi. Khi một URL được trả về với trạng thái này, crawler cần xem xét chính sách ngừng lấy lại thay vì tăng retry ngay. Điểm cần xác nhận là mã thực trên response của đúng URL, cùng chuỗi redirect và nơi phát sinh. Một tiêu đề trang có chữ Gone nhưng status 200 là một tình huống khác cần phân loại riêng.

MDN giải thích 410 là tài nguyên không còn tại origin và tình trạng có khả năng mang tính lâu dài. So với 404, tín hiệu về việc tài nguyên đã gỡ rõ hơn. Tuy vậy, người vận hành vẫn có thể cấu hình nhầm mã hoặc thay đổi chính sách sau đó. Vì thế, crawler nên lưu trạng thái có nguồn và thời điểm, không biến một lần nhận mã thành thao tác xóa mọi dấu vết của dữ liệu.

Phân biệt 410 và 404

404 không nói rõ tình trạng là tạm thời hay kéo dài. Nó có thể xuất hiện do URL sai, tài nguyên chưa tạo hoặc bên phục vụ không muốn tiết lộ tồn tại. Với 410, hướng xử lý thường là ngừng vòng retry thông thường cho URL đã được xác nhận. Không gán tất cả 404 thành Gone để giảm hàng đợi; cách gộp đó làm mất khả năng phát hiện lỗi tạo URL, thay đổi đường dẫn hoặc sự cố triển khai ngắn hạn.

Trong kho URL, nên có trạng thái riêng cho not_found và gone. Trạng thái này khác lỗi kết nối, lỗi phân tích và phản hồi bị từ chối quyền truy cập. Khi báo cáo, giữ cả số URL mới nhận 410 và số URL đã ở trạng thái đó từ trước. Tổng số lượt HTTP bị lặp trên cùng URL không phải số tài nguyên mới bị gỡ; phân biệt hai đơn vị giúp nhìn đúng biến động của nguồn dữ liệu.

Không suy ra lý do pháp lý hoặc kỹ thuật cụ thể

Một 410 không tự nói ai gỡ tài nguyên, vì sao gỡ hay dữ liệu được phép lưu bao lâu. Nếu response có lời giải thích, lưu phần cần thiết cùng nguồn để bên phụ trách xem xét. Không tự diễn giải nó thành lỗi bản quyền, yêu cầu pháp lý hoặc bằng chứng server hỏng. Các quyết định về lưu trữ và sử dụng dữ liệu cần theo chính sách của tổ chức và thỏa thuận với nguồn, tách khỏi ý nghĩa kỹ thuật của status.

Đổi proxy không làm một URL đã gỡ xuất hiện trở lại theo hợp đồng của origin. Nếu các đường truy cập được phép cho kết quả khác nhau, cần kiểm cache, phiên và endpoint trước khi kết luận. Mục tiêu là xác định phản hồi của tài nguyên dự kiến, không tìm cách tiếp tục lấy nội dung khi nguồn đã công bố ngừng phục vụ. Với dữ liệu quan trọng, ưu tiên liên hệ bên cung cấp để biết nguồn thay thế chính thức nếu có.

Lỗi 410 Gone khi crawl trong bộ URL fixture

Một bộ ca nhỏ giúp kiểm chính sách crawler mà không gửi tải tới website bên ngoài. Chuẩn bị ba đường dẫn: một trả dữ liệu 200, một trả 404 và một trả 410. Dữ liệu chỉ là fixture của nhóm kiểm thử, không đại diện một sự kiện gỡ nội dung thật. Khi dùng cùng client, anh em có thể xác nhận status được lưu riêng và hàng đợi không tự coi mọi response có body là dữ liệu thành công.

Server trả ba trạng thái rõ ràng

from http.server import BaseHTTPRequestHandler, HTTPServer
 
class Fixture(BaseHTTPRequestHandler):
    def do_GET(self):
        status = {'/ok': 200, '/missing': 404, '/gone': 410}.get(self.path, 404)
        body = b'{"item":"lab"}' if status == 200 else b''
        self.send_response(status)
        self.send_header('Content-Type', 'application/json')
        self.send_header('Cache-Control', 'no-store')
        self.send_header('Content-Length', str(len(body)))
        self.end_headers()
        self.wfile.write(body)
 
HTTPServer(('127.0.0.1', 8768), Fixture).serve_forever()

Lưu thành lab410.py rồi chạy trên Python 3 trong terminal riêng. Cache-Control no-store giúp ca cơ sở tập trung vào chính sách crawler thay vì một lớp cache. Nó là lựa chọn của fixture, không có nghĩa mọi 410 thực đều mang header này. Trong phép thử cục bộ của bài, ba đường dẫn cho đúng 200, 404, 410. Kết quả này xác nhận bộ đầu vào để kiểm phân loại, chưa xác nhận scheduler sản xuất của anh em đã xử lý đúng.

Client lưu trạng thái thay vì chỉ bắt exception

import http.client
 
states = {}
for path in ('/ok', '/missing', '/gone'):
    conn = http.client.HTTPConnection('127.0.0.1', 8768, timeout=2)
    conn.request('GET', path)
    response = conn.getresponse()
    response.read()
    states[path] = {
        200: 'fetched', 404: 'not_found', 410: 'gone'
    }.get(response.status, 'needs_review')
    conn.close()
assert states == {'/ok': 'fetched', '/missing': 'not_found', '/gone': 'gone'}
print(states)

Mẫu dùng http.client nên lỗi HTTP không tự biến thành exception như ở một số API cấp cao. Khi áp dụng thư viện khác, kiểm cách nó giữ response trong exception và cách đọc status. Không bắt mọi exception rồi trả nội dung rỗng, vì như vậy DNS lỗi, timeout và 410 có thể bị gộp vào cùng kết quả không dữ liệu. Một tầng thu thập tốt cần trả về kết quả có cấu trúc cho tầng quyết định lịch.

Vòng đời tài nguyên và status

Lỗi 410 Gone khi crawl và thiết kế trạng thái URL

Một URL có nhiều thông tin hơn trạng thái cuối. Kho dữ liệu nên giữ URL ban đầu, URL cuối sau redirect, lần thành công gần nhất và lần kiểm gần nhất. Các trường này phục vụ các câu hỏi khác nhau: dữ liệu từng tồn tại lúc nào, lần nào mới xác nhận mất và URL nào thực phát status. Không ghi đè mọi trường bằng thời điểm hiện tại rồi làm mất lịch sử cần để điều tra.

Tách dữ liệu nội dung và dữ liệu thu thập

Nếu crawler đã có một bản nội dung cũ, nhận 410 ở lần sau không buộc tầng kỹ thuật phải xóa ngay bản đó. Có thể đánh dấu nguồn hiện không còn phục vụ, giữ phiên bản lịch sử theo chính sách đã được phê duyệt. Giao diện sử dụng dữ liệu cần biết đây là bản đã lưu, không phải nội dung vừa được nguồn xác nhận. Việc gắn thời điểm và trạng thái nguồn giúp tránh trình bày dữ liệu cũ như dữ liệu đang hoạt động.

Không nên viết nội dung trang lỗi vào cột nội dung chính của tài nguyên. Nếu lưu response lỗi để chẩn đoán, đặt nó trong vùng bằng chứng có loại dữ liệu và thời hạn phù hợp. Một thông báo Gone có thể là HTML dài hoặc thông tin vận hành không cần cho bộ tìm kiếm nội bộ. Tách vùng lưu sẽ giúp chỉ mục không vô tình đưa trang lỗi vào kết quả như thể nó là phiên bản mới của bài viết.

Tombstone cần đủ thông tin để giải thích

Một bản ghi đánh dấu đã gỡ có thể gồm status, nguồn kiểm, thời điểm, URL cuối và lý do ngắn nếu nguồn cung cấp. Không cần sao chép toàn bộ lịch sử request để giữ ý nghĩa này. Quan trọng là người dùng dữ liệu biết vì sao tài nguyên không được cập nhật nữa và có thể tìm tới bằng chứng phù hợp. Nếu có trạng thái xác nhận thủ công, lưu người hoặc quy trình đã xác nhận theo cơ chế nội bộ.

Tombstone không nên được tạo chỉ từ lỗi parser hoặc body trống. Một response 200 không có trường mong đợi có thể là lỗi schema, trang đăng nhập hoặc biến thể khác, chứ chưa phải 410. Cần giữ nguyên status và phân loại riêng các thất bại xử lý dữ liệu. Khi các tầng này tách rõ, nhóm vận hành có thể sửa parser mà không phải khôi phục hàng nghìn URL đã bị đánh dấu gỡ sai.

Lỗi 410 Gone khi crawl và cache phản hồi âm

Phản hồi lỗi cũng có thể được cache theo quy tắc HTTP. Vì vậy, status nhận ở client không phải lúc nào cũng là câu trả lời mới từ origin trong thời điểm đó. Khi điều tra một URL vừa đổi trạng thái, kiểm Cache-Control, tuổi response và các dấu hiệu cache mà hệ thống công bố. RFC về HTTP caching là nguồn để hiểu việc tái sử dụng phản hồi; triển khai cụ thể vẫn cần đọc cấu hình của từng hop.

Lần thấy gần nhất khác lần origin xác nhận

Nếu crawler nhận cùng response cache nhiều lần, trường last_seen có thể tăng nhưng thời điểm origin tạo thông tin không đổi. Không nên coi mỗi lần đó là một xác nhận mới rằng tài nguyên vẫn Gone. Trong báo cáo, có thể giữ thời điểm thu nhận và thông tin cache riêng nếu cần mức tin cậy này. Khi không đủ dữ liệu, ghi rằng status được nhận qua lớp cache, tránh khẳng định đã hỏi origin trực tiếp.

Không gửi hàng loạt tham số ngẫu nhiên để phá cache. Cách đó có thể tạo URL khác, làm mất liên hệ với tài nguyên cần kiểm và gây tải thừa. Nếu nhóm vận hành có cơ chế kiểm hoặc xóa cache được phép, dùng cơ chế đó theo phạm vi cụ thể. Với nguồn bên ngoài, tôn trọng chỉ dẫn và nhờ bên cung cấp xác nhận thay vì coi việc gọi nhiều biến thể URL là bằng chứng kỹ thuật tốt hơn.

Cache và redirect có thể chồng nhau

Một URL cũ có thể chuyển tới URL mới rồi nhận 410 ở đích. Crawler cần lưu cả chuỗi hoặc ít nhất cặp đầu và cuối để tránh kết luận URL ban đầu trực tiếp phát mã. Nếu redirect trỏ tới trang chung cho mọi tài nguyên đã gỡ, body có thể giống nhau dù danh tính tài nguyên khác nhau. Khóa dữ liệu phải gắn với tài nguyên nguồn, không gộp theo hash trang lỗi rồi làm mất các URL liên quan.

Khi URL có canonical hoặc nhiều biến thể tham số, quy tắc chuẩn hóa cần được xác định trước. Đừng xóa tham số chỉ vì một biến thể nhận 410; tham số đó có thể chọn tài nguyên khác. Hãy dựa vào hợp đồng của nguồn hoặc cấu trúc đường dẫn đã được xác nhận. Một lỗi chuẩn hóa có thể làm crawler hỏi nhầm URL rồi lưu trạng thái Gone cho một tài nguyên vẫn tồn tại ở địa chỉ hợp lệ.

Bộ URL đối chứng

Lỗi 410 Gone khi crawl và lịch lấy lại dữ liệu

Lịch thu thập nên phân biệt retry nhanh với kiểm tra lại vòng đời. Sau một 410 đã xác nhận, retry ngay cùng URL thường không có mục đích. Một tổ chức có thể đặt lịch rà lại chậm hơn hoặc chỉ mở lại khi nguồn cung cấp tín hiệu mới, tùy hợp đồng dữ liệu. Đừng biến điều đó thành một khoảng thời gian chung cho mọi website, vì tần suất phù hợp phụ thuộc nhu cầu và quyền truy cập của từng nguồn.

Dừng vòng retry thông thường

Nếu scheduler có danh sách status được thử lại, kiểm xem 410 có bị thêm nhầm vào nhóm lỗi tạm thời không. Một lỗi cấu hình thường gặp là thử lại mọi mã khác 200 mà không xét ý nghĩa. Cần có nhánh kết thúc tác vụ với lý do gone, đồng thời không báo thành công thu nội dung mới. Nhánh đó nên được kiểm bằng fixture để xác nhận tác vụ không quay lại hàng đợi ngay trong cùng chu kỳ.

Đếm số lần xử lý ở tầng hàng đợi và số HTTP request thực để phát hiện retry ẩn. Thư viện tải, middleware và scheduler có thể cùng phát lại. Nếu chỉ kiểm một tầng, URL đã Gone vẫn có thể được gọi nhiều lần bởi tầng còn lại. Một ca thử với mã tương quan và bộ đếm request tại fixture sẽ cho thấy đường đi đầy đủ, giúp sửa đúng nơi tạo lượt thừa mà không thay cả hệ thống.

Mở lại trạng thái khi có bằng chứng mới

Nguồn có thể khôi phục nội dung hoặc chuyển sang địa chỉ chính thức khác. Nếu có thông báo cập nhật được phép dùng, quy trình có thể đưa URL vào một ca kiểm lại riêng. Khi nhận 200, vẫn cần kiểm danh tính và nội dung: một trang chung hoặc trang đăng nhập không chứng minh tài nguyên cũ đã quay lại. Trạng thái chuyển từ Gone sang hoạt động cần gắn với bằng chứng đầu ra phù hợp, không chỉ một mã thành công.

Nếu URL mới đại diện cho tài nguyên kế nhiệm, cân nhắc lưu quan hệ thay thế thay vì ghi đè danh tính cũ. Dữ liệu lịch sử có thể cần biết mục nào đã bị gỡ và mục nào được tạo sau đó. Với hệ thống đồng bộ, việc giữ quan hệ rõ giúp tránh nối nhầm nội dung mới vào bản ghi cũ chỉ vì đường dẫn có vẻ tương tự. Quyết định đó thuộc mô hình dữ liệu và cần được nhóm sử dụng dữ liệu hiểu.

Lỗi 410 Gone khi crawl và chất lượng dữ liệu xuống dòng

Khi một tài nguyên không còn ở nguồn, các hệ thống tiêu thụ dữ liệu cần được thông báo đúng mức. Một chỉ mục tìm kiếm, báo cáo phân tích và kho lưu trữ có thể có cách xử lý khác nhau. Crawler không nên tự áp một thao tác xóa vật lý cho mọi bên. Thay vào đó, phát trạng thái nguồn cùng thời điểm và phiên bản dữ liệu để từng hệ thống áp chính sách đã thống nhất.

Chỉ mục và bộ nhớ đệm nội bộ

Nếu chỉ mục hướng tới nội dung hiện còn công khai tại nguồn, trạng thái Gone có thể dẫn tới việc ẩn hoặc gắn nhãn bản ghi theo quy trình. Nếu chỉ mục dành cho lưu trữ lịch sử được phép, có thể giữ nội dung với dấu thời gian và nhãn nguồn đã ngừng phục vụ. Hai mục tiêu khác nhau cần hai chính sách khác nhau. Không dùng một tên trạng thái kỹ thuật để bỏ qua câu hỏi về mục đích của sản phẩm dữ liệu.

Khi cập nhật nhiều hệ thống, cần có mã sự kiện hoặc phiên bản để tránh xử lý trùng. Một sự kiện Gone được phát lại không nên làm xóa thêm các tài nguyên khác do khóa nối thiếu phạm vi. Kiểm khóa theo nguồn và URL chuẩn đã xác nhận, nhất là khi nhiều nguồn có cùng một đường dẫn tương đối. Với dữ liệu liên kết, giữ bản ghi tham chiếu tối thiểu để các bảng khác không rơi vào trạng thái không giải thích được.

Báo cáo không nên nhầm mất nguồn với mất bản lưu

Trong dashboard, tách số tài nguyên không còn tại nguồn khỏi số bản ghi đã xóa trong kho. Một 410 có thể chỉ thay trạng thái thu thập, trong khi dữ liệu cũ vẫn được giữ theo chính sách. Nếu hai con số bị gộp, người quản lý khó hiểu dung lượng kho hoặc mức độ cập nhật. Cần mô tả đơn vị đo rõ trong báo cáo và giữ quy tắc tính ổn định giữa các kỳ.

Một đợt tăng 410 đồng loạt có thể do nguồn thay chính sách đường dẫn hoặc do crawler tạo URL sai sau bản sửa. Trước khi xử lý hàng loạt, lấy một nhóm mẫu đại diện để kiểm. So phiên bản bộ tạo URL, redirect và thông báo từ nguồn nếu có. Không tự kết luận nguồn đã gỡ toàn bộ dữ liệu chỉ từ một mẫu lỗi phát sinh đồng thời với thay đổi mã của hệ thống thu thập.

Trạng thái nguồn và bản lưu

Lỗi 410 Gone khi crawl và ranh giới với proxy

Proxy là một phần của tuyến kết nối, còn 410 là phản hồi về tài nguyên từ một thành phần HTTP. Cần biết thành phần nào tạo response và nó có đại diện đúng origin không. Nếu dùng forward proxy cục bộ trong kiểm thử, chỉ nên xác minh nó chuyển tiếp status và giữ dữ liệu phân loại. Không cần thêm cơ chế xoay địa chỉ để xử lý một trạng thái vòng đời đã được nguồn thông báo.

Kiểm đường đi bằng cùng một URL

Khi cần điều tra và được phép so tuyến, dùng đúng URL, method và trạng thái phiên. Kiểm cấu trúc URL proxy để tránh nhầm lỗi đầu vào gateway với status từ nguồn. Nếu có danh sách no_proxy, ghi rõ ca nào bypass theo chính sách. Đừng nhận rằng đã so qua hai đường nếu cả hai lượt đều bị cùng một quy tắc bypass đưa về đường trực tiếp.

Một response từ proxy có thể có body thông báo riêng, nhưng tên mẫu trang không đủ xác định nguồn phát. Cần log hoặc header tương quan từ thành phần được quản lý. Với HTTPS không giải mã tại proxy, giữ phân biệt tunnel và response bên trong. Nếu chưa quan sát được nguồn phát 410, báo kết quả ở mức client nhận status đó; không mở rộng thành kết luận về chính sách gỡ dữ liệu của một bên cụ thể.

Hồ sơ hỗ trợ ngắn và có ích

Hồ sơ nên gồm URL đã che dữ liệu không cần thiết, thời điểm, method, status, URL cuối và mẫu body lỗi rút gọn. Thêm lần thành công gần nhất nếu kho có, cùng thay đổi client gần thời điểm lỗi. Không gửi cookie, bearer token hoặc tài khoản proxy để chứng minh một status. Người hỗ trợ thường cần biết tuyến và request nào, không cần nhận toàn bộ môi trường riêng tư của worker.

Nếu cần mua proxy uy tín cho hoạt động thu thập được phép, anh em nên đánh giá tuyến bằng một endpoint kiểm phù hợp trước. Sau đó xử lý trạng thái vòng đời của nguồn theo hợp đồng dữ liệu; không coi việc mua thêm gateway là phương án phục hồi tài nguyên đã được công bố gỡ.

Lỗi 410 Gone khi crawl và ca nghiệm thu scheduler

Trước khi mở rộng lô, hãy chạy fixture qua chính pipeline mà hệ thống dùng thật. Mỗi URL cần đi qua bước tải, phân loại, cập nhật trạng thái và lập lịch tiếp theo. Một unit test chỉ gọi hàm chuyển status thành chuỗi chưa kiểm được vòng retry bên ngoài. Kết quả nghiệm thu nên cho thấy /gone không bị xếp lại tức thời, /missing có chính sách riêng và /ok vẫn đi qua bước kiểm nội dung.

Ca kiểm bản lưu cũ

Tạo một bản ghi giả có nội dung thành công trước đó rồi cho lần kiểm mới nhận 410. Xác nhận hệ thống giữ hoặc xóa nội dung theo đúng chính sách đã chọn, đồng thời cập nhật trạng thái nguồn. Kiểm rằng thời điểm thành công cũ không bị ghi đè bằng thời điểm lỗi mới. Đây là phần quan trọng vì một bản sửa scheduler có thể đúng số lần request nhưng làm mất lịch sử dữ liệu cần cho người sử dụng.

Tiếp theo, phát lại cùng sự kiện Gone để kiểm tính lặp của cập nhật. Nó không được tạo thêm bản ghi nội dung rỗng, gửi nhiều thông báo giống nhau hoặc làm sai số đếm tài nguyên. Cuối cùng, cho nguồn fixture trở lại 200 trong một ca mở lại có chủ ý và xác nhận hệ thống kiểm danh tính trước khi chuyển trạng thái. Bộ ca này kiểm vòng đời dữ liệu, không chỉ một lệnh HTTP riêng lẻ.

URL hết hạn khác tài nguyên đã gỡ

Một đường dẫn tạm hoặc URL được ký có thể ngừng hoạt động khi hết hạn, trong khi tài nguyên còn tồn tại qua quy trình cấp URL mới. Status cụ thể phụ thuộc dịch vụ, nên không đoán rằng mọi đường dẫn cũ hỏng đều là 410. Nếu nguồn công bố vòng đời URL, lưu định danh tài nguyên bền vững theo hợp đồng và tạo lại đường truy cập qua cách được phép. Không sửa chữ ký hoặc tham số thời hạn bằng tay để biến URL cũ thành một địa chỉ mới.

Khi kho đang lưu URL tạm như khóa chính, một lần hết hạn có thể bị hiểu nhầm là tài nguyên bị gỡ. Cần xem lại mô hình định danh trước khi cập nhật hàng loạt trạng thái. Một ID nguồn ổn định và URL truy cập hiện tại có thể là hai trường khác nhau. Việc tách chúng giúp crawler quản lý vòng đời đường dẫn mà không làm mất quan hệ với bản nội dung đã thu, nếu hợp đồng của nguồn cho phép cách dùng đó.

Link nội bộ của chính kho dữ liệu

Nếu sản phẩm của anh em tạo liên kết tới nguồn, trạng thái Gone có thể cần được phản ánh ở giao diện. Có thể gắn nhãn nguồn không còn phục vụ hoặc thay link khi có địa chỉ kế nhiệm chính thức, theo mục đích sản phẩm. Không tự trỏ mọi link cũ về trang chủ của nguồn vì người dùng sẽ mất ngữ cảnh và có thể hiểu nhầm tài nguyên vẫn có ở đó. Mỗi thay đổi liên kết cần giữ lý do và khả năng truy nguyên tới tài nguyên cũ.

Với báo cáo trích dữ liệu lịch sử, giữ thời điểm thu và trạng thái nguồn hiện tại theo phạm vi cần thiết. Một số người dùng cần biết bản ghi được lấy lúc nào để đánh giá độ mới, còn người khác chỉ cần dữ liệu đang hoạt động. Crawler nên cung cấp metadata đủ để hai nhu cầu đó được xử lý rõ ràng. Không để một cột trạng thái cuối thay thế toàn bộ lịch sử rồi buộc mọi người suy đoán dữ liệu đã từng tồn tại hay chưa.

Tái hiện lỗi chuẩn hóa URL

Trong bộ fixture, có thể thêm hai đường dẫn gần giống nhau nhưng có danh tính khác: một hoạt động và một Gone. Cho bộ chuẩn hóa URL chạy qua cả hai rồi xác nhận nó không gộp nhầm. Ca này có ích khi hệ thống xóa tham số, đổi hoa thường hoặc chuẩn hóa dấu gạch chéo. Một quy tắc phù hợp với một nguồn không tự áp dụng cho mọi nguồn; cần gắn cấu hình chuẩn hóa với hợp đồng và giữ các ca phân biệt mà nguồn sử dụng.

Nếu hai tài nguyên bị gộp nhầm, sửa khóa và kế hoạch phục hồi dữ liệu trước khi tiếp tục lô. Không chỉ làm URL hoạt động trở lại trong hàng đợi mà bỏ trạng thái Gone đã lan xuống các hệ thống khác. Sự kiện sửa cần có phạm vi và phiên bản để các bên tiêu thụ cập nhật đúng bản ghi. Như vậy, một lỗi tạo URL được xử lý như lỗi dữ liệu có nguồn gốc, thay vì bị che thành thay đổi vòng đời của tài nguyên tại origin.

Dừng retry một URL đã Gone và xóa dữ liệu đã lưu là hai quyết định cần được quản lý riêng.

Lịch kiểm lại URL

Anh em nên giữ request mẫu, kết quả đối chứng và cấu hình đã che thông tin nhạy cảm để kiểm lại sau thay đổi. Theo dõi Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam để tham khảo nội dung liên quan. Khi triển khai, đánh giá đúng phạm vi của lỗi 410 Gone khi crawl.