标签：#NGINX

Tuning guides talk about throughput. Nobody pages you about throughput. They page you about symptoms, and the useful skill is mapping a symptom back to a cause before you spend money on hardware. Three failure modes account for most of what I find on inherited servers. Each has a distinct signature. The 502 nobody can reproduce Server has 8GB. PHP-FPM is set to 100 workers. Each worker uses 60MB under load. That's 6GB of PHP, plus MariaDB, plus Nginx, plus the OS. Under normal traffic you never approach 100 workers, so it looks fine for months. Then a marketing email goes out, concurrency spikes, and the kernel runs out of memory. The OOM killer picks a process and terminates it, usually the biggest one, which is a PHP-FPM worker holding an in-flight request. User gets a 502. The application log has nothing, because the process died before it could write anything. Nginx logs recv() failed (104: Connection reset by peer) . Ten minutes later everything looks normal. sudo dmesg -T | grep -i "killed process" sudo journalctl -k | grep -i oom Hits there mean you don't have a mystery. You have a pm.max_children value nobody checked against real memory. The site that degrades all day and resets overnight TTFB is 180ms at 8am. By 4pm it's 900ms. Nobody deployed. Overnight it's fast again because something restarted PHP-FPM. That's OPcache running out of room. When the cache fills, it stops caching new scripts or wipes and rebuilds, and every miss pays full parse-and-compile again. It degrades gradually, which is why it goes unnoticed for months. The counters are oom_restarts and hash_restarts from opcache_get_status() . Here's the part that trips people up. OPcache state is per SAPI. Run that function from the CLI and you're reading the CLI cache, which is empty, separate, and tells you nothing about your site. You have to ask through PHP-FPM. <?php // drop in webroot, lock to your IP, delete when done $allowed = [ '203.0.113.42' ]; if ( ! in_array ( $_SERVER [ 'REMOTE_ADDR'

The browser console showed exactly what CORS errors always show — a request blocked for violating the same-origin policy — except the response headers, visible in the network tab, clearly included Access-Control-Allow-Origin: * . The header the browser wanted was right there. The browser rejected the request anyway. The detail that's easy to miss in the network tab Chrome's network inspector, by default, coalesces duplicate header names into a single display line — so Access-Control-Allow-Origin: * shown once in the UI can actually mean the header was sent twice by the server, and the browser is showing you a merged, deduplicated view rather than the literal wire response. curl -s -D - https://api.example.com/data -o /dev/null | grep -i access-control Access-Control-Allow-Origin: * Access-Control-Allow-Origin: https://app.example.com Two separate headers, both valid individually, sent by two different layers that each thought they were the one responsible for CORS: our nginx reverse proxy had a blanket add_header Access-Control-Allow-Origin *; for general API access, and the application server behind it independently set a specific origin for authenticated routes. Neither config was wrong on its own. Together, they produced a response with the header appearing twice — and per the Fetch spec, a response with multiple Access-Control-Allow-Origin values is treated as invalid, so the browser blocks the request rather than guessing which one you meant. Why this is worse than a missing header A missing CORS header fails immediately, obviously, the same way every time. A duplicate header fails in a way that looks, from the response body alone, like the header is present and correct — because it is present, twice, which is precisely the state that trips the spec's validation. Every piece of evidence you'd normally check says "this should work," and it still doesn't. The fix Removed the blanket nginx header and let the application server be the single source of truth for COR

