Hero Image
Hero Image
Hero Image
使用 Nginx HTTPS 與 Basic Auth 反向代理 VMware ESXi 6.5 修復 VMRC /screen

使用 Nginx HTTPS 與 Basic Auth 反向代理 VMware ESXi 6.5 修復 VMRC /screen server { listen 80; server_name esxi.hackion.com; return 301 https://$server_name$request_uri; } server { listen 443 ssl; server_name esxi.hackion.com; ssl_certificate /mycert.crt; ssl_certificate_key /mykey.key; location / { auth_basic "Restricted Content"; auth_basic_user_file /etc/nginx/.htpasswd; proxy_set_header Upgrade $http_upgrade; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Origin ''; proxy_set_header Authorization ''; #Don't pass the Nginx Basic Auth to ESXi or it will break VMRC. proxy_pass_header X-XSRF-TOKEN; proxy_pass https://esxi_server; proxy_send_timeout 300; proxy_read_timeout 300; send_timeout 300; client_max_body_size 1000m; # enables WS support proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } } server { listen 443 ssl http2; # ssl_certificate and ssl_certificate_key are required ssl_certificate /etc/letsencrypt/live/myletsencryptdomain/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/myletsencryptdomain/privkey.pem; include /etc/nginx/snippets/ssl-params.conf; # removed DH params as my ssl-params.conf specifies to only use ECDHE key exchange. server_name fqdn.extern; location / { proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_ssl_verify off; # No need on isolated LAN proxy_pass https://vcenter.ip; # esxi IP Address proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_buffering off; client_max_body_size 0; proxy_read_timeout 36000s; proxy_redirect https://fqdn.local/ https://fqdn.extern/; # read comment below # replace vcenter-hostname with your actual vcenter's hostname, and esxi with your nginx's server_name. } location /websso/SAML2 { proxy_set_header Host fqdn.local; # your actual vcenter's hostname proxy_set_header X-Real-IP $remote_addr; proxy_ssl_verify off; # No need on isolated LAN proxy_pass https://vcenter.ip; # esxi IP Address proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_buffering off; client_max_body_size 0; proxy_read_timeout 36000s; proxy_ssl_session_reuse on; proxy_redirect https://fqdn.local/ https://fqdn.extern/; # read comment below # replace vcenter-hostname with your actual vcenter's hostname, and esxi with your nginx's server_name. } }

Hero Image
nginx 添加第三方nginx_upstream_check_module 模块实现健康状态检测

nginx 添加第三方 nginx_upstream_check_module 模块实现健康状态检测 nginx_upstream_check_module Health check HTTP servers inside an upstream nginx.conf http { upstream cluster { # simple round-robin server 192.168.0.1:80; server 192.168.0.2:80; check interval=5000 rise=1 fall=3 timeout=4000; #check interval=3000 rise=2 fall=5 timeout=1000 type=ssl_hello; #check interval=3000 rise=2 fall=5 timeout=1000 type=http; #check_http_send "HEAD / HTTP/1.0\r\n\r\n"; #check_http_expect_alive http_2xx http_3xx; } ... check syntax: *check interval=milliseconds [fall=count] [rise=count] [timeout=milliseconds] [default_down=true|false] [type=tcp|http|ssl_hello|mysql|ajp|fastcgi]* 默认配置:interval=3000 fall=5 rise=2 timeout=1000 default_down=true type=tcp* ... interval: 检测间隔 3 秒 fall: 连续检测失败次数 5 次时,认定 relaserver is down rise: 连续检测成功 2 次时,认定 relaserver is up timeout: 超时 1 秒 default_down: 初始状态为 down,只有检测通过后才为 up type: 检测类型方式 tcp tcp :tcp 套接字,不建议使用,后端业务未 100%启动完成,前端已经放开访问的情况 ssl_hello: 发送 hello 报文并接收 relaserver 返回的 hello 报文 http: 自定义发送一个请求,判断上游 relaserver 接收并处理 mysql: 连接到 mysql 服务器,判断上游 relaserver 是否还存在 ajp: 发送 AJP Cping 数据包,接收并解析 AJP Cpong 响应以诊断上游 relaserver 是否还存活(AJP tomcat 内置的一种协议) fastcgi: php 程序是否存活 example

Hero Image
Nginx 請求處理流程你了解嗎?

Nginx 請求處理流程你了解嗎? 11 個處理階段 1)NGX_HTTP_POST_READ_PHASE: 接收到完整的 HTTP 標頭後處理的階段,位於 URI 重寫之前。實際上很少有模組會註冊在該階段,預設情況下會被跳過。 2)NGX_HTTP_SERVER_REWRITE_PHASE: 在 URI 與 location 匹配前修改 URI 的階段,用於重新導向。該階段執行 server 區塊內、location 區塊外的重寫指令。在讀取請求標頭的過程中,nginx 會根據 host 及埠號找到對應的虛擬主機設定。 3)NGX_HTTP_FIND_CONFIG_PHASE: 根據 URI 尋找匹配的 location 設定項階段,使用重寫後的 URI 來查找對應的 location。需要注意的是該階段可能會被執行多次,因為也可能有 location 級別的重寫指令。 4)NGX_HTTP_REWRITE_PHASE: 上一階段找到 location 後再次修改 URI,屬於 location 級別的 URI 重寫階段,也可能會被執行多次。 5)NGX_HTTP_POST_REWRITE_PHASE: 防止重寫 URL 後導致的死循環,屬於 location 重寫的下一階段,用來檢查上階段是否有 URI 重寫,並根據結果跳轉到合適的階段。 6)NGX_HTTP_PREACCESS_PHASE: 下一階段之前的準備,屬於存取權限控制的前一階段。一般也用於存取控制,例如限制存取頻率、連線數等。 7)NGX_HTTP_ACCESS_PHASE: 讓 HTTP 模組判斷是否允許請求進入 Nginx 伺服器的存取控制階段,例如基於 IP 白名單/黑名單、使用者名稱密碼等的權限控制。 8)NGX_HTTP_POST_ACCESS_PHASE: 存取控制的後一階段,根據上一階段的執行結果進行處理,向使用者送出拒絕服務的錯誤碼,用來回應上一階段的拒絕。 9)NGX_HTTP_TRY_FILES_PHASE: 為存取靜態檔案資源而設置,try_files 指令的處理階段。如果沒有設定 try_files 指令,該階段會被跳過。 10)NGX_HTTP_CONTENT_PHASE: