Jina Reader API: đọc trang web thành Markdown và kiểm phần mất

Jina Reader API là dịch vụ nhận một URL rồi trả về nội dung trang dưới dạng Markdown, văn bản thuần hay JSON, đã chạy JavaScript và đã lược bỏ phần lớn thẻ HTML. Anh em chỉ cần thêm tiền tố r.jina.ai vào trước URL. Câu hỏi đáng hỏi là nội dung trả về có đủ không. ProxyVN chạy thử ngày 29/10/2026 trên hai trang của quotes.toscrape.com, trang tập scraping được dựng cho mục đích này. Reader lấy đủ 10 câu trích dẫn ở cả bản tĩnh lẫn bản JavaScript, nhưng bỏ toàn bộ 30 thẻ tag, mất tên tác giả ở 1 trên 10 câu, và trả mã 200 cho cả trang 404.

Jina Reader API: mục tiêu dữ liệu, quyền và phạm vi truy cập

Phần đầu chốt Reader dùng để làm gì, đầu ra cần đạt chuẩn nào, và ranh giới với các dịch vụ khác của Jina.

Reader là gì

Jina Reader là một dịch vụ HTTP. Gửi GET tới https://r.jina.ai/ nối với URL đích, dịch vụ tự tải trang bằng trình duyệt phía máy chủ, chạy JavaScript, trích phần nội dung chính, rồi trả về Markdown. Không cần cài gì trên máy.

Mục tiêu thiết kế là tạo đầu vào gọn cho mô hình ngôn ngữ. Vì vậy Reader ưu tiên văn bản chính và bỏ những gì nó cho là phụ: menu, chân trang, thanh bên, nút điều hướng.

Đầu ra mà bài này hướng tới

Đầu ra là tệp Markdown cho mỗi URL, kèm URL nguồn, thời điểm gọi, tiêu đề và một bảng so sánh với HTML gốc. Bảng so sánh trả lời: nội dung chính có đủ không, phần nào bị bỏ, và bỏ có chủ ý hay bỏ nhầm.

Bảng so sánh là phần quan trọng nhất. Với mô hình ngôn ngữ, bỏ menu là điều tốt. Với người cần dữ liệu tag hay link phân trang, bỏ chúng là mất dữ liệu.

Trang được chọn để thử

Lab dùng quotes.toscrape.com, một trang công khai được dựng riêng để tập scraping. Trang gốc có 10 câu trích dẫn, mỗi câu kèm tác giả, link giới thiệu tác giả và ba tới bốn tag. Trang có thanh bên Top Ten tags, link Login và nút Next để sang trang sau.

Trang có hai phiên bản. Bản / là HTML tĩnh, nội dung có sẵn trong mã nguồn. Bản /js/ chứa dữ liệu trong một biến JavaScript và chỉ hiện câu trích dẫn sau khi script chạy.

Quyền với trang đích

Reader tải trang thay anh em, nhưng trách nhiệm với việc tải vẫn thuộc người gọi. Trang đích có điều khoản, có robots.txt, có giới hạn của riêng nó. Dùng Reader không biến một trang không được phép thu thập thành trang được phép.

Lab chỉ gọi trang tập scraping, khoảng mười lần, nghỉ bốn giây giữa các lần. Bài robots.txt khi crawl website bàn chuyện kiểm quyền trước khi tải.

Dữ liệu đi qua bên thứ ba

Khi gọi Reader, URL và nội dung trang đi qua máy chủ của Jina. Với trang công khai, điều này thường không thành vấn đề. Với trang nội bộ, trang cần đăng nhập hay URL chứa token, đó là rò rỉ dữ liệu.

Đừng gửi URL có tham số bí mật qua Reader. Đừng gửi cookie hay header xác thực của trang đích qua Reader nếu chưa đọc chính sách xử lý dữ liệu của Jina.

Ranh giới với embeddings và search

Jina có nhiều dịch vụ: Reader để đọc trang, Search để tìm kiếm, Embeddings để biến văn bản thành vector, Reranker để xếp hạng. Bài này chỉ bàn Reader. Nhầm Reader với Embeddings là chuyện hay gặp vì cùng thương hiệu.

Reader trả văn bản. Embeddings nhận văn bản và trả vector. Hai bước thường nối nhau trong pipeline RAG, nhưng là hai API khác nhau với khóa và giới hạn riêng.

Ranh giới với trích nội dung cục bộ

