Ngiêm cấm sử đụng PROXY và VPS vào mục đích trái pháp luật bạn sẽ phải chịu toàn bộ trách nhiệm trước pháp luật khi sử dụng dịch vụ của chúng tôi tks!
Nginx forward proxy CONNECT: module ngoài và cách kiểm thử

Nginx forward proxy CONNECT: module ngoài, đúng nhánh, kiểm thử

Chuyên viên Kỹ thuật ProxyVN 08-28-2026 Đang tính... phút đọc

Nginx forward proxy CONNECT nghĩa là dùng nginx làm proxy cho client bên trong, nhận lệnh CONNECT rồi mở đường hầm tới website bên ngoài. Nginx gốc không làm được việc này, anh em phải vá và biên dịch module ngoài đúng nhánh. ProxyVN đối chiếu tài liệu module và nêu rõ chỗ chưa chạy thử.

Nginx forward proxy CONNECT là gì và khác reverse proxy ở đâu

Nginx nổi tiếng nhờ vai trò reverse proxy: đứng trước máy chủ ứng dụng, nhận yêu cầu từ bên ngoài và chuyển vào trong. Bài cấu hình nginx làm reverse proxy đã nói kỹ cách làm đó với proxy_pass, header và cân bằng tải.

Bài này đi hướng ngược lại. Client nằm bên trong mạng, nginx đứng giữa và đưa client ra Internet. Đó là forward proxy. Anh em có thể đọc khác biệt khái niệm ở bài forward proxy và reverse proxy.

Vì sao nginx gốc không làm forward proxy HTTPS

Khi trình duyệt dùng proxy để vào website HTTPS, nó gửi một lệnh CONNECT có dạng CONNECT ten-mien:443. Proxy mở kết nối TCP tới đích, báo 200, rồi chuyển byte qua lại mà không đọc. Nginx gốc không có mã xử lý phương thức CONNECT, vì nó được thiết kế quanh proxy_pass tới đích cố định hoặc theo upstream.

Chính tài liệu của module mô tả mục tiêu: bổ sung hỗ trợ phương thức CONNECT, vốn chủ yếu dùng để chuyển yêu cầu SSL qua proxy. Module tên là ngx_http_proxy_connect_module, do cộng đồng viết, không thuộc nginx chính thức.

Phạm vi của bài

Bài chỉ nói về lưu lượng đi qua CONNECT. Anh em sẽ biết cách chọn bản nginx phù hợp, vá, cấu hình, giới hạn cổng và host, và cách thử. Bài không dạy lọc nội dung bên trong HTTPS, vì module nói rõ không đọc được dữ liệu trong đường hầm.

Nginx forward proxy CONNECT cũng không phải dịch vụ cấp địa chỉ IP. Website đích thấy IP của máy chạy nginx. Muốn IP khác, anh em phải đặt nginx trên máy có IP đó hoặc dùng dịch vụ proxy riêng.

Cấu hình forward proxy khác reverse proxy ở những dòng nào

Nhiều người đã quen cấu hình reverse proxy sẽ thử áp nguyên tư duy đó. Bảng dưới giúp anh em nhận ra các khác biệt.

Bảng: Cấu hình forward proxy khác reverse proxy ở những dòng nào

Tiêu chí

Reverse proxy (bài đã đăng)

Forward proxy CONNECT (bài này)

Đích

Cố định trong cấu hình, qua proxy_pass hoặc upstream

Do client chọn trong dòng CONNECT

Phân giải tên

Thường không cần resolver, tên ghi sẵn

Bắt buộc có resolver

Module

Có sẵn trong nginx

Module ngoài và patch

Ai là client

Trình duyệt người dùng cuối

Máy bên trong mạng nội bộ

Rủi ro chính

Lộ ứng dụng phía sau

Mở ống TCP ra Internet

Kiểm soát đích

Do cấu hình quyết định

Phải tự dựng allowlist

Điểm mấu chốt là đích. Ở reverse proxy, anh em quyết định proxy nói chuyện với ai, nên bề mặt tấn công nhỏ. Ở forward proxy, client quyết định, nên mọi sự an toàn nằm ở các luật anh em đặt trước.

Dựng nginx forward proxy CONNECT bằng module ngoài trên đúng nhánh tương thích

Đây là phần dễ sai nhất. Module có bảng chọn patch theo phiên bản nginx, và mỗi bản nginx cần đúng một patch.

Đọc bảng tương thích trước khi tải bất cứ thứ gì

Mình đọc README của kho ngx_http_proxy_connect_module trên GitHub. Với nginx 1.25.0 đến 1.26.x và 1.27.1, README chọn patch proxy_connect_rewrite_102101.patch. Với 1.21.1 đến 1.24.0, cũng là patch đó. Các nhánh cũ hơn dùng patch khác, ví dụ 1.19.x đến 1.21.0 dùng proxy_connect_rewrite_1018.patch.

Mỗi tên patch có hai biến thể. Bản có chữ rewrite bật lại pha REWRITE cho yêu cầu CONNECT, nên các lệnh như set hay if dùng được. Bản không có chữ rewrite tắt pha này theo mặc định. Với bài này mình cần if và biến, nên dùng bản rewrite.

Danh sách phiên bản đã kiểm chứng của module ghi các nhánh 1.26.2 và 1.27.1 là mới nhất, cùng nhiều nhánh cũ như 1.24.0, 1.22.1 và 1.20.2.

Phiên bản nginx hiện hành đã vượt ngoài bảng

Bảng patch theo nhánh nginx và khoảng trống ở bản mới

Bảng patch theo nhánh nginx và khoảng trống ở bản mới

Trang tải của nginx ngày 27/10/2026 liệt kê bản stable là 1.30.6 và bản mainline là 1.31.8. Bảng tương thích của module dừng ở 1.26.x và 1.27.1. Lịch sử commit cho thấy lần cập nhật hỗ trợ gần nhất của module ngày 18/08/2024, ghi nhận hỗ trợ nginx 1.26.2 và 1.27.1.

Nghĩa là nginx 1.30 và 1.31 chưa nằm trong bảng của README. Mình không biết patch 102101 có áp được lên mã nguồn 1.30 hay không, và mình không thử. Đây là rủi ro lớn nhất khi chọn bản.

Ba lựa chọn thực tế

  • Dùng nhánh 1.26.x có trong bảng, ví dụ 1.26.3 từ trang tải, dù đã thuộc nhóm legacy. Bản 1.26.3 không nằm trong danh sách đã kiểm chứng của module nên cần tự thử patch.
  • Dùng đúng 1.27.1 hoặc 1.26.2, hai bản module nói đã kiểm chứng. Đổi lại anh em dùng bản nginx cũ.
  • Thử vá nginx mới hơn và chạy bộ kiểm thử của module. Phải có thời gian và kiên nhẫn.

Nếu máy chạy thật cần cập nhật bảo mật thường xuyên, lựa chọn một và hai có nghĩa là ôm một bản nginx không còn nhận bản vá. Cân nhắc kỹ trước khi đặt lên máy có Internet.

Cách dựng theo README

README hướng dẫn tải mã nguồn nginx, vá, rồi cấu hình bằng add-module.

patch -p1 < /duong/dan/ngx_http_proxy_connect_module/patch/proxy_connect_rewrite_102101.patch
./configure --add-module=/duong/dan/ngx_http_proxy_connect_module
make && make install

Khi biên dịch thành module động bằng add-dynamic-module, README ghi chú tệp .so phải được nạp bởi chính tệp thực thi nginx đã biên dịch cùng lúc. Trộn tệp .so với nginx từ nguồn khác sẽ lỗi.

README cũng ghi một giới hạn đáng nhớ: HTTP/2 không hỗ trợ phương thức CONNECT. Module chỉ chạy với CONNECT trong HTTP/1.x và HTTPS.

Chuẩn bị topology lab, phiên bản và listener cho nginx forward proxy CONNECT

Mình chưa dựng được lab này. Máy viết bài chạy Windows, không có trình biên dịch C, Docker hay bản phân phối Linux. Bản nginx cho Windows trên trang chủ cũng không bao gồm module ngoài. Mọi điều dưới đây là thiết kế anh em nên làm và cấu hình theo tài liệu.

Ba vai trong lab

  • Máy proxy: Linux, đã biên dịch nginx kèm module, nghe ở một địa chỉ mạng nội bộ cổng 3128.
  • Client được phép: có địa chỉ trong dải cho phép, có tài khoản nếu bật xác thực.
  • Đích thử: máy chủ HTTPS nhỏ trong mạng lab và một cổng TCP không nằm trong danh sách cho phép.

