Cách cấu hình Proxy Ubuntu 26.04 hiệu năng cao

Hệ thống đang hoạt động ổn định, bỗng dưng API của đối tác trả về hàng loạt lỗi 429 Too Many Requests. Bạn vội vàng scale up số lượng container/pod lên gấp đôi, nhưng kết quả là dải IP nội bộ bị block hoàn toàn. Đau đầu hơn, cụm server proxy bạn tự build lăn ra ngừng hoạt động do lỗi OOM (Out of Memory) chỉ sau một đợt traffic spike vài phút. Đó là lúc bạn nhận ra: Kiến trúc mạng của hệ thống đang bị nghẽn cổ chai (bottleneck) trầm trọng từ tận tầng thấp nhất của hệ điều hành.

Đây là thách thức cực kỳ quen thuộc với các kỹ sư Backend Developer, DevOps và SysAdmin khi phải quản lý hàng triệu outbound/inbound requests mỗi ngày. Thay vì tiêu tốn vào các dịch vụ Enterprise Proxy đắt đỏ, giải pháp tối ưu nhất là tự build một hạ tầng proxy tự chủ. Sự xuất hiện của Ubuntu 26.04 LTS (Resolute Raccoon) mang đến một nền tảng xử lý network I/O có thể nói là mạnh nhất từ trước tới nay.

Nhưng làm sao để ép phần mềm chạy mượt mà, tối ưu tối đa hiệu năng CPU mà không làm tràn bộ nhớ? Việc cấu hình proxy ubuntu 26.04 liệu có ẩn chứa những rủi ro tiềm ẩn nào từ các tài liệu cũ? Hãy cùng mổ xẻ chi tiết từng dòng lệnh, đối chiếu với tài liệu gốc của Kernel để build một hệ thống xử lý request hiệu suất cao đích thực!

Kiến trúc triển khai HAProxy kết hợp Squid Proxy trên nền tảng Linux Kernel 7.0.

Tại sao Ubuntu 26.04 (Resolute Raccoon) là nền tảng tối thượng cho Proxy?

Hệ điều hành Ubuntu 26.04 LTS không chỉ là một bản cập nhật phần mềm thông thường. Tên mã “Resolute Raccoon” mang đến sự lột xác về kiến trúc hạ tầng. Việc tích hợp Sched_ext và PREEMPT_RT giải quyết trực tiếp bài toán độ trễ mạng (network latency) và xử lý I/O.

Sched_ext: Lập lịch tùy chỉnh bằng eBPF tại user-space

Trước đây, bộ lập lịch mặc định (như CFS hoặc EEVDF) thường gây ra độ trễ cao cho các dịch vụ mạng do liên tục chuyển ngữ cảnh (context switch) giữa các luồng đang chờ I/O.

Với Sched_ext trên Ubuntu 26.04, các kỹ sư có thể đưa logic lập lịch từ kernel ra user-space bằng eBPF.

• Tối ưu hóa độ trễ đuôi (Tail Latency): Thay vì ngắt luồng liên tục, các công ty như Meta đã tạo ra bộ lập lịch tuỳ chỉnh (tên mã BOLT) ưu tiên giữ các luồng I/O hoạt động lâu hơn trên CPU. Kết quả: giảm 35% chi phí chuyển ngữ cảnh, cải thiện độ trễ P99 từ 3-6%.
• Xử lý mạng viễn thông: Với các tải cực kỳ nhạy cảm với độ trễ (Telco Workloads), bộ lập lịch LAVD (Latency-criticality Aware Virtual Deadline) thông qua Sched_ext có thể giảm thời gian phản hồi vượt trội hơn EEVDF tới 81% khi hệ thống chịu tải cao.

PREEMPT_RT: Giải quyết triệt để độ trễ mạng TCP/IP

PREEMPT_RT (Nhân thời gian thực) nay đã được tích hợp mặc định. Mục tiêu của nó không phải là tăng thông lượng tối đa, mà là tính dự đoán (predictability) và giới hạn độ trễ (bounded latency).

