GitHub API rate limit exceeded: Vì sao bị chặn và cách xử lý

GitHub API rate limit exceeded là thông báo GitHub trả về khi anh em đã dùng hết số yêu cầu API được phép trong một khoảng thời gian. Lỗi hay gặp khi cài package bằng Homebrew, Composer, chạy CI hoặc chạy script gọi API mà không đăng nhập. Với yêu cầu ẩn danh, hạn mức tính theo địa chỉ IP, nên nhiều người dùng chung IP sẽ hết rất nhanh. Bài này ProxyVN giải thích các loại giới hạn, cách đọc header và cách xử lý đúng quy định của GitHub. Tham khảo dịch vụ tại ProxyVN.

Tổng quan về lỗi GitHub API rate limit exceeded

Trước khi sửa, anh em cần hiểu GitHub giới hạn những gì và vì sao. Biết rõ cơ chế giúp chọn đúng cách xử lý thay vì thử mò.

Thông báo lỗi trông như thế nào

Khi vượt giới hạn, GitHub trả về mã trạng thái 403 hoặc 429 kèm nội dung JSON. Với yêu cầu chưa đăng nhập, thông báo thường có dạng:

{
  "message": "API rate limit exceeded for 203.0.113.10. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)",
  "documentation_url": "https://docs.github.com/rest/overview/resources-in-the-rest-api#rate-limiting"
}

Địa chỉ IP trong thông báo là IP công cộng mà GitHub nhìn thấy. Nếu anh em ở văn phòng, dùng mạng di động hay proxy, đó có thể là IP mà nhiều người khác cũng đang dùng. Câu "Authenticated requests get a higher rate limit" chính là gợi ý sửa lỗi của GitHub.

Những nơi hay gặp thông báo này

Không chỉ người viết code gọi API mới gặp lỗi. Rất nhiều công cụ phổ biến gọi GitHub API ngầm phía sau:

• Homebrew khi tìm kiếm, cập nhật hoặc cài công thức từ GitHub.
• Composer khi tải package PHP lưu trên GitHub.
• Các công cụ cài phiên bản như nvm, asdf, pyenv khi lấy danh sách bản phát hành.
• Workflow GitHub Actions dùng action tải công cụ từ bản phát hành GitHub.
• Script tự viết, công cụ theo dõi repository, bot thống kê.
• Ứng dụng desktop kiểm tra bản cập nhật qua API của GitHub.

Vì vậy, nhiều anh em gặp lỗi mà không hiểu tại sao, vì chưa từng chủ động gọi API lần nào.

Lỗi 403 và 429 khác nhau thế nào

Mã 429 là mã chuẩn cho tình trạng gửi quá nhiều yêu cầu. Theo tài liệu mã trạng thái 429 của MDN, phản hồi này có thể kèm header Retry-After cho biết bao lâu nữa được gửi tiếp. GitHub dùng cả 403 và 429 cho lỗi giới hạn, nên anh em không thể chỉ dựa vào mã trạng thái. Cần đọc thêm header x-ratelimit-remaining và nội dung thông báo để biết đó là lỗi giới hạn hay lỗi quyền truy cập. Lỗi 429 nói chung khi dùng proxy được phân tích trong bài proxy bị lỗi 429.

Các loại giới hạn của GitHub API

60 yêu cầu theo IP và 5.000 với token

GitHub có hai lớp giới hạn: giới hạn chính tính theo giờ, và giới hạn phụ chống lạm dụng trong thời gian ngắn. Các con số dưới đây lấy từ tài liệu giới hạn của REST API.

Giới hạn chính theo giờ

Giới hạn chính phụ thuộc vào cách anh em xác thực. Bảng dưới gom các mức thường gặp:

Bảng: Giới hạn chính theo giờ