Mục tiêu là chứng minh ba điều. Một, CONNECT tới cổng và host được phép thì thành công. Hai, CONNECT tới cổng hoặc host ngoài danh sách thì bị từ chối. Ba, yêu cầu không phải CONNECT bị xử lý theo cách anh em định.

Vì sao dùng đích nội bộ

Không nên thử bằng website công cộng. Đích nội bộ giúp anh em thấy chính xác proxy làm gì mà không phụ thuộc Internet, và lưu lượng thử không đi ra ngoài.

Phiên bản cần ghi lại

Ghi lại ba thứ: số bản nginx, tên patch đã vá, và mã commit của module. Khi lỗi xuất hiện sau vài tháng, ba thông tin này quyết định anh em có thể tái dựng hay không. Lệnh nginx -V in các tham số biên dịch, trong đó có đường dẫn module đã thêm.

Cấu hình tối thiểu cho nginx forward proxy CONNECT và các tuyến cần kiểm tra

Ví dụ cấu hình trong README gồm một khối server nghe cổng 3128, có resolver, bật proxy_connect, giới hạn cổng bằng proxy_connect_allow và đặt timeout. Mình lấy làm nền rồi thêm lớp kiểm soát.

# nginx.conf (bản lab, chưa chạy thật)
http {
    map $connect_host $host_ok {
        default 0;
        ~^(.+\.)?example\.com$ 1;
        192.168.56.20 1;
    }
 
    server {
        listen 192.168.56.10:3128;
        resolver 192.168.56.1;
 
        proxy_connect;
        proxy_connect_allow 443 8443;
        proxy_connect_connect_timeout 10s;
        proxy_connect_data_timeout 30s;
 
        allow 192.168.56.0/24;
        deny all;
 
        auth_basic "proxy";
        auth_basic_user_file /etc/nginx/htpasswd-proxy;
 
        if ($host_ok = 0) { return 403; }
 
        location / {
            return 403 "Non-CONNECT requests are forbidden";
        }
    }
}

Đọc từng nhóm dòng

Khối server nghe đúng một địa chỉ nội bộ. Tài liệu module nhấn mạnh resolver phải đặt ở cấp server hoặc http, vì proxy cần phân giải tên máy trong lệnh CONNECT. Địa chỉ resolver nên là máy phân giải của mạng lab.

Dòng proxy_connect bật hỗ trợ CONNECT trong khối server. proxy_connect_allow đặt danh sách cổng được phép, ghi đè mặc định 443 và 563. Giá trị all cho mọi cổng, và README cũng cho phép khoảng cổng như 1000-2000. Mình chỉ mở 443 và 8443.

Hai dòng timeout theo README: connect_timeout cho bước thiết lập kết nối tới đích, data_timeout cho khoảng nghỉ giữa hai lần đọc ghi. Mặc định data_timeout là 60 giây, còn connect_timeout không có mặc định.

Khối location trả 403 cho yêu cầu không phải CONNECT, theo đúng gợi ý trong README khi không muốn xử lý các yêu cầu đó.

Chọn resolver cho nginx forward proxy CONNECT

Theo tài liệu nginx về resolver, lệnh này khai báo máy chủ tên miền dùng để đổi tên thành địa chỉ, và đặt được ở cấp http, server hoặc location. Tham số valid ghi đè thời gian lưu kết quả, còn ipv4 và ipv6 cho phép tắt một họ địa chỉ. Tài liệu cũng có resolver_timeout để giới hạn thời gian chờ phân giải.

Với forward proxy, mọi lệnh CONNECT đều cần phân giải, nên resolver chậm làm mọi kết nối chậm. Nên trỏ tới một máy phân giải gần và ổn định trong mạng lab, và đặt valid hợp lý để không tra lại mỗi lần. Nếu đích hay đổi địa chỉ, đặt valid quá dài sẽ giữ địa chỉ cũ.

Khi máy không có IPv6 ra ngoài, tắt ipv6 giúp tránh trường hợp phân giải ra địa chỉ IPv6 rồi kết nối thất bại. Đây là suy luận từ ý nghĩa tham số, mình chưa thử.