• Khóa có thể ngủ (Sleeping locks): Bằng cách biến các khóa quay (spinlocks) thành rt_mutex và áp dụng cơ chế kế thừa độ ưu tiên, các tác vụ mạng TCP/IP sẽ không bị chặn vô lý bởi các tiến trình cấp thấp, giúp độ trễ duy trì ổn định dưới ngưỡng 200 micro giây.
• Ứng phó 5G / Cloud RAN: Trong mạng 5G, xử lý gói tin băng tần cơ sở đòi hỏi độ trễ mili-giây. PREEMPT_RT giúp đạt thời gian phản hồi gói tin ~900 micro giây, loại bỏ điểm nghẽn hệ điều hành.

Lưu ý về sự đánh đổi: Bật PREEMPT_RT có thể làm giảm thông lượng tổng thể do tăng chuyển ngữ cảnh. Tuy nhiên, sự kết hợp với Sched_ext chính là chìa khóa để bù đắp lại thông lượng đã mất này.

Chuẩn bị hạ tầng & vượt qua rủi ro quản trị Ubuntu 26.04

Để bắt đầu việc cấu hình proxy ubuntu 26.04, bạn cần một nền tảng an toàn. Nếu chọn sai cấu hình hoặc dùng thói quen cũ, bạn sẽ gặp lỗi ngay từ bước cài đặt.

Để đảm bảo máy chủ được bảo mật từ đầu, bạn nên tham khảo 7 bước hardening bảo mật nâng cao chống rà soát IP trái phép cho VPS Linux nhằm xây dựng lớp giáp bảo vệ đầu tiên.

Cấu hình phần cứng: Server vs Desktop

Đừng nhầm lẫn cấu hình yêu cầu. Theo tài liệu Release Notes:

• Ubuntu Server 26.04 LTS: Yêu cầu tối thiểu chỉ 1.5 GB RAM và 4 GB lưu trữ. Đây là phiên bản bạn PHẢI dùng để cài Proxy.
• Ubuntu Desktop 26.04 LTS: Cần tối thiểu 6 GB RAM và 25 GB lưu trữ. Nếu máy tính có thông số thấp hơn (vd: 2GB RAM), tài liệu khuyên dùng Xubuntu hoặc Lubuntu.

Những thay đổi cốt lõi dễ gây lỗi (APT & Sudo)

Rất nhiều script cài đặt Proxy từ thời 22.04 sẽ không thể hoạt động trên 26.04 vì những thay đổi sau:

• Hệ thống APT 3.1: Đã chuyển từ thư viện GnuTLS sang sử dụng OpenSSL cho các kết nối TLS. Đặc biệt, lệnh apt-key đã bị loại bỏ hoàn toàn. Khi thêm repo của Nginx hay HAProxy, bạn bắt buộc phải dùng định dạng keyring mới lưu tại /usr/share/keyrings/.
• Lệnh quản trị sudo: Bản triển khai viết bằng Rust (sudo-rs) nay là mặc định. Lệnh sudo truyền thống bị đổi tên thành sudo.ws. Ngoài ra, gói sudo-ldap bị xóa bỏ (thay bằng LDAP qua PAM).

Tinh chỉnh Kernel (Sysctl), trái tim của hạ tầng Proxy

Hệ điều hành mặc định được thiết kế để lướt web, không phải để hứng hàng triệu packet. Việc tuning Sysctl là điều kiện tiên quyết.

Bảo vệ đường ống kết nối (Connection Pipeline) từ Layer 2 đến Layer 4

Khi một gói tin đi từ Card mạng (NIC) lên ứng dụng proxy, nó phải qua 3 hàng đợi (queue) chính. Bạn cần tăng đồng thời cả 3 tham số sau:

1. net.core.netdev_max_backlog (Layer 2/3): Hàng đợi chứa các gói tin thô từ NIC. Nếu hàng đợi này nhỏ, gói tin (kể cả TCP SYN) sẽ bị drop ngay lập tức trước khi tới tầng TCP.
2. net.ipv4.tcp_max_syn_backlog (Layer 4): SYN queue chứa các yêu cầu kết nối bán mở (SYN_RECV) đang chờ quá trình bắt tay 3 bước (3-way handshake). Giúp chống chịu SYN flood cực tốt.
3. net.core.somaxconn: Accept queue chứa các kết nối đã hoàn tất (ESTABLISHED) chờ proxy gọi hàm accept().