Bài Trafilatura web scraping bàn cách trích nội dung chính ngay trên máy, không qua dịch vụ ngoài. Cách cục bộ không chạy được JavaScript nếu không kèm trình duyệt, nhưng giữ dữ liệu trong nhà và không phụ thuộc hạn mức của ai.

Reader tiện ở chỗ không phải dựng trình duyệt. Đổi lại, anh em phụ thuộc một dịch vụ ngoài và chấp nhận cách nó quyết định nội dung nào là chính.

Ai cần Reader

Người làm prototype RAG cần văn bản sạch từ vài chục URL ngay hôm nay. Người viết công cụ tóm tắt bài báo. Người cần đọc nhanh trang dựng bằng JavaScript mà không muốn cài trình duyệt không giao diện.

Cả ba đều cần biết Reader bỏ gì. Đó là lý do lab so sánh với HTML gốc thay vì chỉ in kết quả.

Jina Reader API: chuyển trang được phép sang nội dung có cấu trúc, kiểm header và định dạng theo tài liệu

Phần này đi qua cách gọi, các header điều khiển đầu ra và kết quả trên hai trang thử.

Gọi cơ bản

r.jina.ai cộng URL

import requests
UA = "ProxyVN-lab/1.0 (lab@example.com)"
r = requests.get("https://r.jina.ai/https://quotes.toscrape.com/",
                 headers={"User-Agent": UA}, timeout=90)
print(r.status_code, r.headers.get("Content-Type"))
print(r.text[:300])

Response có Content-Type text/plain. Nội dung mở đầu bằng ba dòng: Title, URL Source và Markdown Content, rồi tới phần Markdown. Lab nhận 200 sau 1,26 giây, 1.787 byte, so với 11.064 byte của HTML gốc.

Header điều khiển định dạng

Reader nhận một số header để đổi đầu ra. Accept bằng application/json trả JSON thay cho văn bản. X-Return-Format nhận markdown, text, html và vài giá trị khác. X-Retain-Images bằng none bỏ ảnh. X-With-Links-Summary bằng true thêm danh sách link ở cuối.

Lab thử bốn biến thể trên cùng trang tĩnh. Tất cả trả 200. Bản text dài 1.859 byte. Bản không ảnh kèm tóm tắt link dài 3.920 byte vì có thêm danh sách link.

Đầu ra text khác Markdown ở đâu

Bản text dài 1.859 byte, nhỉnh hơn bản Markdown 1.787 byte. Bản text bỏ cú pháp link nhưng giữ chữ của link, và thêm khoảng trắng giữa các khối. Với mô hình ngôn ngữ, hai bản gần tương đương. Với người cần link tác giả, chỉ bản Markdown giữ được URL.

Chọn một định dạng cho cả pipeline và ghi vào cấu hình. Trộn hai định dạng trong cùng một kho làm khó việc chia đoạn và so sánh về sau.

Đầu ra JSON

Với Accept bằng application/json, response có bốn khóa ở gốc: code, status, data và meta. Khối data có title, description, url, content, metadata, external, httpStatus, httpStatusText và usage. Lab nhận title là Quotes to Scrape, url là URL gốc, usage ghi 429 token.

JSON tiện hơn văn bản vì tách sẵn tiêu đề, URL và nội dung, lại có httpStatus của trang đích. Bài khuyên dùng JSON cho mọi job tự động.

Kết quả trên trang tĩnh

Bảng: Kết quả trên trang tĩnh

Phần trên trang gốc	HTML gốc	Reader Markdown
Câu trích dẫn	10	10
Tên tác giả	10	9
Link giới thiệu tác giả	10	10
Tag dưới mỗi câu	30	0
Thanh bên Top Ten tags	10	0
Link Login	Có	Không
Nút Next sang trang sau	Có	Không

Nội dung chính gần đủ, chỉ thiếu một tên tác giả. Mọi thứ Reader coi là phụ đều bị bỏ, kể cả 30 tag mà nhiều người coi là dữ liệu chính của trang này.

Tên tác giả bị mất ở câu đầu

Câu đầu tiên của Albert Einstein ra Markdown là câu trích dẫn, chữ by, rồi ngay sau là link about, không có tên. Chín câu còn lại có đủ tên. Câu thứ ba, cũng của Einstein, có đủ tên. Lab chạy lại và thấy cùng kết quả ở cả bản tĩnh lẫn bản JavaScript.

Lab không biết lý do cụ thể. Có thể bộ trích nội dung coi phần tử đầu tiên khác các phần tử sau. Bài học thực tế: kiểm từng trường trên mỗi bản ghi, không chỉ đếm số bản ghi.

