Cấu hình NO_PROXY cho localhost và API nội bộ đúng cách

Trong môi trường doanh nghiệp, ứng dụng thường phải truy cập Internet qua proxy để đáp ứng chính sách mạng và kiểm soát lưu lượng. Tuy nhiên, các kết nối đến localhost, dịch vụ trên cùng máy hoặc API nội bộ thường cần đi trực tiếp. Nếu không phân biệt những đích này, yêu cầu có thể bị chuyển đến proxy ngoài dự kiến, gây lỗi kết nối hoặc làm sai luồng giao tiếp giữa các dịch vụ.

Cấu hình NO_PROXY giúp xác định những địa chỉ không sử dụng proxy trong các HTTP client có hỗ trợ. Để cấu hình đúng, cần hiểu cách ứng dụng đọc biến môi trường, cách so khớp tên miền và ý nghĩa của localhost trong từng môi trường triển khai.

NO_PROXY hoạt động như thế nào?

NO_PROXY là biến môi trường chứa danh sách đích mà HTTP client được yêu cầu kết nối trực tiếp, thay vì sử dụng proxy đã khai báo. Danh sách này thường gồm hostname, tên miền hoặc địa chỉ IP, phân tách bằng dấu phẩy.

Một bộ biến môi trường proxy phổ biến gồm:

• HTTP_PROXY: địa chỉ proxy dành cho các yêu cầu HTTP, nếu client hỗ trợ biến này.
• HTTPS_PROXY: địa chỉ proxy dành cho các yêu cầu HTTPS.
• NO_PROXY: danh sách đích được kết nối trực tiếp.

Khi gửi yêu cầu, client quyết định sử dụng proxy dựa trên cấu hình hiệu lực và cách so khớp danh sách ngoại lệ. Vì vậy, NO_PROXY không phải quy tắc định tuyến áp dụng tự động cho toàn bộ hệ điều hành. Nó chỉ có tác dụng với chương trình hoặc thư viện có triển khai cơ chế tương ứng.

Đặc biệt, HTTPS_PROXY không bắt buộc phải chứa URL bắt đầu bằng https://. Với proxy HTTP hỗ trợ phương thức CONNECT, giá trị dạng http://proxy.corp.example:8080 có thể được dùng cho yêu cầu HTTPS. Giao thức trong URL mô tả cách kết nối đến proxy, không phải giao thức của website đích.

Cấu hình cơ bản cho localhost và API nội bộ

Giả sử ứng dụng phải truy cập Internet qua proxy của tổ chức, đồng thời gọi dịch vụ cục bộ và API tại api.corp.example. Trong shell tương thích POSIX, có thể khai báo:

export HTTP_PROXY='http://proxy.corp.example:8080'

export HTTPS_PROXY='http://proxy.corp.example:8080'

export NO_PROXY='localhost,127.0.0.1,::1,api.corp.example'

Các địa chỉ và cổng trong ví dụ chỉ có tính minh họa; cần thay bằng cấu hình được quản trị viên cung cấp. Sau khi khai báo, hãy khởi chạy ứng dụng từ chính phiên shell đó để tiến trình nhận được các biến môi trường.

Bỏ qua proxy cho localhost cần khai báo những gì?

Cần kiểm tra riêng localhost, loopback IPv4 và loopback IPv6 thay vì giả định một khai báo bao phủ tất cả.

Nên liệt kê localhost, 127.0.0.1 và ::1 khi ứng dụng có thể sử dụng cả tên localhost, địa chỉ loopback IPv4 và địa chỉ loopback IPv6. Không nên giả định rằng khai báo localhost sẽ tự động bao phủ mọi yêu cầu gửi đến địa chỉ loopback.

Thông thường, việc so khớp dựa trên hostname hoặc địa chỉ xuất hiện trong URL, không phải toàn bộ địa chỉ mà DNS có thể phân giải ra. Vì vậy, http://localhost và http://127.0.0.1 có thể được xử lý khác nhau. Cú pháp IPv6 trong NO_PROXY cũng cần được kiểm tra với client thực tế.

Khai báo API nội bộ theo phạm vi phù hợp

Nếu chỉ một API cần kết nối trực tiếp, hãy bắt đầu bằng hostname cụ thể như api.corp.example. Nếu nhiều dịch vụ cùng một miền nội bộ có chung chính sách kết nối, có thể cân nhắc ngoại lệ theo hậu tố miền.

Ví dụ thường gặp là NO_PROXY='localhost,127.0.0.1,::1,corp.example,.corp.example'. Tuy nhiên, cách hiểu tên miền gốc và dấu chấm đầu không đồng nhất giữa mọi client. Cần xác minh cả trường hợp corp.example và các tên con như api.corp.example trước khi áp dụng rộng rãi.