Tác dụng: Tăng cả 3 tham số này tạo ra một bộ đệm an toàn khổng lồ, giúp máy chủ hấp thụ lưu lượng bùng nổ (burst tolerance), ngăn chặn rớt gói tin và duy trì thông lượng kể cả khi ứng dụng proxy tạm thời bị nghẽn CPU.

Tối ưu hóa 3 lớp hàng đợi TCP (netdev, SYN, Accept) giúp máy chủ chống rớt gói tin và chống SYN Flood hiệu quả.

Sự thật về tcp_tw_recycle và cách xử lý TIME_WAIT an toàn

Hàng ngàn bài hướng dẫn cũ khuyên bạn set net.ipv4.tcp_tw_recycle = 1 để dọn dẹp các kết nối TIME_WAIT. Tuy nhiên, tính năng này đã bị gỡ bỏ hoàn toàn khỏi nhân Linux do ảnh hưởng nghiêm trọng của nó đối với các client đứng sau NAT (Network Address Translation).

Tại sao tcp_tw_recycle gây nguy hiểm?

Tham số này phụ thuộc vào TCP Timestamps. Khi nhiều thiết bị dùng chung một IP Public (quán cafe, công ty), mỗi thiết bị tạo ra một timestamp giả ngẫu nhiên. Nếu Client 2 kết nối ngay sau Client 1 nhưng có timestamp nhỏ hơn, máy chủ sẽ lầm tưởng đó là gói tin cũ bị kẹt và tự động drop gói SYN. Hậu quả là client bị rớt kết nối ngẫu nhiên.

Cách xử lý an toàn:

• net.ipv4.tcp_tw_reuse = 1: Cho phép kernel tái sử dụng an toàn các socket TIME_WAIT cho các kết nối hướng ra ngoài (outbound).
• net.ipv4.tcp_fin_timeout = 10: Giảm thời gian chờ ở trạng thái FIN_WAIT_2 (mặc định 60s) xuống 10s để giải phóng tài nguyên.
• net.ipv4.tcp_max_tw_buckets: Đặt giới hạn trần cho số lượng socket TIME_WAIT. Nếu vượt ngưỡng, kernel lập tức hủy socket cũ nhất để chống cạn kiệt cổng (port exhaustion).

Cơ chế NAT làm sai lệch TCP Timestamps, dẫn đến việc rớt kết nối ngẫu nhiên đối với các client dùng chung IP Public.

BBR và lầm tưởng về cơ chế hàng đợi qdisc

Google BBR là thuật toán chống tắc nghẽn vô địch. Nhiều người cho rằng phải cài fq hoặc fq_codel thì BBR mới chạy. Sự thật là từ kernel 4.20, TCP stack đã hỗ trợ điều tốc gói tin (TCP-level pacing) nội bộ. BBR hiện tại có thể hoạt động với bất kỳ qdisc nào.

Tuy nhiên, cơ chế pacing nội bộ tiêu tốn nhiều tài nguyên hệ thống hơn. Do đó, đối với máy chủ proxy chịu tải cao, việc kết hợp BBR với fq hoặc fq_codel vẫn là cấu hình được Google khuyến nghị khẩn thiết.

Tối ưu HAProxy 3.2 LTS: Connection Pooling & quản lý RAM

HAProxy đứng ở Front-end đóng vai trò Load Balancer. Đừng giải quyết sự cố quá tải bằng cách tăng thiếu kiểm soát giới hạn kết nối (maxconn), vì nó sẽ tiêu hao toàn bộ RAM của bạn.

Để hiểu sâu hơn về mô hình này, bạn có thể tìm hiểu cách cấu hình Reverse Proxy Nginx nâng cao nhằm bảo vệ Web API nội bộ khỏi DDoS và bot rác, qua đó thấy rõ sự tương đồng và cách phối hợp giữa các loại proxy.

Kỹ thuật Connection Pooling (tái sử dụng kết nối)

Tái sử dụng kết nối có sẵn tốn ít chu kỳ CPU hơn nhiều so với việc liên tục TCP Handshake với máy chủ backend.

