Proxy Bluesky: API, giao diện web và hạn mức AT Protocol

Proxy Bluesky chỉ có ý nghĩa khi anh em hiểu Bluesky chạy trên AT Protocol, nơi giao diện web, API công khai và máy chủ dữ liệu là ba thứ tách rời. Hạn mức tính theo IP ở chỗ này, theo tài khoản ở chỗ khác. Bài này, ProxyVN giải thích từng tầng, viết script đọc dữ liệu công khai qua proxy và chỉ ra khi nào đổi IP không giải quyết được gì.

Proxy Bluesky và cấu trúc AT Protocol

Bluesky không phải một máy chủ duy nhất như các mạng xã hội quen thuộc. Nó là một ứng dụng xây trên AT Protocol, giao thức phân tán do chính đội Bluesky phát triển. Hiểu cấu trúc này là điều kiện để biết proxy đặt ở đâu thì có tác dụng.

Ba thành phần chính

Tổng quan AT Protocol mô tả ba vai trò. Máy chủ dữ liệu cá nhân, gọi là PDS, lưu tài khoản và bài viết của người dùng. Relay gom dữ liệu từ nhiều PDS thành một luồng chung. AppView đọc luồng đó, dựng chỉ mục và trả về các thứ như hồ sơ, bảng tin, luồng bài theo tác giả.

• PDS: nơi anh em đăng nhập, nơi lưu bản ghi bài viết, lượt thích, follow.
• Relay: gom và phát lại thay đổi từ các PDS.
• AppView: phục vụ dữ liệu đã tổng hợp cho ứng dụng đọc.

Mỗi thành phần có địa chỉ riêng và hạn mức riêng. Một request đọc hồ sơ công khai đi tới AppView, còn request đăng nhập đi tới PDS.

Giao diện web chỉ là một ứng dụng khách

Trang bsky.app mà người dùng mở trên trình duyệt là một ứng dụng khách. Nó gọi tới PDS của tài khoản để đăng nhập và ghi dữ liệu, gọi tới AppView để đọc bảng tin. Các ứng dụng khách khác cũng gọi tới đúng những API đó.

Vì vậy, gắn proxy cho trình duyệt nghĩa là mọi request của bsky.app tới PDS và AppView đều đi qua proxy. Script tự viết gọi trực tiếp API cũng có thể đi qua proxy, nhưng anh em kiểm soát được từng request đi đâu.

Proxy chạm tới tầng nào

Proxy nằm giữa máy của anh em và máy chủ đích. Nó không đổi được tài khoản, không đổi được dữ liệu trong PDS và không đổi được cách AppView xếp hạng nội dung. Tác dụng duy nhất là đổi IP mà máy chủ nhìn thấy.

Như vậy, proxy Bluesky chỉ ảnh hưởng tới những gì phụ thuộc vào IP: hạn mức tính theo IP và việc máy chủ thấy request đến từ đâu. Mọi thứ tính theo tài khoản nằm ngoài tầm của proxy.

Phân biệt API và giao diện web khi dùng proxy Bluesky

Người mới thường dùng giao diện web để thử rồi chuyển sang script khi cần tự động hoá. Hai cách này đi qua cùng hạ tầng nhưng khác nhau về xác thực, hạn mức và rủi ro. Phần này đặt chúng cạnh nhau.

Ba cách truy cập Bluesky

API công khai không cần đăng nhập

Một số endpoint đọc dữ liệu công khai không cần xác thực. Tài liệu Bluesky cho biết các endpoint này có thể gọi thẳng tới AppView công khai tại public.api.bsky.app. Ví dụ đọc hồ sơ qua app.bsky.actor.getProfile và đọc bài của một tác giả qua app.bsky.feed.getAuthorFeed.

Đây là đường phù hợp nhất để đọc dữ liệu công khai. Không cần tài khoản, không có rủi ro khoá tài khoản, chỉ cần tôn trọng hạn mức theo IP. Proxy ở đây giúp tách IP chạy script khỏi IP văn phòng.

API cần đăng nhập

Các thao tác ghi như đăng bài, thích, follow và một số thao tác đọc riêng tư cần phiên đăng nhập. Script gọi com.atproto.server.createSession tới PDS, nhận về token truy cập và token làm mới. Các request sau mang token này trong header.