Những quy tắc so khớp cần kiểm tra

Hostname không phải URL đầy đủ

Trong cấu hình thông thường, NO_PROXY chứa đích kết nối, không chứa giao thức hoặc đường dẫn. Nên dùng api.corp.example thay vì https://api.corp.example/private. Biến này không phải công cụ để đặt chính sách riêng cho từng đường dẫn API.

Nếu cần phân biệt lưu lượng theo đường dẫn, hãy sử dụng tính năng định tuyến của ứng dụng hoặc một thành phần mạng phù hợp. Không nên mở rộng ý nghĩa của NO_PROXY ngoài những gì client hỗ trợ.

Không mặc định ký tự đại diện luôn được hỗ trợ

Cú pháp *.corp.example có thể không được diễn giải giống nhau giữa các thư viện. Một số client hỗ trợ giá trị * đứng riêng để kết nối trực tiếp đến mọi đích, nhưng điều đó không có nghĩa chúng hỗ trợ mẫu ký tự đại diện trong tên miền.

Không nên đặt NO_PROXY='*' cho ứng dụng vẫn phải sử dụng proxy khi truy cập Internet. Giá trị này có thể làm mất tác dụng của cấu hình proxy đối với client hỗ trợ nó.

Địa chỉ IP, CIDR và cổng phụ thuộc client

Không phải thư viện nào cũng hiểu dải mạng theo ký pháp CIDR trong NO_PROXY. Ngoài ra, hỗ trợ CIDR không đồng nghĩa client sẽ phân giải mọi hostname rồi kiểm tra địa chỉ kết quả với dải mạng đó.

Tương tự, cú pháp hostname:cổng chỉ có ý nghĩa trên những client hỗ trợ so khớp theo cổng. Khi chưa có yêu cầu đặc biệt, ưu tiên hostname hoặc IP cụ thể và kiểm tra hành vi trước khi bổ sung quy tắc phức tạp.

Chữ hoa, chữ thường và thứ tự ưu tiên

Nhiều môi trường sử dụng cả HTTP_PROXY, HTTPS_PROXY, NO_PROXY và các biến chữ thường tương ứng. Mức độ hỗ trợ cùng thứ tự ưu tiên phụ thuộc chương trình, nên không có một quy tắc chung áp dụng cho mọi ứng dụng.

Để giảm khác biệt giữa các công cụ, có thể đồng bộ các biến trong shell:

export http_proxy="$HTTP_PROXY"

export https_proxy="$HTTPS_PROXY"

export no_proxy="$NO_PROXY"

Không để hai biến cùng chức năng mang giá trị mâu thuẫn. Chẳng hạn, NO_PROXY chứa API nội bộ nhưng no_proxy lại rỗng có thể tạo ra kết quả khác nhau giữa các client.

Riêng curl chỉ chấp nhận dạng chữ thường http_proxy cho cấu hình proxy HTTP qua biến môi trường, vì lý do bảo mật liên quan đến môi trường CGI. Đây là ví dụ cho thấy cần đọc tài liệu của công cụ đang sử dụng thay vì chỉ dựa vào tên biến phổ biến.

Áp dụng trong ứng dụng và container

Ứng dụng chạy bằng dịch vụ hệ thống

Khai báo biến trong terminal không làm thay đổi môi trường của dịch vụ đã chạy. Với trình quản lý dịch vụ, cần đặt biến tại cấu hình môi trường của dịch vụ rồi thực hiện thao tác tải lại hoặc khởi động lại theo cơ chế tương ứng.

Hãy kiểm tra môi trường của đúng tiến trình ứng dụng. Việc nhìn thấy NO_PROXY trong terminal chỉ chứng minh phiên shell hiện tại có biến đó, không chứng minh dịch vụ nền đã nhận được.

Container và Docker Compose

Container cần được truyền biến môi trường, còn API ở container khác phải được gọi bằng tên dịch vụ phù hợp.

Biến môi trường trên máy chủ không tự động xuất hiện trong mọi container. Cần truyền HTTP_PROXY, HTTPS_PROXY và NO_PROXY vào môi trường chạy của container thông qua cơ chế cấu hình triển khai.

Localhost trong container trỏ đến chính không gian mạng của container đó. Nếu API nằm trong container khác, ứng dụng thường phải gọi bằng tên dịch vụ, chẳng hạn internal-api. Khi đó, tên internal-api cần xuất hiện trong danh sách ngoại lệ nếu client đang sử dụng proxy.

Cũng cần phân biệt môi trường xây dựng image với môi trường chạy ứng dụng. Proxy hoạt động khi tải gói trong bước build không chứng minh cấu hình ở thời điểm chạy đã đúng.