Moving a Next.js app off Vercel and onto a plain Ubuntu VPS usually starts with a painful realization: either your serverless functions are timing out on background jobs, or your client just handed you a strict "you must host this on our infrastructure" requirement. Deploying the app itself is easy. What trips people up (and what cost me hours of debugging and locking myself out of my own server) is everything around the app. Here are the 12 things that actually break when you leave the serverless ecosystem, in the order you'll hit them. 1. Next.js needs a process manager, not just npm start Running npm start in a terminal dies the moment you disconnect. You need something that keeps the process alive, restarts it on crash, and survives a reboot. PM2 is the simplest option for a single-server Node deploy. npm install -g pm2 // ecosystem.config.js module . exports = { apps : [{ name : " my-app " , script : " node_modules/.bin/next " , args : " start " , cwd : " /var/www/my-app " , instances : 1 , exec_mode : " fork " , autorestart : true , max_memory_restart : " 512M " , env : { NODE_ENV : " production " , PORT : 3000 }, }], }; cd /var/www/my-app && pm2 start ecosystem.config.js pm2 save pm2 startup systemd -u YOUR_USER --hp /home/YOUR_USER That last line is the one people forget - without it, PM2's process list doesn't survive a server reboot. 2. Nginx needs to proxy to the port, not serve the files Next.js is not a static site (unless you've explicitly exported it as one). Nginx's job is to forward requests to the Node process, not serve files from disk: upstream nextjs_upstream { server 127.0.0.1 : 3000 ; keepalive 64 ; } server { listen 80 ; server_name example.com www.example.com ; location / { proxy_pass http://nextjs_upstream ; proxy_set_header Host $host ; proxy_set_header X-Real-IP $remote_addr ; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for ; proxy_set_header X-Forwarded-Proto $scheme ; # WebSocket support - required for HMR and any realtime f