Với tài khoản lưu trên hạ tầng của Bluesky, PDS thường được gọi qua bsky.social. Tài khoản tự host PDS thì gọi tới địa chỉ PDS riêng. Script nên đọc địa chỉ này từ cấu hình thay vì ghi cứng.

Giao diện web với proxy trong trình duyệt

Mở bsky.app trong một hồ sơ trình duyệt có proxy là cách đơn giản để kiểm tra trải nghiệm người dùng từ một mạng khác. Đăng nhập, đọc bảng tin, mở hồ sơ, mọi thứ đi qua proxy. Không cần code.

Nhược điểm là khó đo. Trình duyệt gửi hàng chục request mỗi lần chuyển trang, khó biết request nào chạm hạn mức. Với nhu cầu đo đạc hay thu thập, API cho kết quả rõ ràng hơn.

Bảng so sánh ba cách truy cập

Bảng dưới gom ba cách truy cập và đặc điểm chính. Cột cuối cho biết proxy có tác dụng gì ở từng cách.

Bảng: Bảng so sánh ba cách truy cập

Cách truy cập	Máy chủ gọi tới	Cần đăng nhập	Hạn mức chính	Tác dụng của proxy
API công khai	public.api.bsky.app	Không	Theo IP	Tách IP script, phân tải
API có đăng nhập	PDS của tài khoản	Có	Theo IP và theo tài khoản	Chỉ ảnh hưởng phần theo IP
Giao diện bsky.app	PDS và AppView	Có	Theo IP và theo tài khoản	Kiểm tra trải nghiệm từ mạng khác

Nhìn bảng, anh em thấy càng gần dữ liệu công khai, proxy càng có vai trò rõ. Càng gần tài khoản, hạn mức theo tài khoản càng quyết định và proxy càng ít ý nghĩa.

Hạn mức của Bluesky mà proxy Bluesky cần tôn trọng

Bluesky công bố hạn mức trong trang Rate Limits của tài liệu. Đọc kỹ trang này trước khi viết bất kỳ script nào. Phần dưới tóm tắt các con số chính tính tới ngày viết bài.

Hạn mức theo IP

Mọi request tới các endpoint của PDS bị giới hạn theo IP ở mức 3.000 request mỗi 5 phút. Đây là hạn mức chung, áp dụng cho tổng số request từ một địa chỉ. Script đọc dữ liệu hợp lý hiếm khi chạm mức này nếu có khoảng nghỉ giữa các lần gọi.

Hạn mức theo IP là chỗ duy nhất proxy có ảnh hưởng. Nhưng chia một script ra nhiều IP để vượt hạn mức đi ngược tinh thần của hạn mức. ProxyVN khuyên anh em giữ một IP cố định cho mỗi công cụ và điều chỉnh tốc độ cho phù hợp.

Hạn mức đăng nhập theo tài khoản

Endpoint createSession bị giới hạn theo tài khoản: 30 lần mỗi 5 phút và 300 lần mỗi ngày. Hạn mức này không phụ thuộc IP. Script đăng nhập lại mỗi lần chạy sẽ chạm mức 300 mỗi ngày rất nhanh nếu chạy dày.

Đổi proxy không cứu được script chạm hạn mức createSession. Cách đúng là lưu token sau lần đăng nhập đầu và dùng token làm mới khi token truy cập hết hạn. Phần code bên dưới làm đúng việc này.

Hạn mức ghi dữ liệu

Các thao tác ghi bản ghi được tính theo hệ điểm. Tạo một bản ghi tốn 3 điểm, cập nhật tốn 2, xoá tốn 1. Mỗi tài khoản có 5.000 điểm mỗi giờ và 35.000 điểm mỗi ngày.

• Tạo bài viết, lượt thích, follow: 3 điểm mỗi lần.
• Cập nhật hồ sơ: 2 điểm.
• Xoá bản ghi: 1 điểm.
• Tối đa khoảng 1.666 lần tạo mỗi giờ nếu chỉ tạo.

Con số này đủ rộng cho người dùng và công cụ hợp lệ. Nếu script của anh em cần nhiều hơn, đó là dấu hiệu nó đang làm việc mà nền tảng không muốn, như tự động follow hàng loạt.

Tính nhanh nhu cầu request trước khi chạy