Allowlist theo host: phần cần tự thử

Module không có lệnh allowlist host. Mình dùng biến $connect_host, được README mô tả là tên máy trong dòng CONNECT. Một khối map chuyển tên máy thành cờ 1 hoặc 0, rồi if trả 403 khi cờ bằng 0. Đây là cách ghép các thành phần có tài liệu, không phải ví dụ có sẵn trong README.

Vì if và biến nằm ở pha REWRITE, anh em cần patch bản rewrite. Nếu dùng patch không rewrite, phần này không chạy. Mình cũng chưa biết $connect_host có sẵn đúng lúc if chạy hay không. Đây là điểm đầu tiên phải kiểm ở lab, và nếu không đạt thì cần phương án khác.

Kiểm soát client: allow, deny và auth_basic

README nói có thể kiểm soát CONNECT bằng module auth_basic của nginx. Tài liệu auth_basic của nginx mô tả kiểm tra tên và mật khẩu theo HTTP Basic, với tệp mật khẩu tạo bằng htpasswd hoặc openssl passwd. Hai kiểu băm cần tránh: PLAIN và SHA không muối. Tài liệu nói rõ SHA dễ bị tấn công bảng cầu vồng.

Module access cho phép allow và deny theo địa chỉ, kiểm tra theo thứ tự cho tới khi gặp luật khớp đầu tiên. Tài liệu auth_basic cho biết khi kết hợp cả hai thì lệnh satisfy quyết định cần cả hai hay chỉ một. Mặc định, theo tài liệu nginx, cần thỏa cả hai. Anh em nên đọc lại trang đó trước khi tin vào mặc định.

Một chi tiết về mã 401 và 407

Proxy chuẩn trả 407 Proxy Authentication Required kèm header Proxy-Authenticate. Tài liệu auth_basic của nginx nói về xác thực Basic cho tài nguyên, và theo cách thường thấy nó trả 401. Khác biệt này có thể khiến client dùng proxy không biết phải gửi tài khoản. Mình chưa thử trên nginx thật. Khi chạy lab, ghi lại mã trả về và xem client có gửi lại tài khoản hay không. Bài sửa lỗi 407 giải thích mã chuẩn.

Thứ tự dựng lab từng bước

Mỗi bước chỉ thêm một biến số để dễ truy ngược khi có lỗi.

1. Lấy mã nguồn nginx đúng nhánh, lấy mã module, ghi mã commit.

2. Vá bằng patch ứng với bản, xem lệnh patch có báo lỗi hay không.

3. Cấu hình, biên dịch, chạy nginx -V để xác nhận module đã vào.

4. Chạy khối server chỉ có proxy_connect, resolver và location trả 403, thử CONNECT tới cổng 443.

5. Thêm proxy_connect_allow, thử cổng được phép và không được phép.

6. Thêm allow và deny, thử từ máy trong và ngoài dải.

7. Thêm auth_basic, ghi lại mã trả về khi thiếu hoặc sai tài khoản.

8. Thêm khối map và if, thử host trong và ngoài danh sách.

9. Thêm log_format, đối chiếu thời gian từng chặng.

Nếu bước 2 báo patch thất bại, dừng lại. Đó là dấu hiệu bản nginx đã vượt khỏi bảng tương thích, và mọi bước sau đều vô nghĩa cho tới khi xử lý xong.

Chạy ca đúng sai và đọc log nginx forward proxy CONNECT

Bảy ca thử CONNECT và kỳ vọng theo tài liệu

Bảy ca thử CONNECT và kỳ vọng theo tài liệu

Bảng này là kỳ vọng suy ra từ tài liệu. Mình chưa chạy ca nào.

Bảng: Chạy ca đúng sai và đọc log nginx forward proxy CONNECT

Ca thử

Kỳ vọng theo tài liệu

Đã chạy

CONNECT tới host trong danh sách, cổng 443, đủ tài khoản

200 Connection Established, đường hầm mở

Chưa

CONNECT tới cổng 25

Bị từ chối do proxy_connect_allow

Chưa

CONNECT tới host ngoài danh sách

403 do cờ host_ok bằng 0

Chưa

CONNECT từ địa chỉ ngoài dải

Bị deny all chặn