Cụm Kubernetes

Trong Kubernetes, ứng dụng có thể truy cập dịch vụ qua tên ngắn, tên có namespace hoặc tên DNS đầy đủ. Cấu hình ngoại lệ nên phản ánh chính xác các dạng tên mà ứng dụng thực sự sử dụng.

Không nên sao chép nguyên danh sách tên miền hoặc dải mạng từ một cụm khác. Hậu tố DNS và quy hoạch mạng có thể khác nhau; đồng thời, client có thể không hỗ trợ cú pháp được khai báo.

Khác biệt giữa các thư viện HTTP

Cấu hình đúng ở cấp môi trường vẫn có thể không có tác dụng nếu ứng dụng sử dụng cơ chế proxy riêng. Khi xử lý proxy API nội bộ, hãy kiểm tra cả runtime lẫn thư viện gửi yêu cầu.

• Python Requests: thông thường đọc cấu hình proxy từ môi trường. Tuy nhiên, cấu hình session hoặc việc tắt trust_env có thể thay đổi hành vi này.
• Go: transport sử dụng http.ProxyFromEnvironment có thể đọc biến môi trường. Transport tùy chỉnh có thể không sử dụng cơ chế đó.
• Node.js: không nên giả định mọi phiên bản, thư viện hoặc HTTP agent đều tự động đọc cùng bộ biến proxy. Cần kiểm tra thành phần gửi yêu cầu cụ thể.
• Java: nhiều ứng dụng sử dụng thuộc tính JVM như http.proxyHost và http.nonProxyHosts thay vì trực tiếp dựa vào NO_PROXY. Cú pháp danh sách ngoại lệ cũng khác.

Nếu ứng dụng đặt proxy trực tiếp trong mã nguồn, hãy xác minh cấu hình đó có còn tham chiếu NO_PROXY hay không. Tùy chọn proxy tường minh có thể thay đổi cơ chế xử lý ngoại lệ.

Quy trình kiểm tra cấu hình NO_PROXY

Đối chiếu log và kết nối thực tế để xác nhận đường đi, không chỉ dựa vào phản hồi thành công.

1. Xác nhận biến môi trường: kiểm tra trong đúng container, phiên chạy hoặc tiến trình liên quan; che thông tin xác thực khi chia sẻ kết quả.
2. Thử một đích Internet: sử dụng endpoint được phép và xác nhận yêu cầu vẫn đi qua proxy bằng log hoặc thông tin kết nối.
3. Thử localhost: gọi đúng hostname và cổng mà ứng dụng sử dụng, sau đó kiểm tra kết nối trực tiếp.
4. Thử API nội bộ: kiểm tra bằng cùng thư viện và cấu hình của ứng dụng, không chỉ bằng công cụ dòng lệnh.
5. Đối chiếu bằng chứng: kết hợp log ứng dụng, log proxy và quan sát kết nối mạng nếu được cấp quyền.

Có thể dùng curl -v https://api.corp.example/health để quan sát quá trình kết nối. Chế độ chi tiết có thể hiển thị dữ liệu nhạy cảm, vì vậy cần kiểm tra và che thông tin trước khi chia sẻ log.

Một phản hồi thành công chưa đủ chứng minh yêu cầu đi trực tiếp. Ngược lại, lỗi kết nối trực tiếp chưa chắc do NO_PROXY: nguyên nhân có thể nằm ở DNS, tường lửa, định tuyến hoặc chứng chỉ TLS.

Lỗi thường gặp và nguyên tắc vận hành

Những lỗi phổ biến gồm khai báo sai tên biến, dùng URL thay cho hostname, quên truyền biến vào container, chưa khởi động lại dịch vụ hoặc gọi API bằng tên khác với tên đã khai báo. Chuyển hướng HTTP sang hostname khác cũng có thể khiến yêu cầu tiếp theo chịu quy tắc proxy khác.

Về bảo mật, nên giữ danh sách ngoại lệ ở phạm vi cần thiết, không đưa mật khẩu proxy vào kho mã nguồn và không tắt xác minh TLS để xử lý lỗi kết nối. NO_PROXY chỉ điều khiển lựa chọn proxy ở client; nó không cấp quyền truy cập mạng và không thay thế chính sách tường lửa.

Kết luận

Để cấu hình NO_PROXY hiệu quả, hãy bắt đầu bằng localhost, các địa chỉ loopback cần dùng và hostname API nội bộ cụ thể. Sau đó đồng bộ biến môi trường, kiểm tra khả năng hỗ trợ của thư viện và xác nhận đường đi thực tế của yêu cầu. Cách tiếp cận này giúp ứng dụng duy trì truy cập Internet qua proxy trong khi các kết nối nội bộ hoạt động đúng thiết kế.