Kết quả trên trang JavaScript

Tải thẳng trang /js/ bằng requests, HTML dài 5.808 byte, có đủ tên ba tác giả trong biến data của script, nhưng không có dấu ngoặc kép mở nào, vì câu trích dẫn chưa được dựng thành HTML. Bộ phân tích HTML thường sẽ không thấy câu nào.

Reader trả 10 câu trích dẫn đủ dấu ngoặc kép sau 2,42 giây, gần gấp đôi thời gian của trang tĩnh. Đây là bằng chứng Reader chạy JavaScript phía máy chủ. Bản JavaScript không có link about, nên Markdown cũng không có. Câu đầu vẫn thiếu tên tác giả.

Chuẩn bị URL, khóa và phiên bản khi dùng Jina Reader API

Phần này gom các quyết định trước khi chạy hàng loạt: khóa, giới hạn, URL và timeout.

Gọi không khóa và hạn mức

Lab gọi không khóa. Header phản hồi có x-ratelimit-limit với giá trị 20, 20;w=60, nghĩa là 20 request trong cửa sổ 60 giây, và x-ratelimit-remaining là 19. Header x-usage-tokens báo số token của đầu ra, ví dụ 429 cho trang tĩnh.

Hạn mức 20 request mỗi phút là con số lab đọc được từ header ngày chạy với IP lab, không phải cam kết. Hạn mức có khóa cao hơn theo tài liệu của Jina. Đọc header thay vì ghi cứng con số vào code.

Khóa API

Khóa gửi qua header Authorization dạng Bearer. Lab gửi một khóa giả và nhận 401 sau 0,76 giây với JSON có name AuthenticationFailedError và status 40102, thông báo khóa không hợp lệ.

Khóa sai không rơi về chế độ không khóa, mà bị từ chối hẳn. Code nên phân biệt lỗi khóa với lỗi trang đích, vì cách xử lý khác nhau. Đọc khóa từ biến môi trường, không ghi vào code.

Viết URL đích

URL đích nối thẳng sau r.jina.ai/. Với URL có dấu hỏi và tham số, nên mã hóa phần URL đích hoặc gửi bằng POST theo tài liệu, để tham số của trang đích không bị hiểu là tham số của Reader.

Lab chỉ dùng URL không có tham số. Khi job có URL phức tạp, thử trên vài URL mẫu trước và so tiêu đề trả về với tiêu đề thật.

Timeout

Reader phải tải trang và chạy JavaScript, nên chậm hơn tải thẳng. Lab đo 0,76 tới 2,42 giây cho trang nhỏ. Trang nặng có thể mất chục giây. Đặt timeout phía client đủ rộng, lab dùng 90 giây.

Tài liệu Reader có header để đặt thời gian chờ phía dịch vụ. Lab không thử header này.

Định danh request

Lab đặt User-Agent ProxyVN-lab/1.0 kèm email giả [email protected] cho request tới Reader. Đây là định danh với Jina, không phải với trang đích. Trang đích nhìn thấy request từ máy chủ của Jina.

Điều này có hệ quả: trang đích không biết anh em là ai. Nếu trang đích có quy định yêu cầu định danh, Reader không đáp ứng được thay anh em.

Môi trường lab

Python 3.12.10, requests 2.34.2, beautifulsoup4 để đếm phần tử trên HTML gốc. Không có SDK riêng nào được cài, vì Reader chỉ là HTTP. Ghi phiên bản vào requirements.txt.

Thu nội dung, mã trạng thái và hạn mức theo đúng nguồn với Jina Reader API

Phần này ghi lại toàn bộ request của lab và các tình huống lỗi.

Bảng request ngày 29/10/2026

Bảng: Bảng request ngày 29/10/2026

Request	Mã	Giây	Byte	Ghi chú
Tải thẳng trang tĩnh	200	không ghi	11.064	10 câu, 30 tag
Tải thẳng trang JS	200	không ghi	5.808	0 câu đã dựng
Reader trang tĩnh, Markdown	200	1,26	1.787	10 câu
Reader trang JS, Markdown	200	2,42	1.194	10 câu
Reader trang tĩnh, JSON	200	0,76	2.098	Có httpStatus
Reader trang tĩnh, text	200	0,83	1.859	10 câu
Reader không ảnh, có tóm tắt link	200	0,96	3.920	Thêm danh sách link
Reader trang đích 404	200	1,96	289	Có dòng Warning
Reader khóa giả	401	0,76	251	AuthenticationFailedError