Trước khi viết vòng lặp, anh em nên ước lượng số request cần dùng. Ví dụ theo dõi 50 tài khoản công khai, mỗi tài khoản đọc 2 trang bài mỗi giờ, tổng là 100 request mỗi giờ. Con số này rất xa hạn mức 3.000 request mỗi 5 phút theo IP.

Ước lượng giúp anh em thấy ngay mình có cần nhiều IP hay không. Phần lớn nhu cầu hợp lệ chỉ cần một IP cố định với khoảng nghỉ một giây giữa các lần gọi. Nếu ước lượng ra con số sát hạn mức, đó là lúc nên cân nhắc firehose thay vì gọi API lặp lại.

Ghi phép tính này vào tài liệu của công cụ. Khi có người đề xuất tăng số tài khoản theo dõi, nhóm chỉ cần cập nhật con số và so lại với hạn mức. Quyết định sẽ dựa trên số liệu thay vì cảm giác.

Các con số có thể thay đổi

Hạn mức có thể được điều chỉnh theo thời gian. Trước khi chạy script quy mô lớn, mở lại trang tài liệu để kiểm tra. Script cũng nên đọc header phản hồi và xử lý mã 429 thay vì giả định một con số cố định.

Chuẩn bị môi trường cho proxy Bluesky

Môi trường thử gồm Python, thư viện Requests và một proxy cố định. Với phần đọc công khai, không cần tài khoản Bluesky. Với phần có đăng nhập, anh em cần một tài khoản của mình và một mật khẩu ứng dụng.

Cài thư viện và đặt biến

Lệnh dưới là ví dụ trên PowerShell. Requests kèm hỗ trợ SOCKS để dùng được cả proxy HTTP lẫn SOCKS5.

python -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install "requests[socks]"
$env:BSKY_PROXY = 'http://USERNAME:PASSWORD@HOST:PORT'
$env:BSKY_HANDLE = 'tenban.bsky.social'
$env:BSKY_APP_PASSWORD = 'xxxx-xxxx-xxxx-xxxx'

Giá trị trên là mẫu. Hai biến BSKY_HANDLE và BSKY_APP_PASSWORD chỉ cần cho phần có đăng nhập.

Tạo mật khẩu ứng dụng

Bluesky cho phép tạo mật khẩu ứng dụng riêng cho script, thay vì dùng mật khẩu chính. Mục này nằm trong phần cài đặt bảo mật của ứng dụng, tên menu có thể đổi theo phiên bản giao diện. Mỗi script nên có một mật khẩu ứng dụng với tên rõ ràng.

Mật khẩu ứng dụng có thể thu hồi riêng lẻ. Khi một máy chạy script bị nghi lộ, anh em xoá đúng mật khẩu đó mà không phải đổi mật khẩu tài khoản. Đây là thói quen bảo mật cơ bản cho mọi công cụ tự động.

Tài khoản trên PDS tự host

AT Protocol cho phép người dùng chạy PDS riêng hoặc dùng PDS của bên thứ ba. Khi đó, script có đăng nhập phải gọi tới địa chỉ PDS đó thay vì bsky.social. Biến BSKY_PDS trong code ở phần sau dành cho trường hợp này.

Hạn mức của PDS tự host do người vận hành PDS quyết định, có thể khác với con số trong tài liệu Bluesky. AppView công khai thì vẫn dùng chung cho mọi người. Nếu anh em vận hành PDS riêng, ghi lại hạn mức đã cấu hình để script không vượt.

Proxy với PDS tự host cũng cần tính thêm một điều: PDS có thể giới hạn IP được phép đăng nhập theo cấu hình riêng. Kiểm tra cấu hình này trước khi gắn proxy cho script, tránh mất thời gian dò lỗi kết nối.

Chọn loại proxy

Đọc dữ liệu công khai từ AppView không cần IP dân cư. Proxy datacenter cố định là đủ, miễn ổn định và có độ trễ thấp. Với phiên đăng nhập của người quản lý tài khoản, một IP cố định giúp lịch sử truy cập dễ đọc.

• Script đọc công khai: proxy datacenter Việt Nam hoặc US, một IP cố định.
• Script có đăng nhập: một IP cố định riêng, không dùng chung với script đọc.
• Không cần proxy xoay cho bất kỳ việc nào trong bài.

Nếu anh em định mở rộng sang thu thập dữ liệu công khai trên nhiều nền tảng để nghe ngóng thảo luận, bài social listening trên blog ProxyVN trình bày quy trình và giới hạn đạo đức của việc đó.

