Sửa đổi dữ liệu được ủy quyền bởi nginx khi đang di chuyển


9

Tôi có một thiết lập nginx nhận yêu cầu từ các máy chủ bên ngoài và ủy quyền cho máy chủ nội bộ.

Cấu hình trông giống như thế này:

server {

        listen 10.0.0.66:443;

        server_name my.example.com;

        root /websites/my.example.com

        ssl on;
        ssl_certificate /websites/ssl/my.example.com.crt;
        ssl_certificate /websites/ssl/my.example.com.key;

        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header Host $http_host;

        location / {
                proxy_pass https://10.0.0.100:3000/;
        }
}

Đối với mục đích thử nghiệm / thử nghiệm, tôi muốn có thể chạy những gì máy chủ nội bộ đã trả lời thông qua một nhị phân tùy ý và phản hồi với những gì nhị phân phản hồi.

dụ: nếu tôi muốn thu nhỏ html trên proxy, tôi sẽ chạy phản hồi của máy chủ thông qua htmlcompressor và sau đó gửi đầu ra dưới dạng phản hồi của proxy cho máy khách. Kết quả cuối cùng sẽ là máy khách cuối nhận được rút gọn html.

Tôi biết có tất cả các loại addon và ví dụ để nginx thực hiện điều này cho dữ liệu được phục vụ tại địa phương, nhưng làm cách nào để thiết lập nó cho proxy?


Chỉ cần làm rõ. Bạn muốn nginx chuyển tiếp yêu cầu đến máy chủ proxy, nhận phản hồi lại, nén nó, sau đó chuyển tiếp nó đến người dùng? Bạn muốn nginx xử lý nó ở giữa máy chủ và người dùng?
sjdaws

@sjdaws, không nhất thiết phải nén nó, nhưng chạy nó thông qua bất kỳ chương trình tùy ý nào và sử dụng đầu ra như những gì được gửi đến máy khách. Vì vậy, về bản chất, tôi muốn sửa đổi đầu ra từ máy chủ sang máy khách.
0x6A75616E

Câu trả lời:


10

Vì vậy, bạn muốn nginxủy quyền một yêu cầu từ máy khách đến máy chủ phụ trợ, và sau đó, trước khi trả lại câu trả lời của phụ trợ cho máy khách, hãy trả lời như vậy thông qua bộ xử lý bên ngoài khác?

Tôi không nghĩ rằng bạn có thể làm như trên với bất kỳ nginxmô-đun chính thức nào được cung cấp bởi Igor Sysoev và Nginx, Inc. Điều gần gũi nhất đó là có sẵn để thay đổi cơ thể của phản ứng là một vài mô-đun bộ lọc mà đến với nhau với nginx, nhưng tắt theo mặc định, bao gồm cả add_before_body, add_after_bodysub_filterchỉ thị:

http://nginx.org/en/docs/http/ngx_http_addition_module.html
http://nginx.org/en/docs/http/ngx_http_sub_module.html

Ngoài ra, có lẽ gzip on;là những gì bạn thực sự muốn thay thế?

http://nginx.org/en/docs/http/ngx_http_gzip_module.html

Hoặc, có khả năng, nếu bạn biết perlvà sẵn sàng chạy một mô-đun thử nghiệm hoàn toàn, hãy xem việc nhúng perlvào nginx, với một mô-đun nginx chính thức được tắt theo mặc định và (hoàn toàn rõ ràng) hoàn toàn thử nghiệm:

http://nginx.org/en/docs/http/ngx_http_perl_module.html

Một tùy chọn khác là sử dụng một số loại thiết lập Fast-CGI mà bạn sẽ chuyển hướng các yêu cầu, trong đó, lần lượt, tập lệnh Fast-CGI của bạn sẽ thực hiện các yêu cầu đến phần phụ trợ, rồi xử lý cuối cùng, trước khi quay lại các phản hồi trở lại nginx để lưu trữ và trả lại cho người dùng.

Ngoài ra còn có proxy_set_body(nhưng chưa có fastcgi_set_body), để thay đổi nội dung của yêu cầu (ví dụ: từ những gì khách hàng đã cung cấp), nhưng dường như không có bất kỳ chỉ thị hoặc biến tương đương nào để có được phần thân của phản hồi, để vượt qua đến một yêu cầu nào đó tiếp theo cho một bộ xử lý sau. Trong mọi trường hợp, một mô-đun bộ lọc có thể là những gì bạn muốn cho một bộ xử lý hậu.

(Ngoài ra, bạn có nhận ra rằng một cách tiếp cận ngây thơ của các forkcâu trả lời ing và đường ống thông qua một giám đốc điều hành thông thường sẽ cực kỳ chậm, phải không?)

Tóm lại , tôi nghĩ gzip on;chính xác là những gì bạn đang tìm kiếm; mặt khác, miễn là bạn có thể sửa đổi ứng dụng web gốc, tôi nghĩ rằng cách tốt nhất của bạn có thể là cài đặt một số loại bộ xử lý hậu kỳ trong chính ứng dụng web, có vẻ như là giải pháp đơn giản nhất tiếp theo. Về tiềm năng, bạn có thể xem xét cách các mô-đun bộ lọc được triển khai, ví dụ ngx_http_addition_filter_module.c đã nói ở trên, cộng với một số bộ lọc có liên quan rõ ràng hơn như ngx_http_gzip_filter_module.c và triển khai mô đun bộ lọc nhúng của riêng bạn. Hoặc thuê Nginx, Inc. để viết bài này cho bạn! Nhưng, nghiêm túc, gzip on;chỉ hoạt động và có khả năng mang lại cho bạn kết quả tốt hơn nhiều mà không gặp rắc rối, hiệu suất hoặc vấn đề ổn định và nó đã được biên dịch theo mặc định, bạn chỉ cần kích hoạt nó trongnginx.conf.


Cảm ơn vì đã trả lời! Tôi nhận thức được gzip và những gì tôi đang cố gắng thực hiện ở mức cao hơn so với làm chệch hướng đầu ra. Tôi có một proxy kiểm soát quyền truy cập vào một số dịch vụ web nội bộ nhất định và tôi muốn có thể nối thêm những thứ như phân tích google vào đầu ra, giống như cách mà cloudflare thực hiện. Giống như bạn nói, có vẻ như fastcgi là một lựa chọn, vì vậy tôi sẽ xem xét điều đó. Cảm ơn một lần nữa!
0x6A75616E

Nếu bạn chỉ muốn nối thêm công cụ hoặc thêm phân tích google, thì add_after_bodyhoặc sub_filterchính xác là những gì bạn cần. Ví dụ tại nginx.org/en/docs/http/ngx_http_sub_module.html hiển thị chính xác kịch bản đó: thay thế "</ head>" bằng "</ head> <script." Bạn có thể phải biên dịch lại nginx để kích hoạt các mô-đun đó (kiểm tra xem nginx -Vnginx của bạn đã được biên dịch như thế nào), nhưng chúng đã là các mô-đun chuẩn.
cnst

Có một cái nhìn vào mô-đun subs_filter quá.
franzlorenzon

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.