Mọi request tới Reader trả nhanh dưới 2,5 giây. Không request nào chạm hạn mức.

Trang đích 404 vẫn trả 200

404 nhưng mã 200

Lab gọi Reader với một đường dẫn không tồn tại trên trang thử. Reader trả mã 200, nội dung có Title là 404 Not Found và một dòng Warning nói URL đích trả lỗi 404 Not Found, rồi tới Markdown của trang lỗi.

Với Accept JSON, khối data có httpStatus bằng 404 và title là 404 Not Found, trong khi code ở gốc vẫn là 200. Code chỉ kiểm r.status_code sẽ lưu trang lỗi như một trang bình thường.

Kiểm httpStatus thay cho status_code

Quy tắc cho job tự động: luôn dùng JSON, đọc data.httpStatus, chỉ chấp nhận khi giá trị nằm trong khoảng 200. Với đầu ra văn bản, tìm dòng bắt đầu bằng Warning: Target URL returned error.

r.status_code của Reader chỉ cho biết Reader có xử lý được request không. Nó không cho biết trang đích có tồn tại không.

Hạn mức và 429

Lab không chạm hạn mức. Khi chạm, Reader trả 429 theo tài liệu. Đọc header Retry-After nếu có, chờ, rồi thử lại. Giữ nhịp dưới con số trong x-ratelimit-limit, trừ hao cho các job khác dùng chung IP hoặc chung khóa.

Bài proxy bị lỗi 429 giải thích vì sao đổi IP không phải cách đúng để xử lý 429.

Không có job bất đồng bộ

Reader trả kết quả đồng bộ trong một request. Không có mã job, không có trạng thái chờ. Với hàng nghìn URL, phải tự xếp hàng và tự giới hạn nhịp phía client.

Đi theo phân trang

Trang thử có nút Next dẫn sang trang 2, rồi trang 3, tới trang 10. Reader bỏ nút này khỏi Markdown. Nếu job cần mọi câu trích dẫn của cả website, có hai cách. Tự sinh URL theo khuôn /page/2/, /page/3/, hoặc bật tóm tắt link rồi tìm link có chữ page trong danh sách.

Cách thứ nhất đơn giản nhưng phải biết trước khuôn URL. Cách thứ hai tổng quát hơn nhưng phụ thuộc danh sách link Reader trả có đủ hay không. Với website lạ, tải HTML gốc của trang đầu một lần để hiểu cấu trúc phân trang trước khi quyết định.

Mỗi trang một request

Reader không crawl cả website. Mỗi request chỉ đọc đúng một URL. Mười trang là mười request, tính vào hạn mức như nhau. Với 20 request mỗi phút không khóa, một website một nghìn trang cần gần một giờ.

Tính trước số URL, nhân với thời gian mỗi request và chia cho hạn mức, để biết job mất bao lâu. Nếu quá lâu, cân nhắc khóa có hạn mức cao hơn, hoặc chỉ đưa qua Reader những trang thật sự cần chạy JavaScript.

Đo token thay cho đo byte

Header x-usage-tokens và trường usage trong JSON cho biết số token của đầu ra. Trang tĩnh 429 token, trang JavaScript 251 token vì không có link about. Trang 404 chỉ 28 token.

Với người trả phí theo token, đây là con số cần theo dõi. Ghi vào nhật ký cho từng URL để ước lượng chi phí trước khi chạy hàng loạt.

Đối soát nội dung, giá trị thiếu và xuất xứ với Jina Reader API

Phần này biến bảng so sánh thủ công thành phép kiểm tự động.

Đếm bản ghi trước và sau

Trên HTML gốc, đếm phần tử bản ghi bằng bộ chọn CSS, ví dụ div có class quote. Trên Markdown của Reader, đếm dòng bắt đầu bằng dấu ngoặc kép mở. Hai số phải bằng nhau. Lab có 10 và 10.

Với trang JavaScript, HTML gốc không có phần tử để đếm. Khi đó đếm từ nguồn dữ liệu khác, như biến data trong script, hoặc dùng trình duyệt không giao diện một lần để có đáp án.

Kiểm từng trường

Đếm bản ghi không đủ. Lab có 10 bản ghi nhưng một bản ghi thiếu tác giả. Viết biểu thức tìm dòng có chữ by mà không có tên phía sau. Lab tìm được đúng một dòng ở mỗi phiên bản trang.

Khi một trường quan trọng thiếu ở một tỷ lệ nhỏ bản ghi, quyết định: bỏ bản ghi đó, bổ sung từ HTML gốc, hay chấp nhận. Ghi quyết định vào tài liệu của pipeline.