Ví dụ tối thiểu đọc dữ liệu công khai qua proxy Bluesky

Ví dụ đầu tiên chỉ đọc dữ liệu công khai, không đăng nhập. Script lấy hồ sơ một tài khoản và tải các bài gần nhất của tài khoản đó theo từng trang bằng cursor. Đây là ví dụ triển khai do ProxyVN viết theo tài liệu Bluesky, đã kiểm tra cú pháp Python nhưng chưa chạy qua proxy thương mại cụ thể.

Đọc bài theo trang bằng cursor

Code đọc hồ sơ và bài viết

Hàm xrpc gọi một phương thức bất kỳ trên AppView công khai. Hàm author_feed lặp qua các trang bằng cursor, dừng khi hết trang hoặc đạt số bài mong muốn. Mỗi lần gọi in ra các header hạn mức nếu máy chủ trả về.

import os
import time
import requests
 
APPVIEW = "https://public.api.bsky.app/xrpc/"
PROXY = os.environ.get("BSKY_PROXY")
 
def session():
    s = requests.Session()
    if PROXY:
        s.proxies.update({"http": PROXY, "https": PROXY})
    s.headers.update({"User-Agent": "bsky-public-reader/0.1"})
    return s
 
def xrpc(s, method, **params):
    r = s.get(APPVIEW + method, params=params, timeout=(10, 30))
    limits = {k: v for k, v in r.headers.items() if k.lower().startswith("ratelimit")}
    if r.status_code == 429:
        return 429, limits, {}
    r.raise_for_status()
    return r.status_code, limits, r.json()
 
def author_feed(s, actor, want=200, delay=1.0):
    posts, cursor = [], None
    while len(posts) < want:
        params = {"actor": actor, "limit": 100}
        if cursor:
            params["cursor"] = cursor
        code, limits, data = xrpc(s, "app.bsky.feed.getAuthorFeed", **params)
        if code == 429:
            print("rate limited", limits)
            break
        for item in data.get("feed", []):
            p = item["post"]
            posts.append({"uri": p["uri"], "time": p["record"].get("createdAt"),
                          "text": p["record"].get("text", "")[:80],
                          "likes": p.get("likeCount", 0)})
        cursor = data.get("cursor")
        print("page", len(posts), limits)
        if not cursor:
            break
        time.sleep(delay)
    return posts
 
if __name__ == "__main__":
    s = session()
    code, limits, prof = xrpc(s, "app.bsky.actor.getProfile", actor="bsky.app")
    print(prof.get("handle"), prof.get("followersCount"), prof.get("postsCount"))
    for p in author_feed(s, "bsky.app", want=150)[:5]:
        print(p["time"], p["likes"], p["text"])

Trong ví dụ, actor là bsky.app, tài khoản chính thức của Bluesky. Anh em thay bằng handle của tài khoản mình quản lý hoặc tài khoản công khai cần theo dõi cho mục đích hợp lệ.

Cách chạy và đầu ra mong đợi

Chạy python bsky_public.py. Dòng đầu in handle, số người theo dõi và số bài. Các dòng tiếp theo in tiến độ từng trang và cuối cùng là năm bài mới nhất.

bsky.app 3215000 790
page 100 {'ratelimit-limit': '3000', 'ratelimit-remaining': '2998', ...}
page 150 {'ratelimit-limit': '3000', 'ratelimit-remaining': '2997', ...}
2026-10-21T15:02:11.000Z 1820 We're rolling out ...
...

Đầu ra trên là minh hoạ, con số và header thực tế có thể khác hoặc không xuất hiện. Nếu máy chủ không trả header hạn mức, script vẫn chạy và chỉ in dict rỗng. Khi đó anh em dựa vào mã 429 để biết đã chạm hạn mức.

Kiểm tra dữ liệu đầu ra

Mỗi bài có uri dạng at://, đây là định danh duy nhất trong AT Protocol. Dùng uri để loại trùng khi chạy lại script. Trường createdAt do ứng dụng khách ghi khi tạo bài, có thể khác thời điểm AppView nhận được bài.