• http-reuse always: Buộc HAProxy luôn tận dụng các kết nối hiện có. Hiệu quả giảm CPU rất kinh ngạc, nhưng cần đảm bảo backend không ngắt kết nối quá nhanh.
• Cân bằng với pool-fd-ratio: Duy trì kết nối nhàn rỗi giúp giảm tải CPU nhưng tốn File Descriptors (FD). Nếu CPU đang cao, hãy ép HAProxy giữ lại FD bằng cách cấu hình: tune.pool-high-fd-ratio 90 và tune.pool-low-fd-ratio 80. Nếu hệ thống cạn kiệt FD, hãy hạ xuống mức cân bằng 50 / 40.

Bài toán RAM tối quan trọng với tune.bufsize

Kích thước buffer (tune.bufsize) ảnh hưởng tuyến tính đến RAM. Một kết nối TCP/HTTP qua HAProxy cần 2 buffers (nhận và gửi).

Với mặc định 16384 bytes (16 kB), mỗi kết nối tiêu tốn khoảng 33 kB RAM (bao gồm 32 kB cho 2 buffer + dữ liệu trạng thái). Nếu bạn tăng bufsize để chứa header/cookie lớn, RAM sẽ bị bào mòn nhanh chóng, gây rủi ro OOM (Out of Memory).

Cảnh báo cực kỳ nghiêm trọng:

Tuyệt đối KHÔNG ĐƯỢC GIẢM tune.bufsize xuống dưới 16 kB để tiết kiệm RAM. Lý do:

1. Phá vỡ giao thức HTTP/2 (bắt buộc buffer tối thiểu 16384 bytes).
2. Nếu HTTP Request/Response lớn hơn khoảng trống buffer, HAProxy sẽ từ chối và ném ra lỗi HTTP 400 (Bad Request) hoặc HTTP 502 (Bad Gateway).
3. Trang hiển thị thống kê (statistics page) nội bộ của HAProxy sẽ bị hỏng.

Thiết lập Squid Proxy: Phá vỡ rào cản hệ điều hành

Nếu Squid đứng sau làm Cache hoặc Forward Proxy, nó sẽ tiêu thụ RAM theo một cách rất khác. Việc cài đặt Squid thất bại 90% là do cấu hình cấp thấp của hệ điều hành.

Cấu trúc tiêu thụ RAM của Squid: Việc bỏ quên lượng RAM dành cho Metadata là nguyên nhân chính gây lỗi OOM (Hết bộ nhớ).

Nếu hệ thống yêu cầu độ ổn định cao, bạn có thể triển khai kiến trúc High Availability Proxy với cơ chế setup tự động failover để đạt uptime 99.9%.

Khắc phục giới hạn Data Segment Size

Squid cần lượng RAM rất lớn. Tuy nhiên, hệ điều hành (như Linux/BSD) áp đặt giới hạn cứng về Kích thước phân đoạn dữ liệu (Data Segment Size). Nếu Squid xin thêm RAM mà bị chặn lại, nó sẽ văng ra lỗi chí mạng: FATAL: xcalloc: Unable to allocate 4096 blocks of 1 bytes!.

Cách khắc phục:

Bạn buộc phải can thiệp vào các giới hạn tài nguyên của hệ điều hành.

• Trên hệ thống PAM (Linux), bạn cần tăng giới hạn bộ nhớ trong /etc/security/limits.conf và sử dụng lệnh ulimit để chỉ định mức giới hạn cứng (hard limit) trước khi start Squid.
• (Với các hệ thống BSD, phải chỉnh tham số datasize trong /etc/login.conf và chạy cap_mkdb). Đặc biệt trên kiến trúc 32-bit (phân chia 2GB tiến trình / 2GB kernel), việc nắm rõ giới hạn cấp phát bộ nhớ là sống còn.

Rủi ro BOUNCE_BUFFERS làm cạn kiệt bộ nhớ

Một kỹ thuật tối ưu ít người biết đến liên quan đến DMA (Direct Memory Access). Một số phần cứng NIC cũ không thể truy cập trực tiếp vùng bộ nhớ cao (high memory).