Chưa

CONNECT không tài khoản

Bị từ chối bởi auth_basic, mã cần ghi lại

Chưa

GET thường tới proxy

403 Non-CONNECT requests are forbidden

Chưa

CONNECT qua HTTP/2

Không hỗ trợ theo README

Chưa

Cấu hình client trỏ vào nginx

Khi proxy đã chạy, client khai báo như với mọi proxy HTTP. Công cụ dòng lệnh đọc biến môi trường http_proxy và https_proxy, với địa chỉ dạng http://tai-khoan:[email protected]:3128. README dùng curl với tùy chọn -x để thử, và lệnh đó là cách nhanh nhất để thấy đường hầm mở.

Với các địa chỉ nội bộ không nên đi qua proxy, đặt biến no_proxy. Bài No_proxy là gì giải thích cú pháp, và bài định dạng proxy giải thích cách viết tài khoản vào chuỗi địa chỉ, kể cả khi mật khẩu có ký tự đặc biệt cần mã hóa.

Nếu proxy đặt ở máy chủ ảo của anh em, bài tự dựng proxy trên VPS có thêm các lưu ý về cổng và tường lửa.

Script thử client

Anh em có thể dùng một script socket thô: gửi từng dòng yêu cầu và in dòng trạng thái của proxy. Script không phụ thuộc phần mềm proxy phía sau, nên áp dụng được cho nginx.

ca = [
    ("CONNECT cổng 443", "CONNECT dich-lab.example.com:443 HTTP/1.1"),
    ("CONNECT cổng 25", "CONNECT dich-lab.example.com:25 HTTP/1.1"),
    ("CONNECT host ngoài danh sách", "CONNECT khac.example.org:443 HTTP/1.1"),
]

Mình đã chạy script này với proxy giả bằng Python để kiểm tra script không lỗi. Kết quả đó không nói gì về nginx, nên bài không đưa vào bảng.

Đọc log

Module tự ghi lỗi với tiền tố proxy_connect. README mô tả ví dụ khi kết nối tới đích quá thời gian, log có dòng kèm chữ upstream connect timed out và địa chỉ đích. Các biến như $proxy_connect_connect_time và $proxy_connect_resolve_time, được README mô tả, đo thời gian phân giải và thời gian kết nối, nên đưa vào log_format để nhìn được từng chặng.

Giá trị trống của các biến này nghĩa là module không xử lý yêu cầu đó. Giá trị dấu gạch ngang nghĩa là phân giải hoặc kết nối thất bại. Đây là cách phân biệt lỗi DNS với lỗi kết nối rất rõ ràng.

Anh em có thể đọc triệu chứng phía client ở bài lỗi ERR_TUNNEL_CONNECTION_FAILED.

Ghi log theo từng chặng

Log từng chặng của đường hầm

Log từng chặng của đường hầm

Các biến thời gian của module có thể đưa vào log_format của nginx. Anh em ghi tên máy, cổng, thời gian phân giải, thời gian kết nối và thời gian tới byte đầu.

log_format tunnel '$remote_addr "$connect_host:$connect_port" '
                  'resolve=$proxy_connect_resolve_time '
                  'connect=$proxy_connect_connect_time '
                  'first_byte=$proxy_connect_first_byte_time';
access_log /var/log/nginx/tunnel.log tunnel;

Mỗi dòng log cho biết ai xin đường hầm tới đâu và chậm ở chặng nào. Nếu resolve lớn, máy phân giải chậm. Nếu connect lớn, mạng tới đích chậm. Nếu first_byte lớn nhưng hai chặng đầu nhanh, máy đích chậm trả lời. Mình chưa chạy cấu hình log này.

Phép thử có thể làm mà không cần module

Dù chưa có module, một phép thử đơn giản vẫn giúp: gửi CONNECT vào một nginx gốc rồi ghi lại phản hồi. Kết quả cho thấy nginx gốc từ chối hay đóng kết nối, và đó là mốc để so sánh sau khi vá. Mình chưa chạy phép này vì không chạy được nginx.

Hoàn nguyên, giới hạn và đưa nginx forward proxy CONNECT vào dùng thật

Checklist trước khi dùng nginx forward proxy CONNECT

Checklist trước khi dùng nginx forward proxy CONNECT