• Có uri trùng giữa hai trang: lưu danh sách uri đã thấy và bỏ qua bản lặp.
• Văn bản rỗng: bài chỉ có ảnh hoặc là bài repost, kiểm tra trường reason.
• likeCount thay đổi giữa hai lần chạy: số liệu sống, ghi kèm thời điểm đọc.

Lưu kết quả và lên lịch chạy

Kết quả đọc nên lưu ra tệp có cấu trúc, ví dụ JSON Lines với mỗi dòng một bài. Mỗi dòng gồm uri, thời điểm tạo, thời điểm đọc, văn bản rút gọn và các con số tương tác. Thời điểm đọc giúp phân tích sự thay đổi của lượt thích theo thời gian.

Lịch chạy nên giãn theo nhu cầu thật. Theo dõi tài khoản của tổ chức thì vài giờ một lần là đủ. Chạy mỗi phút chỉ tăng tải lên máy chủ và tốn băng thông proxy mà không thêm thông tin đáng kể.

Khi chạy theo lịch, dùng cursor của lần trước không phải lúc nào cũng hợp lý, vì bài mới nằm ở đầu luồng. Cách đơn giản là đọc trang đầu, dừng khi gặp uri đã có trong dữ liệu. Script vừa nhanh vừa không đọc lại dữ liệu cũ.

Phiên đăng nhập qua proxy Bluesky không chạm hạn mức

Ví dụ thứ hai dành cho script cần đăng nhập vào tài khoản của anh em. Điểm mấu chốt là đăng nhập một lần, lưu token, rồi làm mới token khi cần. Cách này giữ số lần gọi createSession ở mức thấp nhất.

Code lưu và làm mới phiên

Hàm get_session đọc token từ tệp nếu có. Nếu chưa có, nó gọi createSession và lưu kết quả. Khi một request trả về lỗi token hết hạn, hàm refresh gọi com.atproto.server.refreshSession bằng token làm mới.

import os
import json
import requests
 
PDS = os.environ.get("BSKY_PDS", "https://bsky.social") + "/xrpc/"
TOKEN_FILE = "bsky_session.json"
 
def proxied():
    s = requests.Session()
    proxy = os.environ.get("BSKY_PROXY")
    if proxy:
        s.proxies.update({"http": proxy, "https": proxy})
    return s
 
def create(s):
    r = s.post(PDS + "com.atproto.server.createSession", timeout=(10, 30), json={
        "identifier": os.environ["BSKY_HANDLE"],
        "password": os.environ["BSKY_APP_PASSWORD"]})
    r.raise_for_status()
    return r.json()
 
def refresh(s, sess):
    r = s.post(PDS + "com.atproto.server.refreshSession", timeout=(10, 30),
               headers={"Authorization": f"Bearer {sess['refreshJwt']}"})
    r.raise_for_status()
    return r.json()
 
def save(sess):
    with open(TOKEN_FILE, "w", encoding="utf-8") as f:
        json.dump({k: sess[k] for k in ("did", "handle", "accessJwt", "refreshJwt")}, f)
 
def get_session(s):
    if os.path.exists(TOKEN_FILE):
        with open(TOKEN_FILE, encoding="utf-8") as f:
            return json.load(f)
    sess = create(s)
    save(sess)
    return sess
 
def authed_get(s, sess, method, **params):
    h = {"Authorization": f"Bearer {sess['accessJwt']}"}
    r = s.get(PDS + method, params=params, headers=h, timeout=(10, 30))
    if r.status_code in (400, 401) and "ExpiredToken" in r.text:
        sess.update(refresh(s, sess))
        save(sess)
        h["Authorization"] = f"Bearer {sess['accessJwt']}"
        r = s.get(PDS + method, params=params, headers=h, timeout=(10, 30))
    return r

Đây là ví dụ triển khai, đã kiểm tra cú pháp. Tệp bsky_session.json chứa token có quyền trên tài khoản, cần đặt quyền đọc hạn chế và không đưa vào kho mã nguồn. Tên lỗi ExpiredToken lấy theo cách PDS thường báo, anh em in nội dung lỗi thực tế để điều chỉnh điều kiện nếu cần.

Vì sao cách này quan trọng với proxy

Nhiều script mẫu trên mạng gọi createSession ở đầu mỗi lần chạy. Chạy mỗi 5 phút là 288 lần mỗi ngày, sát hạn mức 300. Thêm vài lần chạy tay là vượt. Lúc đó người viết script thường nghĩ do IP và đi đổi proxy.