Phần bị bỏ có chủ ý

Giữ gì, bỏ gì

Tag, thanh bên, Login, Next bị bỏ là hành vi thiết kế của Reader, không phải lỗi. Với RAG, bỏ chúng giúp văn bản gọn. Với người cần tag hay cần đi tiếp sang trang sau, Reader không phải công cụ phù hợp, hoặc phải kết hợp với tải HTML gốc.

Tùy chọn tóm tắt link trả thêm danh sách link ở cuối, giúp lấy lại link Next nếu cần đi theo phân trang. Lab không kiểm chi tiết danh sách này có đủ mọi link không.

Kết hợp Reader với HTML gốc

Một cách làm thực dụng là tải HTML gốc cho mọi trang, rồi chỉ gọi Reader với trang mà HTML gốc không có nội dung đã dựng. Phép thử đơn giản: đếm phần tử bản ghi trong HTML, bằng 0 thì gửi qua Reader.

Với trang thử, bản tĩnh có đủ 10 câu trong HTML nên không cần Reader. Bản JavaScript có 0 câu đã dựng nên gửi qua Reader. Cách này giảm số request tới dịch vụ ngoài, và giữ được tag cùng link phân trang từ HTML gốc ở những trang tĩnh.

Ghi lại phiên bản hành vi

Reader là dịch vụ, không phải thư viện có số phiên bản cố định. Hành vi trích có thể đổi mà anh em không được báo trước. Giữ một bộ URL mẫu có đáp án như trang thử của lab, chạy lại định kỳ và so với kết quả cũ.

Khi số câu, số tác giả hay kích thước đầu ra đổi trên bộ mẫu, đó là tín hiệu Reader đã đổi cách trích. Kiểm lại pipeline trước khi tin vào kết quả của các URL khác.

Giữ xuất xứ

Ghi URL đích, URL Source mà Reader trả, tiêu đề, httpStatus, thời điểm gọi, định dạng đã yêu cầu và số token vào phần đầu tệp Markdown hoặc tệp JSON đi kèm. Reader có thể đổi cách trích theo thời gian. Ghi ngày gọi giúp giải thích khi lần chạy sau cho kết quả khác.

Bài JSON và CSV khi crawl dữ liệu bàn cách tổ chức tệp đi kèm như vậy.

So kích thước để phát hiện bất thường

Trang tĩnh 11.064 byte HTML ra 1.787 byte Markdown, giảm khoảng sáu lần. Trang 404 chỉ còn 289 byte. Đặt ngưỡng: Markdown nhỏ bất thường so với các trang cùng loại là dấu hiệu trang lỗi, trang chặn hoặc trang cần đăng nhập.

Lưu kết quả, giới hạn request và khi nào Jina Reader API cần proxy

Phần cuối bàn chuyện lưu trữ, nhịp gọi và vị trí của proxy khi đã có một dịch vụ đứng giữa.

Lưu JSON làm bản gốc

Lưu nguyên JSON trả về cho từng URL, rồi sinh Markdown từ trường content. Khi muốn đổi cách hậu xử lý, chạy lại từ JSON đã lưu, không gọi lại Reader. Cách này tiết kiệm hạn mức và token.

Cache theo URL

Không gọi Reader hai lần cho cùng URL trong một khoảng thời gian ngắn. Lưu kết quả kèm thời điểm, chỉ gọi lại khi cần làm mới. Với 20 request mỗi phút không khóa, cache là khác biệt giữa job chạy vài phút và job chạy vài giờ.

Nhịp gọi

Lab nghỉ bốn giây giữa các request, tức khoảng 15 request mỗi phút, dưới con số 20 đọc được từ header. Bài rate limit API khi dùng proxy có mẫu bộ đếm theo cửa sổ thời gian.

Proxy của anh em không đổi IP mà trang đích thấy

Khi gọi Reader qua proxy, proxy chỉ đứng giữa máy anh em và máy chủ của Jina. Trang đích vẫn thấy request từ máy chủ của Jina, không thấy IP của proxy. Proxy không thay đổi nội dung Reader lấy được từ trang đích.

Đây là điểm khác với tải trang thẳng. Ai nghĩ dùng proxy Việt Nam với Reader sẽ khiến trang đích trả nội dung cho người Việt Nam sẽ thất vọng, vì trang đích không nhìn thấy proxy đó.

Proxy vẫn có chỗ dùng