Cách gọi API	Hạn mức mỗi giờ	Tính theo
Không đăng nhập	60 yêu cầu	Địa chỉ IP gửi yêu cầu
Token cá nhân của người dùng	5.000 yêu cầu	Tài khoản người dùng
GitHub App thuộc tổ chức Enterprise Cloud	15.000 yêu cầu	Ứng dụng
Token cài đặt GitHub App	Từ 5.000, tối đa 12.500	Lượt cài đặt
GITHUB_TOKEN trong Actions	1.000 yêu cầu	Mỗi repository
Git LFS không đăng nhập	300 yêu cầu mỗi phút	Địa chỉ IP

Khoảng cách giữa 60 và 5.000 là gần 83 lần. Đây là lý do gần như mọi hướng dẫn xử lý lỗi đều bắt đầu bằng việc dùng token. Với token cài đặt GitHub App, hạn mức tăng thêm 50 yêu cầu mỗi giờ cho mỗi repository vượt quá 20, và mỗi người dùng tổ chức vượt quá 20.

Giới hạn phụ chống lạm dụng

Ngay cả khi còn hạn mức giờ, anh em vẫn có thể bị chặn bởi giới hạn phụ. GitHub đặt các giới hạn này để tránh một bên dùng quá nhiều tài nguyên trong thời gian ngắn:

• Không quá 100 yêu cầu đồng thời, tính chung cả REST và GraphQL.
• REST API: không quá 900 điểm mỗi phút. GraphQL: không quá 2.000 điểm mỗi phút.
• Không quá 90 giây thời gian CPU cho mỗi 60 giây thực, trong đó GraphQL tối đa 60 giây.
• Tạo nội dung: khoảng 80 yêu cầu mỗi phút và 500 yêu cầu mỗi giờ.
• Yêu cầu cấp token OAuth: 2.000 mỗi giờ.

Mỗi yêu cầu GET, HEAD, OPTIONS thường tốn 1 điểm. POST, PATCH, PUT, DELETE thường tốn 5 điểm. GitHub ghi rõ các giới hạn này có thể thay đổi mà không báo trước, và không có cách nào kiểm tra trạng thái giới hạn phụ.

Giới hạn của GraphQL API

GraphQL không đếm theo số yêu cầu mà theo điểm. Theo tài liệu giới hạn GraphQL, người dùng có 5.000 điểm mỗi giờ. Điểm của một truy vấn được tính bằng cách cộng số yêu cầu cần cho mỗi kết nối, chia cho 100 rồi làm tròn, tối thiểu là 1 điểm. Một truy vấn cần 5.101 yêu cầu sẽ tốn 51 điểm.

Mỗi kết nối phải có tham số first hoặc last, nhận giá trị từ 1 tới 100. Một lần gọi không được yêu cầu quá 500.000 nút. Anh em có thể hỏi chi phí của truy vấn bằng trường rateLimit:

query {
  viewer { login }
  rateLimit { limit cost remaining used resetAt }
}

GraphQL có lợi khi cần lấy nhiều dữ liệu liên quan trong một lần gọi. Thay vì gọi REST hàng chục lần cho từng repository, một truy vấn GraphQL có thể lấy đủ thông tin chỉ với vài điểm.

Lý do IP dùng chung hết hạn mức GitHub API rate limit nhanh

Nhiều người chung một IP dùng chung hạn mức

Với yêu cầu không đăng nhập, 60 yêu cầu mỗi giờ là của cả địa chỉ IP, không phải của riêng anh em. Nhiều tình huống khiến hàng chục, hàng trăm người cùng chia nhau con số nhỏ này.

Văn phòng và mạng công ty

Mạng văn phòng thường đi ra Internet qua một hoặc vài IP công cộng. Mười lập trình viên cùng chạy brew update, composer install hay chạy thử script vào buổi sáng có thể dùng hết 60 yêu cầu chỉ trong vài phút. Người đến sau sẽ gặp lỗi dù chưa gọi lần nào.

CGNAT của nhà mạng