Đổi proxy không giúp gì vì hạn mức này tính theo tài khoản. Lưu token và làm mới đúng cách giảm số lần createSession xuống còn vài lần mỗi ngày, bất kể chạy qua proxy nào.

Lưu token thay vì đăng nhập lại

Xử lý lỗi khi chạy proxy Bluesky

Lỗi khi dùng proxy với Bluesky có ba nguồn: proxy, hạn mức và dữ liệu. Tách đúng nguồn giúp anh em không đổi proxy khi lỗi nằm ở token, và không đổi token khi lỗi nằm ở proxy.

Lỗi ở tầng proxy

Mã 407 cho thấy sai thông tin xác thực proxy. ProxyError hoặc ConnectTimeout cho thấy request chưa ra khỏi proxy. SSLError thường do nhầm tiền tố giao thức giữa http và socks5h.

• 407: kiểm tra user, mật khẩu, mã hoá ký tự đặc biệt.
• ConnectTimeout: kiểm tra proxy còn hoạt động, cổng đúng, IP máy đã được cho phép.
• SSLError: kiểm tra tiền tố giao thức và proxy có hỗ trợ CONNECT.

Bài requests.exceptions.ProxyError trên blog ProxyVN đi sâu vào nhóm lỗi này trong Python.

Lỗi 429 và cách phản ứng

Mã 429 nghĩa là đã chạm một hạn mức. Đọc nội dung lỗi và header để biết hạn mức nào. Nếu là hạn mức theo IP, giảm tốc độ và chờ hết cửa sổ 5 phút. Nếu là createSession, xem lại cách lưu token.

Gặp 429 trên Bluesky, câu hỏi đầu tiên là hạn mức đó tính theo IP hay theo tài khoản, rồi mới nghĩ tới chuyện có liên quan proxy hay không.

Bài mua proxy bị lỗi 429 trên blog ProxyVN bàn thêm về cách đọc mã lỗi này trong bối cảnh dùng proxy nói chung.

Lỗi dữ liệu

Handle không tồn tại trả lỗi từ AppView với thông báo rõ ràng. Tài khoản bị tạm ngưng hoặc đã xoá cũng trả lỗi riêng. Script nên ghi lại handle gây lỗi và bỏ qua, không thử lại liên tục.

Bài bị xoá sau khi anh em đã lưu vẫn nằm trong dữ liệu của anh em. Nếu mục đích là phân tích, cân nhắc tôn trọng việc người dùng xoá bài bằng cách định kỳ kiểm tra lại và loại bỏ. Đây là chuẩn mực tốt khi làm việc với dữ liệu mạng xã hội.

Dùng proxy Bluesky đúng ranh giới

Dữ liệu trên Bluesky công khai theo thiết kế, nhưng công khai không có nghĩa dùng sao cũng được. Phần này nói về những ranh giới anh em cần giữ khi chạy công cụ.

Đọc công khai có trách nhiệm

Đọc dữ liệu công khai để theo dõi tài khoản của mình, nghiên cứu thảo luận về thương hiệu hay lưu trữ bài viết của tổ chức là các mục đích hợp lý. Giữ tốc độ vừa phải, lưu ít dữ liệu nhất cần thiết và tôn trọng việc người dùng xoá bài. Điều khoản dịch vụ của Bluesky là văn bản anh em cần đọc trước khi chạy công cụ ở quy mô lớn.

Với nhu cầu theo dõi luồng dữ liệu thời gian thực, AT Protocol có firehose và dịch vụ Jetstream. Đây là đường chính thức để nhận thay đổi liên tục, hiệu quả hơn nhiều so với gọi getAuthorFeed lặp lại. Tìm hiểu tài liệu của chúng trước khi viết vòng lặp gọi API dày đặc.

Không tự động hoá tương tác giả

Bài này không hướng dẫn tạo nhiều tài khoản, tự động follow, thích hay trả lời hàng loạt. Dù hệ điểm cho phép hàng nghìn thao tác mỗi giờ, dùng hết hạn mức để tạo tương tác giả là hành vi spam. Proxy không làm hành vi đó trở nên hợp lệ.

• Mỗi công cụ gắn với một tài khoản có thật và có người chịu trách nhiệm.
• Thao tác ghi tự động chỉ dùng cho nội dung của chính tài khoản đó.
• Không chia một công cụ ra nhiều IP để né hạn mức.