Hoàn nguyên lab

Dừng nginx, xóa cấu hình thử, xóa tệp mật khẩu, gỡ bản nginx tự biên dịch khỏi hệ thống hoặc giữ ở thư mục riêng. Đóng cổng 3128 trên tường lửa. Kiểm tra bằng cách thử kết nối vào cổng 3128 từ máy client, kết quả phải là bị từ chối.

Những điều module không làm

FAQ của module trả lời thẳng: module không phân tích hay thao tác được yêu cầu bên trong đường hầm CONNECT. Nó cũng không lấy được dữ liệu của luồng SSL được chuyển. Nếu muốn nhìn dữ liệu, FAQ chỉ cách đặt thêm một lớp proxy nginx giữa module và máy đích, nhưng đó là việc khác.

Giới hạn nữa: HTTP/2 không hỗ trợ CONNECT. Module cũng chỉ chạy ở khối server, không đặt trong location.

Cổng nghe bằng TLS

README có ví dụ cho listen 3128 ssl với chứng chỉ tự ký, để client nói chuyện với proxy qua HTTPS. Với curl, README nêu hai tùy chọn: dùng -x https://... để gửi CONNECT qua HTTPS và --proxy-insecure để bỏ kiểm tra chứng chỉ của proxy. Tùy chọn này không tắt kiểm tra chứng chỉ của website đích.

Cổng nghe bằng TLS giúp thông tin xác thực không đi dạng đọc được trên mạng. Đổi lại không phải client nào cũng hỗ trợ proxy qua HTTPS, nên cần kiểm tra client của anh em trước khi chọn.

Chọn địa chỉ ra bằng proxy_connect_bind

README có proxy_connect_bind để kết nối đi ra bắt nguồn từ một địa chỉ cục bộ cụ thể, và proxy_connect_address để chỉ định luôn địa chỉ đích thay vì dùng kết quả phân giải. Máy nhiều địa chỉ IP cần hai lệnh này để chọn IP mà website nhìn thấy.

FAQ của module có một chú ý: khi dùng proxy_connect_bind với địa chỉ IPv4 mà đích trả về IPv6, kết nối có thể lỗi. Nếu máy có cả hai họ địa chỉ, hãy thử riêng ca này.

Phòng tránh dùng proxy để chạm mạng nội bộ

Một forward proxy đặt trong mạng nội bộ có thể bị dùng để chạm tới chính các dịch vụ nội bộ, vì máy proxy nhìn thấy chúng. Danh sách cổng không đủ. Anh em cần allowlist host, và cần để ý tên miền có thể được cấu hình trỏ về địa chỉ nội bộ.

README nói biến $connect_addr, chứa địa chỉ đã phân giải của đích, không có giá trị đúng ở pha REWRITE. Vì thế mình không dựng luật dựa trên địa chỉ phân giải trong cấu hình trên. Nếu anh em cần chặn theo địa chỉ phân giải, phải tìm cách khác và thử kỹ.

Rủi ro khi dùng thật

Một proxy CONNECT mở là một ống TCP. Nếu cổng nghe lộ ra Internet mà không có allow, deny và xác thực, người ngoài sẽ dùng nó để tấn công qua IP của anh em. Giữ cổng nghe ở địa chỉ nội bộ, khóa bằng ba lớp: địa chỉ client, tài khoản và đích.

Nginx bản vá thủ công cũng không nhận cập nhật tự động. Cần theo dõi thông báo bảo mật của nginx và của module, và tự biên dịch lại khi cần.

Khi nào không nên chọn cách này

Nếu chỉ cần forward proxy cơ bản, các công cụ có sẵn như Squid hay Tinyproxy gọn hơn: không cần vá hay biên dịch. Chọn nginx kèm module khi anh em đã có hạ tầng nginx và muốn một công cụ duy nhất, hoặc cần các biến và đo thời gian của module.

Danh sách kiểm tra trước khi dùng thật

  • Ghi số bản nginx, tên patch, mã commit của module.
  • Đã biên dịch và chạy bộ kiểm thử của module cho đúng bản đang dùng.
  • Cổng nghe chỉ ở giao diện nội bộ, allow và deny đặt đúng dải.
  • proxy_connect_allow chỉ có cổng cần thiết.
  • Xác nhận allowlist host hoạt động bằng ca thử CONNECT ngoài danh sách.
  • Biết mã trả về khi thiếu tài khoản và client xử lý ra sao.
  • Có kế hoạch cập nhật nginx và vá lại.