Nhiều nhà mạng di động và một số nhà mạng cố định dùng CGNAT, tức là cho rất nhiều thuê bao dùng chung một IP công cộng. Cơ chế này được giải thích kỹ trong bài CGNAT là gì. Khi đó, IP mà GitHub nhìn thấy là IP chung của cả nghìn người, và hạn mức ẩn danh gần như luôn trong tình trạng cạn.

Proxy và VPN dùng chung

Proxy share hay VPN miễn phí cho nhiều người dùng chung IP. Nếu có người khác trên cùng IP đang chạy công cụ gọi GitHub API liên tục, anh em sẽ thấy lỗi ngay từ lần gọi đầu tiên. Ưu nhược điểm của việc dùng chung proxy có trong bài có nên dùng chung proxy cho nhiều thiết bị.

Máy chủ CI dùng chung

Dịch vụ CI miễn phí hoặc runner tự dựng trong cùng một mạng cũng chia nhau IP. Các bước tải công cụ từ bản phát hành GitHub mà không truyền token sẽ nhanh chóng chạm giới hạn 60 yêu cầu.

Điểm chung của mọi tình huống trên là yêu cầu ẩn danh. Chỉ cần đăng nhập bằng token, hạn mức chuyển sang tính theo tài khoản, không còn phụ thuộc người khác trên cùng IP.

Cách xử lý lỗi GitHub API rate limit exceeded đúng quy định

Phần này đi qua các cách xử lý mà chính GitHub khuyến nghị. Cách đầu tiên giải quyết được phần lớn trường hợp.

Tạo và dùng token cá nhân

Token cá nhân giúp hạn mức tăng từ 60 lên 5.000 yêu cầu mỗi giờ. Anh em tạo token theo các bước:

• Đăng nhập GitHub, bấm ảnh đại diện ở góc phải, chọn Settings.
• Kéo xuống cuối thanh bên trái, chọn Developer settings.
• Chọn Personal access tokens, chọn Fine-grained tokens.
• Bấm Generate new token, đặt tên, chọn thời hạn hết hạn.
• Ở Repository access, chọn Public repositories nếu chỉ cần đọc dữ liệu công khai.
• Bấm Generate token, sao chép token ngay vì GitHub chỉ hiện một lần.

Token chỉ đọc dữ liệu công khai là đủ cho Homebrew, Composer và phần lớn script thống kê. Không cấp quyền rộng hơn mức cần, và không đưa token vào mã nguồn công khai.

Gắn token vào các công cụ phổ biến

Mỗi công cụ đọc token từ một chỗ khác nhau. Dưới đây là cách gắn cho các công cụ hay gặp lỗi:

# curl: gửi token trong header Authorization
curl -H "Authorization: Bearer ghp_xxxxxxxxxxxx" https://api.github.com/rate_limit
 
# Homebrew: đặt biến môi trường trong ~/.zshrc hoặc ~/.bashrc
export HOMEBREW_GITHUB_API_TOKEN="ghp_xxxxxxxxxxxx"
 
# Composer: lưu token cho github.com ở cấu hình toàn cục
composer config --global github-oauth.github.com ghp_xxxxxxxxxxxx
 
# GitHub CLI: đăng nhập một lần, các lệnh gh dùng token đã lưu
gh auth login
gh api rate_limit

Sau khi gắn, chạy lại lệnh vừa lỗi. Nếu vẫn báo lỗi, kiểm tra token còn hạn không, có dấu cách thừa không, và công cụ có đọc đúng biến môi trường không.

Truyền token trong GitHub Actions

Trong workflow, GitHub tự cấp GITHUB_TOKEN với hạn mức 1.000 yêu cầu mỗi giờ cho mỗi repository. Nhiều action tải công cụ từ bản phát hành GitHub có tham số token, nên truyền vào để tránh gọi ẩn danh:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Goi API co xac thuc
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: gh api repos/${{ github.repository }}/releases/latest --jq .tag_name

Với runner tự dựng trong mạng dùng chung, đây là thay đổi quan trọng nhất. Bước tải công cụ không truyền token sẽ dùng hạn mức 60 yêu cầu của IP chung.

Chờ tới thời điểm đặt lại

Nếu không gấp, cách đơn giản nhất là chờ. Hạn mức chính được đặt lại theo chu kỳ, thời điểm cụ thể nằm trong header x-ratelimit-reset. GitHub yêu cầu không gửi thêm yêu cầu trước thời điểm này khi x-ratelimit-remaining đã về 0.

Đọc header khi gặp GitHub API rate limit exceeded

Đọc header hạn mức và thời điểm reset

Mỗi phản hồi của GitHub API đều kèm bộ header cho biết tình trạng hạn mức. Đọc được các header này, script của anh em có thể tự điều chỉnh tốc độ thay vì chờ tới khi bị chặn.

Ý nghĩa từng header

GitHub trả về năm header về hạn mức:

• x-ratelimit-limit: số yêu cầu tối đa trong một giờ.
• x-ratelimit-remaining: số yêu cầu còn lại trong khung hiện tại.
• x-ratelimit-used: số yêu cầu đã dùng trong khung hiện tại.
• x-ratelimit-reset: thời điểm đặt lại, tính bằng giây theo giờ UTC kể từ năm 1970.
• x-ratelimit-resource: nhóm tài nguyên mà yêu cầu được tính vào, ví dụ core, search, graphql.

GitHub lưu ý các giá trị có thể khác nhau giữa các vùng, nên header là nguồn đáng tin nhất. Anh em không nên viết logic phụ thuộc vào con số còn lại chính xác tới từng đơn vị.

Kiểm tra hạn mức bằng dòng lệnh

Endpoint /rate_limit cho tổng quan mọi nhóm tài nguyên. Gọi endpoint này không tốn hạn mức chính, nhưng vẫn có thể tính vào giới hạn phụ.

# Xem header hạn mức của một yêu cầu bất kỳ
curl -I https://api.github.com/users/octocat
 
# Xem tổng quan hạn mức (không đăng nhập)
curl -s https://api.github.com/rate_limit
 
# Đổi thời điểm reset sang giờ dễ đọc (Linux)
date -d @1761123456
 
# Đổi thời điểm reset sang giờ dễ đọc (macOS)
date -r 1761123456

Kết quả của /rate_limit có nhiều nhóm như core, search, graphql, code_search. Nhóm search có hạn mức riêng thấp hơn nhiều so với core, nên script tìm kiếm thường hết trước.

Quy tắc xử lý khi bị chặn

GitHub đưa ra quy tắc rõ ràng cho việc thử lại khi gặp lỗi giới hạn:

Bảng: Quy tắc xử lý khi bị chặn

Tình huống	Cách xử lý
Có header retry-after	Chờ đúng số giây ghi trong header
x-ratelimit-remaining bằng 0	Chờ tới thời điểm x-ratelimit-reset
Không có hai header trên	Chờ ít nhất một phút
Vẫn lỗi giới hạn phụ sau khi chờ	Tăng thời gian chờ theo cấp số nhân, dừng sau số lần nhất định

GitHub cảnh báo việc tiếp tục gửi yêu cầu trong lúc đang bị giới hạn có thể khiến ứng dụng bị cấm. Đây là lý do script cần tự dừng, không được lặp gọi liên tục.

Ví dụ script Python tôn trọng hạn mức

Đoạn code dưới đây là ví dụ triển khai chung bằng thư viện requests, áp dụng đúng các quy tắc trên. Script dùng token, đọc header và tự chờ khi cần:

import os
import time
import requests
 
TOKEN = os.environ["GITHUB_TOKEN"]
session = requests.Session()
session.headers.update({
    "Authorization": f"Bearer {TOKEN}",
    "Accept": "application/vnd.github+json",
    "X-GitHub-Api-Version": "2022-11-28",
})
 