Để giao tiếp, hệ điều hành tạo ra một vùng đệm tạm ở vùng bộ nhớ thấp (low memory) gọi là Bounce Buffer. CPU phải làm thêm nhiệm vụ copy dữ liệu từ vùng đệm này lên high memory.

Với cường độ I/O khổng lồ của Squid, quá trình sao chép kép này tạo ra hàng loạt bounce buffer, dẫn đến Cạn kiệt bộ nhớ thấp (Low Memory Starvation). RAM hệ thống còn trống nhiều nhưng Squid vẫn bị treo hoặc sập do cạn low memory.

Giải pháp: Nếu máy chủ có RAM > 256MB, hãy đảm bảo hệ điều hành/kernel của bạn đã vô hiệu hóa BOUNCE_BUFFERS, cho phép thiết bị DMA đẩy thẳng dữ liệu lên high memory.

Giám sát, chẩn đoán & benchmark hệ thống

Sau khi đã hoàn tất các bước cấu hình proxy ubuntu 26.04, bạn không thể đưa ngay lên Production nếu chưa kiểm chứng số liệu. Bạn cần thiết lập hệ thống giám sát traffic Proxy Server theo thời gian thực để luôn nắm bắt được trạng thái hoạt động của máy chủ.

ss -tin: Thay thế netstat

Lệnh netstat đã lỗi thời. Hãy dùng ss -tin (Socket Statistics). Lệnh này có lợi thế vượt trội vì cung cấp số liệu nội bộ TCP (TCP internals) như: thời gian trễ vòng (RTT), độ biến thiên, và kích thước cửa sổ tắc nghẽn (CWND) theo thời gian thực mà không gây tốn tài nguyên (no-overhead), loại bỏ việc phải bắt gói tin (packet capture) phức tạp.

Đặc biệt chú ý chỉ số retrans (retransmissions). Nếu retrans khác 0 (non-zero), điều này trực tiếp báo hiệu mạng của bạn đang bị mất gói tin (packet loss). Kết hợp với CWND nhỏ, chắc chắn hệ thống đang bị nghẽn (congestion).

Benchmark chuẩn xác bằng wrk2

Công cụ load test wrk2 được khuyên dùng thay vì wrk gốc vì nó giải quyết triệt để vấn đề bỏ sót có phối hợp (Coordinated Omission).

Các tool cũ đo độ trễ từ lúc gửi đến lúc nhận. Nếu server bị quá tải, công cụ test sẽ tự động chậm lại để chờ phản hồi, vô tình che giấu đi khoảng thời gian server bị treo.

wrk2 giải quyết bằng cách:

• Ép hệ thống chạy ở Thông lượng không đổi (Constant Throughput) qua cờ --rate.
• Tính độ trễ từ thời điểm mà yêu cầu lẽ ra phải được gửi đi theo kế hoạch, phản ánh chính xác vấn đề của client.
• Sử dụng HdrHistograms để ghi lại dữ liệu lossless, giúp báo cáo độ trễ cực kỳ chính xác ở các bách phân vị cao như 99.9999%. Phép đo này lôi ra ánh sáng mọi điểm nghẽn đột biến (outliers) hiếm hoi nhất mà các tool trung bình bỏ sót hoàn toàn.

Coordinated Omission che giấu độ trễ thực sự. Công cụ wrk2 giúp phơi bày các điểm nghẽn đột biến (Spikes) ở bách phân vị cao.

Câu hỏi thường gặp (FAQ)

1. Cấu hình tối thiểu để chạy Ubuntu 26.04 LTS làm Proxy Server là bao nhiêu?

Bản Server cần tối thiểu 1.5GB RAM, 4GB Storage. (Bản Desktop cần 6GB RAM). Tuy nhiên, trên môi trường Production, nên bắt đầu từ 4 vCPU và 8GB RAM.

2. Những thay đổi quản trị cốt lõi nào trên Ubuntu 26.04 dễ gây lỗi cài đặt?

Lệnh apt-key đã bị loại bỏ hoàn toàn (phải dùng OpenSSL keyring). Lệnh sudo mặc định được viết lại bằng Rust (sudo-rs).