Nếu cần IP ra ngoài, anh em có thể mua proxy tại ProxyVN, có proxy dân cư tĩnh Viettel, VNPT, FPT, datacenter Việt Nam và proxy xoay, hỗ trợ HTTP và SOCKS5 với tài khoản user và mật khẩu.

Nginx giữ cổng. Module cho nó biết mở đường hầm. Địa chỉ IP vẫn là của máy đang chạy.

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

Nginx có sẵn proxy_connect không. Không. Đây là module ngoài của cộng đồng, phải vá và biên dịch cùng nginx. Nginx gốc chỉ có proxy_pass cho mô hình reverse proxy.

Có dùng được với nginx mới nhất không. README chưa liệt kê nhánh 1.30 hay 1.31. Lần cập nhật hỗ trợ gần nhất của module là tháng 8 năm 2024. Mình chưa thử vá bản mới, nên anh em tự kiểm tra bằng bộ kiểm thử của module.

Khác gì Squid khi làm forward proxy. Squid là forward proxy đầy đủ, có cache và nhiều luật truy cập, không cần vá. Nginx kèm module gọn hơn về tính năng, hợp khi anh em đã dùng nginx.

Thêm xác thực kiểu 407 cho nginx được không. Tài liệu module chỉ nói có thể dùng auth_basic. Mình chưa kiểm tra mã trả về. Nếu client cần 407 đúng chuẩn, cần thử và có thể phải điều chỉnh.

Dùng được cho HTTP thường không, hay chỉ HTTPS. Module xử lý phần CONNECT. Với yêu cầu HTTP thường, README gợi ý tự định nghĩa trong khối location, ví dụ proxy_pass tới $host, hoặc từ chối bằng 403. Mình chọn từ chối để giữ phạm vi hẹp.

Có thể kết hợp với bài reverse proxy không. Được, miễn tách khối server. Một khối server nghe cổng 3128 làm forward proxy, các khối khác làm reverse proxy như bài đã đăng. Đừng dùng chung khối.

Có đo được độ trễ của proxy không. Có, nhờ các biến proxy_connect_resolve_time, connect_time và first_byte_time được README mô tả. Chúng đo từng chặng của đường hầm. Mình chưa chạy nên chưa có số liệu.

Nên đặt timeout bao nhiêu. README đặt mặc định 60 giây cho data_timeout và không có mặc định cho connect_timeout. Ví dụ trong README dùng 10 giây cho cả hai. Mình chọn 10 giây cho kết nối và 30 giây cho nghỉ dữ liệu, rồi khuyên đo thực tế vì ứng dụng nào cũng khác.

Vì sao lệnh nginx -t báo lỗi khi mình thêm proxy_connect. Nguyên nhân thường là nginx đang chạy không có module, hoặc tệp .so không khớp với tệp nginx đã biên dịch. README nhấn mạnh .so phải được nạp bởi đúng tệp nginx đã biên dịch cùng lúc. Chạy nginx -V để xem bản đang dùng thật sự là bản nào.

Có cần mở cổng 443 trên máy proxy không. Không. Cổng 443 trong proxy_connect_allow là cổng đích ở phía ngoài, không phải cổng nghe. Cổng nghe của proxy là 3128 trong ví dụ.

Có thể giới hạn số kết nối đồng thời của mỗi client không. Các module chuẩn của nginx như limit_conn hoạt động theo khối server, nhưng mình chưa kiểm tra chúng có áp dụng cho yêu cầu CONNECT của module hay không. Nếu cần chống lạm dụng, hãy thử ca này ở lab trước khi dựa vào nó.

Nginx forward proxy CONNECT và những điều cần nhớ

Nginx forward proxy CONNECT cần module ngx_http_proxy_connect_module, patch đúng nhánh nginx (bảng dừng ở 1.26.x và 1.27.1) và khóa bằng allow, xác thực, proxy_connect_allow. Mặc định chỉ cho cổng 443 và 563. Cần proxy ổn định, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam cho Nginx forward proxy CONNECT.

TIN TỨC LIÊN QUAN