Proxy cần khi máy gọi Reader nằm trong mạng nội bộ chỉ được ra Internet qua proxy. Trường hợp thứ hai là tổ chức yêu cầu mọi lưu lượng ra ngoài, kể cả tới dịch vụ AI, đi qua một IP cố định để giám sát và để Jina có thể gắn hạn mức theo IP đó. Cấu hình và mã hóa mật khẩu có ký tự đặc biệt có trong bài định dạng proxy.

Với HTTPS, proxy HTTP chỉ thấy CONNECT tới r.jina.ai cổng 443. URL đích, khóa API và nội dung trả về nằm trong kênh mã hóa. Ở các bài khác cùng cụm, lab đã ghi nhận đúng hành vi này với requests.

Khi nào nên tự tải thay vì qua Reader

Có bốn trường hợp nên tự tải: trang đích cần IP thoát cụ thể, cần đăng nhập, có quy định định danh người gọi, hoặc anh em cần dữ liệu mà Reader bỏ như tag và phân trang. Khi đó dùng requests hay trình duyệt không giao diện, qua proxy của mình nếu cần. Bài Web Scraping proxy là gì phân biệt các vai trò của proxy trong trường hợp đó.

Khi máy chủ của nhóm đặt tại Việt Nam và cần IP thoát ổn định cho cả job gọi Reader lẫn job tự tải, proxy tĩnh dễ quản lý hơn proxy xoay. ProxyVN có proxy dân cư tĩnh, datacenter, 4G và proxy xoay qua HTTP hoặc SOCKS5. Anh em có thể mua proxy Việt Nam tại trang chủ ProxyVN rồi khai báo vào requests theo tham số proxies.

Giới hạn suy luận của bài

Số liệu đến từ khoảng mười request tới Reader ngày 29/10/2026, không khóa, trên hai trang của một website tập scraping. Website thật phức tạp hơn nhiều. Lỗi mất tên tác giả ở câu đầu được ghi nhận lặp lại trong ngày chạy, có thể đã đổi ở thời điểm anh em đọc bài.

Lab không dùng khóa thật, không chạm hạn mức, không thử header thời gian chờ, không thử trang cần đăng nhập, không gọi Reader qua proxy. Hạn mức 20 request mỗi phút là giá trị đọc từ header, không phải cam kết từ tài liệu.

Checklist Jina Reader API

Checklist Jina Reader

• Chỉ gửi URL công khai, không có tham số bí mật.
• Dùng Accept JSON cho job tự động.
• Kiểm data.httpStatus, không chỉ status_code.
• Đếm bản ghi và kiểm từng trường với HTML gốc.
• Biết trước Reader bỏ menu, tag, phân trang.
• Đọc x-ratelimit-limit, giữ nhịp dưới mức đó.
• Lưu JSON gốc, cache theo URL.
• Proxy của mình không đổi IP mà trang đích thấy.

Câu hỏi thường gặp về Jina Reader API

Jina Reader có cần khóa API không?

Lab gọi được không khóa với hạn mức đọc từ header là 20 request mỗi phút. Khóa giả bị từ chối với 401.

Reader có chạy JavaScript không?

Có. Lab thấy trang JavaScript ra đủ 10 câu trích dẫn, trong khi HTML tải thẳng chưa có câu nào được dựng.

Vì sao trang lỗi vẫn ra mã 200?

Mã 200 là của Reader. Mã của trang đích nằm ở data.httpStatus trong JSON, hoặc dòng Warning trong văn bản.

Reader có giữ tag và link phân trang không?

Không, trong lab. Reader bỏ tag, thanh bên, Login và Next. Tùy chọn tóm tắt link thêm danh sách link ở cuối.

Dùng proxy Việt Nam với Reader có lấy được nội dung cho người Việt không?

Không. Trang đích thấy máy chủ của Jina, không thấy proxy của anh em.

Reader khác Jina Embeddings thế nào?

Reader đổi trang web thành văn bản. Embeddings đổi văn bản thành vector. Hai API riêng.

Jina Reader API và những điều cần nhớ

Jina Reader API cho anh em Markdown sạch từ một URL chỉ bằng một request, kể cả trang cần chạy JavaScript. Lab ngày 29/10/2026 lấy đủ 10 câu trích dẫn, nhưng bỏ 30 tag, mất một tên tác giả và trả 200 cho trang 404. Dùng JSON, kiểm httpStatus, đối chiếu từng trường với HTML gốc. Cần IP thoát ổn định cho máy chủ gọi Jina Reader API, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.