3. Kernel 7.0 với Sched_ext & PREEMPT_RT giúp ích gì cho Proxy?

Sched_ext (eBPF) giúp giảm context-switch thừa; PREEMPT_RT khóa độ trễ mạng dưới ngưỡng 200 micro-giây. Kết quả: Proxy phản hồi mượt mà hơn.

4. Tại sao tuyệt đối không dùng tcp_tw_recycle để dọn socket nữa?

Nó làm rớt gói tin ngẫu nhiên của các client dùng chung mạng NAT do sai lệch timestamp. Hãy dùng tcp_tw_reuse = 1 để thay thế.

5. BBR v3 có bắt buộc phải đi kèm qdisc fq không?

Không bắt buộc. BBR chạy được với mọi qdisc nhờ pacing nội bộ. Nhưng dùng fq vẫn là Best Practice cho server tải cao.

6. Tăng netdev_max_backlog và tcp_max_syn_backlog khác nhau thế nào?

netdev hứng gói tin thô từ NIC (Layer 2/3); syn_backlog hứng kết nối chờ bắt tay (Layer 4). Tăng cả hai giúp hệ thống chống rớt gói và chặn SYN Flood hiệu quả.

7. Cách giảm CPU cho HAProxy thay vì tăng maxconn thiếu kiểm soát?

Bật Connection Pooling bằng lệnh http-reuse always và set tune.pool-high-fd-ratio 90 để tái sử dụng kết nối cũ.

8. Có nên giảm tune.bufsize của HAProxy để tiết kiệm RAM không?

Mỗi kết nối tốn ~33KB RAM. TUYỆT ĐỐI KHÔNG giảm bufsize xuống dưới 16KB, nếu không sẽ làm vỡ HTTP/2 và gây lỗi 400/502 Bad Gateway.

9. Tại sao Squid báo lỗi thiếu RAM (xcalloc) dù Server còn trống nhiều RAM?

Do hệ điều hành giới hạn mức RAM cấp cho mỗi tiến trình (Data Segment Size). Bạn phải tăng nó trong /etc/security/limits.conf hoặc cấu hình ulimit.

10. Vô hiệu hóa BOUNCE_BUFFERS có tác dụng gì cho Squid?

Giúp thiết bị DMA đẩy thẳng dữ liệu lên vùng RAM cao, tránh việc hệ điều hành copy dữ liệu qua lại làm cạn kiệt vùng RAM thấp (Low Memory Starvation).

11. Lệnh ss -tin tốt hơn netstat ở điểm nào?

Xem được độ trễ RTT và CWND realtime mà không hao tốn tài nguyên. Nếu chỉ số retrans > 0, mạng của bạn chắc chắn đang rớt gói (packet loss).

12. Tại sao phải benchmark proxy bằng wrk2?

Nó khắc phục lỗi bỏ sót có phối hợp (tool cũ sẽ tự chậm lại khi server lag). wrk2 duy trì thông lượng đều, giúp đo chính xác điểm nghẽn ở bách phân vị 99.9999%.

Kết luận

Việc xây dựng và cấu hình proxy ubuntu 26.04 thực sự là nghệ thuật tìm kiếm sự cân bằng. Đó là sự giao thoa giữa eBPF Sched_ext đột phá, sự kỷ luật khi tinh chỉnh 3 lớp TCP Queues, kỹ thuật Connection Pooling của HAProxy và sự khắt khe khi gỡ bỏ rào cản Data Segment/Bounce Buffers cho Squid.

Nắm được những nguyên lý cốt lõi này, bạn không chỉ tối ưu được chi phí server mà còn tự tin đối mặt với bất kỳ sự cố nghẽn cổ chai nào trong môi trường Production. Hãy áp dụng ngay và đo lường sự khác biệt với wrk2 nhé! Chúc các bạn cấu hình thành công!

Tài liệu tham khảo

• Ubuntu 26.04 LTS release notes – Ubuntu release notes
• How Squid uses memory | Squid Web Cache wiki
• Performance tuning HAProxy Enterprise | HAProxy Enterprise
• bbr/Documentation/bbr-faq.md at master · google/bbr · GitHub