Dữ liệu cá nhân trong bài viết công khai

Bài viết công khai vẫn có thể chứa thông tin cá nhân như tên thật, nơi làm việc hay ảnh. Khi lưu dữ liệu để phân tích, chỉ giữ những trường thật sự cần. Phân tích chủ đề thảo luận thường không cần lưu ảnh đại diện hay tên hiển thị.

Nếu dữ liệu được chia sẻ trong nhóm, ẩn danh hoá handle trước khi đưa vào báo cáo. Báo cáo về xu hướng không cần biết ai nói, chỉ cần biết nói gì và bao nhiêu người nói. Đây là cách làm an toàn cho cả người dùng lẫn tổ chức của anh em.

Quản lý tài khoản của tổ chức

Tổ chức có tài khoản Bluesky chính thức nên cấp mật khẩu ứng dụng riêng cho từng công cụ và từng người. Proxy cố định cho mỗi công cụ giúp đối chiếu khi có hoạt động bất thường. Ghi lại ai chịu trách nhiệm công cụ nào trong tài liệu nội bộ.

Checklist trước khi chạy proxy Bluesky thật

Trước khi đưa script vào chạy định kỳ, anh em rà lại danh sách dưới đây. Mỗi mục gắn với một lỗi hoặc rủi ro đã nêu.

Về kiến trúc

Script đọc công khai gọi tới public.api.bsky.app, không đăng nhập. Script có đăng nhập gọi tới đúng PDS của tài khoản. Hai loại script dùng proxy cố định riêng.

• Đã xác định từng request đi tới AppView hay PDS.
• Đã đọc trang Rate Limits mới nhất.
• Đã cân nhắc firehose hoặc Jetstream nếu cần dữ liệu thời gian thực.

Về phiên và bảo mật

Dùng mật khẩu ứng dụng, không dùng mật khẩu chính. Token được lưu và làm mới, createSession chỉ gọi khi cần. Tệp token có quyền đọc hạn chế, không nằm trong kho mã nguồn.

• Mỗi script một mật khẩu ứng dụng, có tên rõ ràng.
• Biết cách thu hồi mật khẩu ứng dụng khi cần.
• Log không chứa mật khẩu, token hay thông tin proxy.

Về vận hành

Có khoảng nghỉ giữa các request. Có xử lý 429 phân biệt hạn mức IP và tài khoản. Có cơ chế loại trùng theo uri và kiểm tra bài đã xoá.

Khi cần mua proxy cố định cho script đọc dữ liệu công khai hoặc phiên quản lý tài khoản, anh em có thể xem gói datacenter Việt Nam, datacenter US và dân cư tĩnh trên trang chủ ProxyVN, thử một IP với script mẫu ở trên trước khi chạy định kỳ.

Câu hỏi thường gặp về proxy Bluesky

Một vài thắc mắc ngắn hay gặp khi anh em bắt đầu với Bluesky và proxy. Chi tiết nằm ở các phần trên.

Checklist proxy Bluesky

Đọc dữ liệu Bluesky có cần tài khoản không

Với dữ liệu công khai như hồ sơ và bài viết của một tác giả, không cần. Gọi trực tiếp tới public.api.bsky.app là đủ. Chỉ các thao tác ghi và một số thao tác đọc riêng tư mới cần đăng nhập.

Đổi proxy có tăng hạn mức đăng nhập không

Không. Hạn mức createSession tính theo tài khoản: 30 lần mỗi 5 phút và 300 lần mỗi ngày. Lưu token và làm mới đúng cách mới là giải pháp.

Có nên dùng proxy xoay cho Bluesky không

Với các mục đích trong bài, IP cố định phù hợp hơn. Proxy xoay làm log khó đọc và dễ bị hiểu là cố né hạn mức theo IP. Nếu cần nhiều dữ liệu, firehose hoặc Jetstream là đường chính thức hiệu quả hơn.

Proxy Bluesky có tác dụng rõ nhất ở tầng đọc dữ liệu công khai, nơi hạn mức tính theo IP. Ở tầng tài khoản, lưu token đúng cách quan trọng hơn mọi lựa chọn proxy. Cần tư vấn chọn IP cố định, anh em nhắn Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam để được hỗ trợ proxy Bluesky.