def github_get(url, max_retries=5):
    wait = 60
    for attempt in range(max_retries):
        r = session.get(url, timeout=30)
        if r.status_code not in (403, 429):
            return r
        retry_after = r.headers.get("retry-after")
        remaining = r.headers.get("x-ratelimit-remaining")
        if retry_after:
            sleep_for = int(retry_after)
        elif remaining == "0":
            sleep_for = max(int(r.headers["x-ratelimit-reset"]) - int(time.time()), 0) + 5
        else:
            sleep_for = wait
            wait *= 2
        print(f"Bi gioi han, cho {sleep_for} giay (lan {attempt + 1})")
        time.sleep(sleep_for)
    raise RuntimeError("Vuot qua so lan thu lai, dung script")
 
r = github_get("https://api.github.com/repos/octocat/Spoon-Knife")
print(r.json()["stargazers_count"], r.headers.get("x-ratelimit-remaining"))

Điểm quan trọng là script dừng hẳn sau số lần thử nhất định. Một script chạy vô hạn khi bị chặn là kiểu hành vi GitHub coi là lạm dụng.

Giảm số yêu cầu để tránh GitHub API rate limit exceeded

Cache bằng ETag, gọi ít mà vẫn đủ dữ liệu

Dùng token giải quyết chuyện hạn mức thấp. Nhưng với script gọi API nhiều, cách bền vững hơn là gọi ít đi. Tài liệu thực hành tốt khi dùng REST API của GitHub đưa ra nhiều cách cụ thể.

Dùng yêu cầu có điều kiện với ETag

Phần lớn endpoint trả về header etag, nhiều endpoint trả thêm last-modified. Lần gọi sau, anh em gửi lại giá trị đó trong header if-none-match. Nếu dữ liệu không đổi, GitHub trả về 304 Not Modified và phản hồi 304 không bị tính vào hạn mức chính, với điều kiện yêu cầu có header Authorization.

# Lần 1: gọi và lưu giá trị etag trong phản hồi
curl --include --header "Authorization: Bearer YOUR-TOKEN" https://api.github.com/repos/octocat/Spoon-Knife/pulls
 
# Lần 2: gửi lại etag, nhận HTTP/2 304 nếu không có gì mới
curl --include --header "Authorization: Bearer YOUR-TOKEN" --header 'if-none-match: "ETAG-VALUE"' https://api.github.com/repos/octocat/Spoon-Knife/pulls

Muốn ETag phát huy tác dụng, mỗi lần hỏi cùng một dữ liệu phải dùng đúng các tham số giống nhau: cỡ trang, số trang, bộ lọc. Đổi tham số sẽ sinh etag khác và mất tác dụng cache.

Dùng webhook thay cho hỏi liên tục

Script kiểm tra repository mỗi phút để xem có pull request mới không là kiểu dùng tốn hạn mức nhất. GitHub khuyên đăng ký webhook để GitHub chủ động gửi sự kiện khi có thay đổi. Nếu bắt buộc phải hỏi định kỳ, hãy hỏi theo lịch cố định, và tôn trọng header x-poll-interval nếu phản hồi có header này.

Gửi yêu cầu tuần tự thay vì đồng thời

Để tránh giới hạn phụ, GitHub khuyên gửi yêu cầu tuần tự qua một hàng đợi, không gửi song song hàng chục luồng. Với số lượng lớn yêu cầu POST, PATCH, PUT, DELETE, nên chờ ít nhất một giây giữa mỗi yêu cầu. Script chạy chậm một chút nhưng không bị chặn sẽ xong việc nhanh hơn script chạy nhanh rồi bị khoá cả tiếng.

Lấy đúng dữ liệu cần và phân trang đúng cách

Thay vì liệt kê toàn bộ pull request rồi tìm trên máy, hãy lọc ngay trong yêu cầu, ví dụ lọc theo nhánh bằng tham số head. Khi phân trang, dùng header link trong phản hồi để biết trang tiếp theo, không tự ghép địa chỉ. Tăng per_page lên 100 cũng giảm đáng kể số yêu cầu cần thiết.