A syndication job noticed before I did A scheduled task publishes one blog post a day to a developer community. It fetches the article from my own site, converts it, and posts it. At 10:00 it failed four times with this: Server error '521 <none>' for url 'https://neuragrowth.co/blog/schema-grammar-ceiling/' 521 is Cloudflare saying the origin server did not answer. So the interesting failure was not in the syndication job at all. My whole site was down, and had been for over three hours by then. The server itself was fine: four days of uptime, load under 0.2, disk at eight percent. But systemctl is-active nginx said failed , and nothing was listening on 80 or 443. nginx resolves your upstreams before it starts The journal had the whole thing in three lines: 06:49:54 systemd[1]: Stopping nginx.service... 06:49:54 nginx[36027]: [emerg] host not found in upstream "example-backend.tld" in /etc/nginx/sites-enabled/site:104 06:49:54 nginx[36027]: nginx: configuration file test failed Line 104 was a small proxy I had added months earlier so the public site could forward one form endpoint to a backend on a different host without revealing its name: location = /api/lead-capture { proxy_pass https://example-backend.tld/api/lead-capture ; proxy_ssl_server_name on ; proxy_set_header Host example-backend.tld ; } When proxy_pass contains a literal hostname, nginx resolves it while parsing the configuration , and treats failure as a fatal config error. That resolution happens inside ExecStartPre=/usr/sbin/nginx -t , so a name it cannot look up means the unit never starts. The config was not wrong. It was valid before the restart and valid after, and nginx -t passed by hand seven hours later. It was invalid for about one second. Why DNS was gone for exactly that instant Ten seconds of journal, reconstructed: 06:49:44 apt-daily-upgrade.service starts 06:49:53 "Reexecution requested ... (unit apt-daily-upgrade.service)" 06:49:53 systemd reexecuting (it had just upgraded itself) 06:49

Most nginx misconfigurations announce themselves. You typo a directive, nginx -t fails, you fix it. That feedback loop is fast and it works. The dangerous ones are different. The config is valid. nginx -t passes. The server starts, serves traffic, logs nothing unusual. And the thing you configured is quietly not happening. I maintain gixy-ng , a static analyzer for nginx configs. A growing share of its checks exist for exactly this category, because it turns out static analysis is the only practical way to catch a failure that produces no signal at runtime. Here are four worth knowing about. 1. OCSP stapling that staples nothing server { listen 443 ssl ; server_name example.com ; ssl_certificate /etc/ssl/example.com.pem ; ssl_certificate_key /etc/ssl/example.com.key ; ssl_stapling on ; ssl_stapling_verify on ; } Looks right. It does nothing. OCSP stapling means nginx fetches the certificate's revocation status from the CA itself and attaches it to the handshake, so the client does not have to. To do that, nginx has to make an outbound request to a hostname. nginx does not use the system resolver for runtime lookups. It has its own, and it only exists if you configure it. No resolver in scope means the hostname never resolves, the fetch never happens, and stapling is silently skipped. Your config test passes. Your clients go do their own OCSP lookups, which is the exact thing you turned stapling on to avoid. resolver 127.0 .0.1 valid=300s ipv6=off ; resolver_timeout 5s ; Use a local resolver or your cloud provider's internal DNS. Pointing this at 8.8.8.8 sends every internal lookup off your network in cleartext, which is its own problem. Check it with: echo | openssl s_client -connect example.com:443 \ -servername example.com -status 2>/dev/null \ | grep -A 17 'OCSP response' Working stapling prints OCSP Response Status: successful . Broken stapling prints no response sent . Run it twice, since the first handshake after a reload usually goes out unstapled while the f

Runbooks still say "renew the SSL certificate" when the browser warning is obsolete protocol . The certificate can be brand new. The tunnel is still TLS 1.0. This is a shortened English note. The tables, handshake diagram, and OpenSSL CLI checks live on the original post: https://sunshout.tistory.com/2206 SSL vs TLS (the only distinction that matters) SSL is a Netscape protocol from the 1990s. SSL 3.0 is withdrawn (POODLE and friends). What every browser speaks now is TLS , currently 1.2 or 1.3. People still say "SSL cert" because vendors sold that phrase. The file is an X.509 certificate. The handshake that uses it is TLS. SSL TLS Who Netscape IETF Versions you might still see 2.0 / 3.0 (disable) 1.0 / 1.1 (disable), 1.2 / 1.3 (use) Status Forbidden Required If a ticket says "SSL is broken", translate it to: which TLS version did the handshake negotiate, and which cipher? The tunnel only has three jobs Confidentiality — encryption so a tap does not yield plaintext. Integrity — a MAC (today: AEAD) so a MITM cannot flip bits unnoticed. Authentication — the certificate binds this hostname to a key a CA will vouch for. https is that tunnel. It is not "the lock icon means the page is safe to click." It means the bits on the wire are for that name, encrypted, and unmodified. XSS and a malicious origin are a different layer. The outage that is not the certificate Symptom: new Let's Encrypt leaf, browsers still scream obsolete TLS or refuse the handshake on phones. Cause: nginx/Apache/openssl still allow TLS 1.0/1.1, or the server has no 1.2+. Renewing the cert does nothing. Check, do not guess: # must fail openssl s_client -connect example.com:443 -tls1 # must work openssl s_client -connect example.com:443 -tls1_2 nginx: ssl_protocols TLSv1.2 TLSv1.3 ; ssl_prefer_server_ciphers off ; Keep TLS 1.2 next to 1.3 if you still have old Android or old Java. New services can prefer 1.3. What to put in the cipher line Key exchange: ECDHE (forward secrecy). Static RSA key exchange

ImgProxy is an open-source image-processing server — resize, convert, and transform images on the fly via URL parameters, ideal as a caching layer in front of a CDN or web app. This guide builds ImgProxy from source on Ubuntu, runs it as a systemd service behind Nginx with TLS, walks through its URL processing options, and secures it with signed URLs. Prerequisites: an Ubuntu server, a domain A record (e.g. imgproxy.example.com ), non-root sudo user. Install ImgProxy ImgProxy uses libvips for image processing; this builds it from source with Go. $ sudo add-apt-repository ppa:dhor/myway $ sudo apt update $ sudo apt install libvips-dev -y $ sudo snap install --classic --channel = latest/stable go $ git clone https://github.com/imgproxy/imgproxy.git $ cd imgproxy $ sudo CGO_LDFLAGS_ALLOW = "-s|-w" go build -o /usr/local/bin/imgproxy Create the environment config: $ sudo touch /usr/local/bin/imgproxy.env $ sudo nano /usr/local/bin/imgproxy.env IMGPROXY_BIND = :8080 IMGPROXY_NETWORK = tcp IMGPROXY_READ_TIMEOUT = 10 IMGPROXY_WRITE_TIMEOUT = 10 IMGPROXY_WORKERS = 2 IMGPROXY_REQUESTS_QUEUE_SIZE = 0 IMGPROXY_QUALITY = 100 IMGPROXY_PREFERRED_FORMATS = webp,jpeg,png,gif,avif IMGPROXY_LOG_FORMAT = "pretty" IMGPROXY_LOG_LEVEL = "INFO" IMGPROXY_WATERMARK_URL = https://example.com/watermark.png IMGPROXY_WATERMARK_OPACITY = 1 Key settings: IMGPROXY_WORKERS should be ~2× your vCPU count; IMGPROXY_REQUESTS_QUEUE_SIZE=0 means unlimited queueing; IMGPROXY_WATERMARK_URL points at whatever image you want overlaid when watermarking is enabled. Point ImgProxy at the config and test: $ export IMGPROXY_ENV_LOCAL_FILE_PATH = /usr/local/bin/imgproxy.env $ cd $ imgproxy WARNING [2024-05-28T00:40:42Z] No keys defined, so signature checking is disabled WARNING [2024-05-28T00:40:42Z] No salts defined, so signature checking is disabled INFO [2024-05-28T00:40:42Z] Starting server at :8080 Stop it with Ctrl+C once verified, then set it up as a service. Run ImgProxy as a systemd Service $ sudo useradd

Gradio is a Python library for wrapping any ML model in a web interface, ready to deploy and scale as an app. This guide builds a GFPGAN-powered face-restoration demo with Gradio on Ubuntu 22.04, runs it as a systemd service, and exposes it through Nginx with TLS. Prerequisites: a GPU-enabled Ubuntu 22.04 server, a domain A record (e.g. gradio.example.com ), non-root sudo access, Nginx installed. Set Up the Server 1. Install dependencies: $ pip3 install realesrgan gfpgan basicsr gradio realesrgan — background restoration gfpgan — face restoration basicsr — provides RRDBNet , the super-resolution architecture GFPGAN relies on gradio — the web interface 2. GFPGAN's pandas dependency needs jinja2 >= 3.1.2: $ pip show jinja2 Upgrade if it's older: $ pip install --upgrade jinja2 3. Create the project directory: $ sudo mkdir -p /opt/gradio-webapp/ $ sudo chown -R : $( id -gn ) /opt/gradio-webapp/ $ sudo chmod -R 775 /opt/gradio-webapp/ Build the Gradio App Uploads a face image and returns two enhanced outputs. $ cd /opt/gradio-webapp/ $ nano app.py import gradio as gr from gfpgan import GFPGANer from basicsr.archs.rrdbnet_arch import RRDBNet from realesrgan import RealESRGANer import numpy as np import cv2 import requests def enhance_image ( input_image ): arch = ' clean ' model_name = ' GFPGANv1.4 ' gfpgan_checkpoint = ' https://github.com/TencentARC/GFPGAN/releases/download/v1.3.4/GFPGANv1.4.pth ' realersgan_checkpoint = ' https://github.com/xinntao/Real-ESRGAN/releases/download/v0.2.1/RealESRGAN_x2plus.pth ' rrdbnet = RRDBNet ( num_in_ch = 3 , num_out_ch = 3 , num_feat = 64 , num_block = 23 , num_grow_ch = 32 , scale = 2 ) bg_upsampler = RealESRGANer ( scale = 2 , model_path = realersgan_checkpoint , model = rrdbnet , tile = 400 , tile_pad = 10 , pre_pad = 0 , half = True ) restorer = GFPGANer ( model_path = gfpgan_checkpoint , upscale = 2 , arch = arch , channel_multiplier = 2 , bg_upsampler = bg_upsampler ) input_image = input_image . astype ( np . uint8 ) cropped_fa

Nginx UI is an open-source web GUI for managing Nginx, single-node or clustered, with real-time stats, automatic Let's Encrypt TLS, performance monitoring, and even LLM-assisted config editing. This guide installs it on Ubuntu 24.04, puts it behind a reverse proxy with TLS, sets up ACME certificate management, and creates a virtual host through the dashboard. Prerequisites: an Ubuntu 24.04 server, non-root sudo user, a domain A record (e.g. nginx-ui.example.com ), Docker installed if you choose that install path. $ sudo apt update $ sudo apt install nginx -y Pick one of the two install methods below. Option A: Install via Script Runs Nginx UI as a system service, managing the host's Nginx directly. $ curl -O https://cloud.nginxui.com/install.sh $ sudo bash install.sh install $ nginx-ui --version $ sudo systemctl start nginx-ui $ sudo systemctl status nginx-ui Option B: Install via Docker Runs as a container — you won't be able to edit the host's Nginx configs directly through it. $ mkdir -p ~/nginx-ui-docker $ cd ~/nginx-ui-docker $ sudo mkdir -p /opt/nginx-ui/nginx $ sudo mkdir -p /opt/nginx-ui/config $ sudo mkdir -p /opt/nginx-ui/www $ nano docker-compose.yml version : ' 3.8' services : nginx-ui : image : uozi/nginx-ui:latest container_name : nginx-ui restart : always environment : - TZ=UTC volumes : - /opt/nginx-ui/nginx:/etc/nginx - /opt/nginx-ui/config:/etc/nginx-ui - /opt/nginx-ui/www:/var/www ports : - " 127.0.0.1:9000:80" networks : - nginx-ui-net networks : nginx-ui-net : driver : bridge $ sudo docker compose up -d $ sudo docker compose ps $ curl -X GET http://localhost:9000 Configure the Reverse Proxy Nginx UI listens on localhost:9000 . Put it behind a public vhost with WebSocket support (needed for live stats/terminal): $ cd /etc/nginx/sites-available $ sudo nano nginx-ui.conf map $http_upgrade $connection_upgrade { default upgrade ; '' close ; } server { listen 80 ; listen [::]:80 ; server_name nginx-ui.example.com ; location / { proxy_set_header Host $

Laravel is a popular PHP framework with routing, authentication, and database management built in. This guide deploys a Laravel app behind Nginx on Ubuntu 24.04, wires it to MySQL, secures it with Let's Encrypt, and builds a small dashboard that queries live data. Prerequisites: Ubuntu 24.04 with Nginx and MySQL installed, a non-root sudo user, a domain A record (e.g. app.example.com ). Create the Database $ sudo mysql mysql > CREATE DATABASE laravel_demo ; mysql > CREATE USER 'laravel_user' @ 'localhost' IDENTIFIED WITH mysql_native_password BY 'secure_password' ; mysql > GRANT ALL ON laravel_demo . * TO 'laravel_user' @ 'localhost' ; mysql > FLUSH PRIVILEGES ; mysql > EXIT ; Seed a demo table to query later: $ mysql -u laravel_user -p mysql > USE laravel_demo ; mysql > CREATE TABLE server_stats ( id INT AUTO_INCREMENT , server_name VARCHAR ( 255 ), region VARCHAR ( 255 ), cpu_usage DECIMAL ( 5 , 2 ), memory_usage DECIMAL ( 5 , 2 ), status ENUM ( 'active' , 'maintenance' , 'offline' ), last_updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP , PRIMARY KEY ( id ) ); mysql > INSERT INTO server_stats ( server_name , region , cpu_usage , memory_usage , status ) VALUES ( 'app-01' , 'us-east' , 24 . 50 , 45 . 30 , 'active' ), ( 'db-01' , 'eu-west' , 12 . 75 , 78 . 20 , 'active' ), ( 'web-01' , 'ap-south' , 65 . 80 , 89 . 50 , 'active' ); mysql > EXIT ; Install Composer and PHP Extensions $ sudo apt update $ sudo apt install composer php php-curl php-fpm php-bcmath php-json php-mysql php-mbstring php-xml php-tokenizer php-zip -y $ composer --version $ php --version $ sudo systemctl restart php8.3-fpm php-fpm runs PHP as a service Nginx can talk to; php-mysql / php-mbstring / php-xml / php-tokenizer / php-zip cover Laravel's runtime requirements. Create the Laravel Project $ cd ~ $ composer create-project --prefer-dist laravel/laravel laravel-demo $ cd laravel-demo $ php artisan key:generate Edit .env : $ nano .env APP_NAME = laravel-demo APP_ENV = development APP_KEY = base64:APP

🇧🇷 Leia a versão em português aqui In previous parts of this series, we built the cluster from scratch: prepared the environment (Part 1), installed containerd and Kubernetes (Part 2), initialized the control-plane (Part 3), and joined the workers (Part 4). With the cluster up and all nodes in Ready state, it's time to actually put it to work: let's deploy our first application. In this article, we'll use Nginx as an example — a classic use case for validating that the cluster is working end to end, from pod creation to service exposure. Organizing the files First, create a directory to organize this deployment's manifests: mkdir nginx cd nginx Keeping Kubernetes manifests organized in per-application directories is a good practice that makes maintenance and versioning (e.g., with Git) easier as the cluster grows. Creating the Deployment A Deployment is the Kubernetes object responsible for managing pod replicas, ensuring the desired number of instances is always running — and handling things like rolling updates and automatic recovery in case of failure. Create the file nginx-deployment.yaml with the following content: apiVersion : apps/v1 kind : Deployment metadata : name : nginx-deployment labels : app : nginx spec : replicas : 2 selector : matchLabels : app : nginx template : metadata : labels : app : nginx spec : containers : - name : nginx image : nginx:1.14.0 ports : - containerPort : 80 This manifest defines: 2 replicas of the Nginx pod ( replicas: 2 ), distributed across the available workers; A selector that ties the Deployment to the pods via the app: nginx label; The nginx:1.14.0 image, exposing container port 80 . Applying the Deployment With the file saved, apply it to the cluster: kubectl apply -f nginx-deployment.yaml kubectl will create the Deployment, and from there Kubernetes takes care of scheduling the 2 pods across the available workers. Checking the Deployment To confirm the Deployment was created and has the desired number of replicas running

The Problem When you put RabbitMQ's Management UI behind an nginx reverse proxy under a sub-path like /rabbitmq/ , queue detail pages and many API calls break silently. The root cause: nginx normalizes the request URI before proxying. It decodes %2F (the URL-encoded forward slash) into a literal / . RabbitMQ's Management API uses %2F to represent the default virtual host ( / ) in API paths: GET /api/queues/%2F/my-queue When nginx decodes it: GET /api/queues///my-queue ← broken What Doesn't Work The common advice of using merge_slashes off or a rewrite directive doesn't fully solve this because nginx still normalizes $uri before forwarding. The Fix Use $request_uri inside an if block. Unlike $uri , $request_uri holds the raw, undecoded URI exactly as the client sent it — nginx never touches it. nginx # RabbitMQ: API paths — use $request_uri to preserve %2F (never decoded by nginx) location ~* ^/rabbitmq/api/ { if ($request_uri ~* "^/rabbitmq/(.*)") { proxy_pass http://rabbitmq:15672/$1; } proxy_buffering off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; } # RabbitMQ: general UI (JS, CSS, static assets, non-API pages) location ~* ^/rabbitmq/ { rewrite ^/rabbitmq/(.*)$ /$1 break; proxy_pass http://rabbitmq:15672; proxy_buffering off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; }

nginx Event Loop — Complete Lifecycle Reference A precise, bottom-up reference covering every buffer, syscall, interrupt, and data movement from the moment a TCP packet hits the NIC to the moment a response is sent back. Two concurrent users are used throughout as a concrete example. Table of Contents Foundations — fd and Socket Hardware Layer — NIC, DMA, Interrupts Kernel Structures and All Buffers epoll — How the Worker Waits Efficiently nginx Startup Sequence Complete Request Lifecycle — Two Concurrent Users What Happens While Worker is Busy All Buffers — Master Reference All Syscalls — Master Reference Failure Modes 1. Foundations 1.1 Everything is a File Linux's core philosophy: every I/O resource — files on disk, network connections, pipes, terminals, devices — is represented as a file. This means one unified API ( read , write , close ) works on all of them. The kernel manages the actual resource. Your process holds a token. 1.2 File Descriptor (fd) A file descriptor is just an integer . It is a per-process token that refers to a kernel-managed resource. The kernel maintains a table per process called the fd table — a simple array where the index is the fd and the value is a pointer into the kernel. Process fd table: ┌─────┬───────────────────────────────┐ │ fd │ points to │ ├─────┼───────────────────────────────┤ │ 0 │ stdin │ │ 1 │ stdout │ │ 2 │ stderr │ │ 3 │ listen socket (nginx) │ │ 5 │ User A client connection │ │ 6 │ User B client connection │ │ 12 │ backend connection for User A │ │ 13 │ backend connection for User B │ └─────┴───────────────────────────────┘ 0, 1, 2 are always pre-assigned. Application fds start from 3 upward. The fd is meaningless on its own. It only means something when passed to a syscall — the kernel uses it to look up the real resource. 1.3 Socket A socket is the kernel's internal data structure representing one end of a network connection. Created when your process calls socket() . Lives entirely in kernel RAM. Your process nev

The Cloud Native Computing Foundation has highlighted a new AI-assisted migration approach that enabled engineers to migrate 60 ingress-nginx resources to Higress in roughly 30 minutes, demonstrating how artificial intelligence is increasingly being applied to modernize Kubernetes networking and gateway infrastructure. By Craig Risi