Cân nhắc GraphQL và GitHub App

Khi cần thông tin liên quan từ nhiều đối tượng, một truy vấn GraphQL thường thay được hàng chục yêu cầu REST. Với tự động hoá trong tổ chức, GitHub khuyên dùng GitHub App thay cho token cá nhân, vì hạn mức của App tăng theo số repository và số người dùng.

Xử lý GitHub API rate limit exceeded trong từng công cụ

Mỗi công cụ gặp lỗi theo cách hơi khác, và có chỗ cấu hình riêng. Phần này gom các trường hợp ProxyVN hay được anh em hỏi nhất, kèm cách xử lý cụ thể.

Homebrew trên macOS và Linux

Homebrew gọi GitHub API khi chạy brew search, brew update hoặc khi cài công thức lấy mã nguồn từ bản phát hành GitHub. Thông báo lỗi thường kèm gợi ý tạo token và đặt vào biến HOMEBREW_GITHUB_API_TOKEN. Sau khi thêm dòng export vào tệp cấu hình shell, anh em mở cửa sổ Terminal mới hoặc chạy source ~/.zshrc để biến có hiệu lực. Token chỉ cần quyền đọc dữ liệu công khai, không cần quyền ghi.

Nếu máy dùng chung, đừng đặt token vào tệp cấu hình mà người khác đọc được. Có thể đặt token trong trình quản lý mật khẩu và chỉ nạp vào biến môi trường khi cần.

Composer cho dự án PHP

Composer tải package từ GitHub qua API khi không có bản đóng gói sẵn. Khi hết hạn mức, Composer dừng lại và hỏi token ngay trong cửa sổ dòng lệnh. Anh em có thể dán token vào đó, Composer sẽ lưu vào tệp auth.json toàn cục. Cách khác là dùng lệnh composer config đã nêu ở trên. Với CI, nên truyền token qua biến môi trường COMPOSER_AUTH dạng JSON thay vì lưu tệp.

Go modules và các trình quản lý phiên bản

Go mặc định tải module qua máy chủ proxy.golang.org, nên ít khi chạm giới hạn GitHub API. Nếu anh em đặt GOPROXY=direct hoặc dùng module riêng tư, Go sẽ gọi thẳng GitHub và có thể gặp lỗi. Giữ GOPROXY mặc định cho module công khai là cách đơn giản nhất.

Các trình quản lý phiên bản như nvm, asdf, mise hay công cụ cài Terraform, kubectl thường gọi API để lấy danh sách bản phát hành. Phần lớn đọc biến GITHUB_TOKEN hoặc GH_TOKEN. Đặt một trong hai biến này là đủ để chuyển sang hạn mức có xác thực.

Script và bot tự viết

Với code tự viết, lỗi thường đến từ ba thói quen: không truyền token, gọi song song quá nhiều luồng, và hỏi định kỳ quá dày. Sửa cả ba cùng lúc, kết hợp ETag, gần như không bao giờ gặp lại lỗi. Nếu bot chạy cho cả tổ chức, chuyển sang GitHub App để hạn mức tăng theo quy mô thay vì dùng token cá nhân của một người.

Proxy và GitHub API rate limit exceeded

Nhiều anh em hỏi ProxyVN liệu có nên dùng proxy để xử lý lỗi này không. Câu trả lời cần tách rõ hai mục đích khác nhau.

Không dùng proxy xoay để vượt giới hạn

Đổi IP liên tục để gọi ẩn danh vượt hạn mức 60 yêu cầu là việc đi ngược mục đích của giới hạn, trái điều khoản sử dụng của GitHub, và có thể khiến tài khoản hoặc ứng dụng bị cấm. ProxyVN không hướng dẫn cách làm này. Hạn mức 5.000 yêu cầu khi có token đã đủ cho gần như mọi nhu cầu hợp lệ, và GitHub App cho hạn mức cao hơn nữa khi cần.

Dùng IP riêng để không chia hạn mức với người lạ

Mục đích hợp lý duy nhất của proxy ở đây là tránh dùng chung IP với người không quen. Nếu anh em đang ở sau CGNAT hoặc dùng proxy share, IP có thể đã cạn hạn mức ẩn danh trước khi anh em gọi lần nào. Một IP riêng giúp các yêu cầu ẩn danh hiếm hoi như kiểm tra cập nhật ứng dụng không bị ảnh hưởng bởi người khác. Ngay cả khi đó, dùng token vẫn là cách chính.

Cấu hình proxy cho Git và công cụ dòng lệnh

Khi mạng công ty bắt buộc đi qua proxy, Git và các công cụ dòng lệnh cần được cấu hình đúng. Cách cấu hình proxy cho clone và push có trong bài git proxy, còn npm, yarn, pnpm có bài npm proxy. Với curl và phần lớn công cụ, biến môi trường HTTPS_PROXY là đủ:

export HTTPS_PROXY="http://user:pass@203.0.113.10:8080" curl -H "Authorization: Bearer ghp_xxxxxxxxxxxx" https://api.github.com/rate_limit

Nếu cần IP Việt Nam riêng, ổn định cho máy chủ CI hoặc máy làm việc, anh em có thể mua proxy tốc độ cao tại ProxyVN với proxy datacenter dùng riêng, hỗ trợ HTTP và SOCKS5.

Lỗi giới hạn của GitHub không phải bức tường để vượt qua, mà là lời nhắc đăng nhập và gọi API thông minh hơn.

ProxyVN đảm bảo mạng kết nối luôn ổn định, proxy không bị mất kết nối, và hỗ trợ 24/24 khi anh em cấu hình proxy cho công cụ phát triển.

Phân biệt GitHub API rate limit exceeded với các lỗi tương tự

Một số lỗi khác cũng trả về mã 403 hoặc 429 từ GitHub. Nhầm lẫn giữa chúng khiến anh em xử lý sai hướng.

Lỗi 403 do thiếu quyền

Mã 403 kèm thông báo "Resource not accessible by integration" hoặc "Must have admin rights" là lỗi quyền, không phải lỗi giới hạn. Header x-ratelimit-remaining lúc này vẫn còn lớn hơn 0. Cách sửa là cấp thêm quyền cho token hoặc GitHub App.

Lỗi 401 do token sai

Mã 401 với "Bad credentials" nghĩa là token sai, hết hạn hoặc bị thu hồi. GitHub tự động thu hồi token bị lộ trong repository công khai. Tạo token mới và kiểm tra lại cách công cụ đọc token.

Lỗi 429 của giới hạn phụ

Khi nội dung có chữ "secondary rate limit", anh em đang gửi quá nhanh hoặc quá nhiều yêu cầu đồng thời, dù còn hạn mức giờ. Giải pháp là giảm tốc độ, gửi tuần tự và chờ theo header retry-after, không phải tạo thêm token.

Lỗi giới hạn khi clone qua HTTPS

Clone hay pull qua HTTPS không bị tính vào hạn mức REST API. Tuy nhiên Git LFS có giới hạn riêng: 300 yêu cầu mỗi phút khi không đăng nhập và 3.000 khi có đăng nhập. Repository có nhiều tệp LFS có thể chạm giới hạn này khi nhiều máy cùng clone.

Kết luận

GitHub API rate limit exceeded xảy ra khi hạn mức gọi API đã hết, thường do yêu cầu ẩn danh tính theo IP dùng chung. Cách xử lý đúng là dùng token, đọc header x-ratelimit, chờ đúng thời điểm đặt lại, dùng ETag và webhook để gọi ít hơn. Cần IP riêng ổn định cho máy làm việc, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam để tránh chia hạn mức khi gặp GitHub API rate limit exceeded.