{"id":21255,"date":"2026-09-02T08:35:33","date_gmt":"2026-09-02T06:35:33","guid":{"rendered":"https:\/\/webhosting.de\/nginx-rate-limiting-schutz-vor-bot-traffic-angriffen-secure\/"},"modified":"2026-09-02T08:35:33","modified_gmt":"2026-09-02T06:35:33","slug":"nginx-hastighetsbegraensning-skydd-mot-bot-trafikattacker-saeker","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/nginx-rate-limiting-schutz-vor-bot-traffic-angriffen-secure\/","title":{"rendered":"NGINX Rate Limiting: Effektivt skydd mot bottrafik och attacker"},"content":{"rendered":"<p><strong>NGINX-hastighet<\/strong> Limiting stoppar automatiserade f\u00f6rfr\u00e5gningar, d\u00e4mpar toppbelastningar och skyddar inloggnings-, API- och formul\u00e4r\u00e4ndpunkter mot botar och attacker. Jag visar dig hur du definierar gr\u00e4nsv\u00e4rden och anv\u00e4nder dem f\u00f6r <strong>Skydd mot botar<\/strong> anv\u00e4nder och utifr\u00e5n detta utformar ett robust s\u00e4kerhetskoncept f\u00f6r v\u00e4lbes\u00f6kta webbplatser.<\/p>\n\n<h2>Centrala punkter<\/h2>\n\n<p><strong>V\u00e4sentligt<\/strong> Dessa \u00e4r de viktigaste budskapen:<\/p>\n<ul>\n  <li><strong>Gr\u00e4nsv\u00e4rden f\u00f6r priser<\/strong> f\u00f6rhindrar skadliga attacker och skyddar backend-resurserna.<\/li>\n  <li><strong>Burst\/utan f\u00f6rdr\u00f6jning<\/strong> f\u00e5ngar upp legitima toppar utan att blockera anv\u00e4ndare.<\/li>\n  <li><strong>Zoner<\/strong> skilja mellan m\u00e4nniskor och botar med olika gr\u00e4nser.<\/li>\n  <li><strong>Loggning<\/strong> tillhandah\u00e5ller data f\u00f6r att iterativt sk\u00e4rpa gr\u00e4nserna.<\/li>\n  <li><strong>Integration<\/strong> med WAF, DDoS-skydd och \u00f6vervakning \u00f6kar effektiviteten.<\/li>\n<\/ul>\n\n<h2>Varf\u00f6r rate limiting stoppar attacker i ett tidigt skede<\/h2>\n\n<p>Angriparna satsar p\u00e5 h\u00f6ga <strong>Beg\u00e4ranfrekvenser<\/strong>, f\u00f6r att missbruka inloggningsformul\u00e4r, \u00f6verbelasta API:er eller automatiskt skrapa inneh\u00e5ll. D\u00e4rf\u00f6r begr\u00e4nsar jag antalet f\u00f6rfr\u00e5gningar per nyckel \u2013 oftast per IP-adress \u2013 och avg\u00f6r om jag ska begr\u00e4nsa dem, f\u00f6rdr\u00f6ja dem eller svara med 429. P\u00e5 s\u00e5 s\u00e4tt h\u00e5ller jag bort bottrafik fr\u00e5n CPU, databasen och applikationslogiken och sl\u00e4pper igenom legitima anv\u00e4ndare. S\u00e4rskilt k\u00e4nsliga s\u00f6kv\u00e4gar som \/login, \/auth, \/xmlrpc.php eller resurskr\u00e4vande s\u00f6kningar gynnas av detta. K\u00e4llan till denna metod \u00e4r <strong>Nginx-dokumentation<\/strong> om ngx_http_limit_req_module.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-rate-limiting-rechenzentrum-4738.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hur NGINX-modulen fungerar i praktiken<\/h2>\n\n<p>Modulen fungerar enligt principen <strong>L\u00e4ckande skopa<\/strong>-Princip: F\u00f6r varje nyckel lagrar NGINX r\u00e4knarv\u00e4rden i en zon och j\u00e4mf\u00f6r dem med den till\u00e5tna hastigheten. Typiska nycklar \u00e4r $binary_remote_addr f\u00f6r IP-adresser, token f\u00f6r API-nycklar eller h\u00e4rledda v\u00e4rden via map. Om en klient kontinuerligt \u00f6verskrider hastigheten och burst-bufferten avvisar NGINX beg\u00e4ran innan den n\u00e5r backend. Detta sparar ber\u00e4kningstid och minskar f\u00f6rdr\u00f6jningarna f\u00f6r riktiga bes\u00f6kare. Jag st\u00e4ller in reaktionen p\u00e5 429 Too Many Requests eller valfritt en annan <strong>Statuskod<\/strong> um.<\/p>\n\n<h2>Konfiguration: F\u00f6rklarat steg f\u00f6r steg<\/h2>\n\n<p>Jag b\u00f6rjar med en zon i http-sektionen, st\u00e4ller in en m\u00e5ttlig hastighet och aktiverar den selektivt p\u00e5 k\u00e4nsliga v\u00e4gar. F\u00f6r kortvariga toppar definierar jag en burst, eventuellt med nodelay, f\u00f6r att undvika pl\u00f6tsliga avvisningar. D\u00e4refter testar jag i stagingmilj\u00f6n och utv\u00e4rderar loggarna innan jag aktiverar den i produktionsmilj\u00f6n. P\u00e5 s\u00e5 s\u00e4tt riskerar jag inte on\u00f6diga sp\u00e4rrar f\u00f6r riktiga anv\u00e4ndare. Ett kortfattat exempel illustrerar detta <strong>Syntax<\/strong> p\u00e5taglig:<\/p>\n\n<pre><code># http {}\nlimit_req_zone $binary_remote_addr zone=req_limit_per_ip:10m rate=10r\/s;\n\nserver {\n  location \/api\/ {\n    limit_req zone=req_limit_per_ip burst=20 nodelay;\n    limit_req_status 429;\n  }\n\n  location \/login {\n    limit_req zone=req_limit_per_ip burst=5;\n    limit_req_status 429;\n  }\n}\n<\/code><\/pre>\n\n<h2>Botskydd med zoner och User-Agent-logik<\/h2>\n\n<p>IP-baserade begr\u00e4nsningar r\u00e4cker s\u00e4llan mot distribuerade botn\u00e4t, d\u00e4rf\u00f6r delar jag upp trafiken i <strong>Zoner<\/strong>: M\u00e4nniskor tilldelas gener\u00f6sare v\u00e4rden, medan generiska s\u00f6krobotar f\u00e5r str\u00e4ngare. Med map utv\u00e4rderar jag anv\u00e4ndaragenter, identifierar godk\u00e4nda botar som Googlebot och tilldelar dem egna, noggrant \u00f6vervakade gr\u00e4nser. F\u00f6r ok\u00e4nda skrapare s\u00e4tter jag h\u00e5rda gr\u00e4nser p\u00e5 kostsamma s\u00f6kv\u00e4gar. Om m\u00f6nster uppt\u00e4cks sk\u00e4rper jag kraven dynamiskt tills <strong>Pris<\/strong> \u00e5terigen ligger inom det normala intervallet.<\/p>\n\n<h2>Finjustering: hastighet, burst, nodelay och statuskoder<\/h2>\n\n<p>Rate styr genomstr\u00f6mningen per sekund, Burst till\u00e5ter kortvariga buffringar och nodelay avg\u00f6r om jag f\u00f6redrar buffring eller omedelbar vidarebefordran. Jag b\u00f6rjar f\u00f6rsiktigt, t.ex. 10 r\/s med burst 20 p\u00e5 API:er, och finjusterar sedan utifr\u00e5n logganalysen. F\u00f6r inloggningsrutter st\u00e4ller jag t.ex. in 1 r\/s med liten burst f\u00f6r att bromsa brute-force-attacker. Vid \u00f6verskridanden returnerar jag 429, eftersom klienter d\u00e5 <strong>klara av<\/strong> och att Retry-logiken fungerar som den ska. I s\u00e4rskilda fall anv\u00e4nder jag alternativa koder om klienterna beg\u00e4r det.<\/p>\n\n<h2>\u00d6versikt i tabellen: Riktlinjer och till\u00e4mpning<\/h2>\n\n<p>F\u00f6ljande <strong>Tabell<\/strong> sammanfattar centrala riktlinjer och visar n\u00e4r de \u00e4r l\u00e4mpliga.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>direktiv<\/th>\n      <th>Effekt<\/th>\n      <th>Exempel<\/th>\n      <th>Typisk anv\u00e4ndning<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>limit_req_zone<\/td>\n      <td>Ange nyckel, zon och <strong>Pris<\/strong> fast<\/td>\n      <td>limit_req_zone $binary_remote_addr zone=perip:10m rate=10r\/s;<\/td>\n      <td>Grundbelopp per IP-adress, token eller anv\u00e4ndaragent<\/td>\n    <\/tr>\n    <tr>\n      <td>limit_req<\/td>\n      <td>Aktiverar gr\u00e4nsen i <strong>Plats<\/strong>\/Server<\/td>\n      <td>limit_req zone=perip burst=20 nodelay;<\/td>\n      <td>Finjustering per s\u00f6kv\u00e4g eller vHost<\/td>\n    <\/tr>\n    <tr>\n      <td>limit_req_status<\/td>\n      <td>L\u00e4gger till HTTP-kod <strong>\u00d6verskridande<\/strong><\/td>\n      <td>limit_req_status 429;<\/td>\n      <td>Korrekt klientbeteende och nya f\u00f6rs\u00f6k<\/td>\n    <\/tr>\n    <tr>\n      <td>karta<\/td>\n      <td>Vidarebefordrar f\u00f6rfr\u00e5gningar till <strong>Zoner<\/strong> p\u00e5<\/td>\n      <td>map $http_user_agent $is_bot {\u2026}<\/td>\n      <td>\u00c5tskillnad mellan bot och m\u00e4nniska utifr\u00e5n User-Agent<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/NGINXLimitingMeeting1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>I praktiken: Skydda inloggningspunkten p\u00e5 ett m\u00e5linriktat s\u00e4tt<\/h2>\n\n<p>Jag begr\u00e4nsar \/login mycket strikt, eftersom botar provar l\u00f6senord med h\u00f6g <strong>Frekvens<\/strong> Testa dig fram. 1 f\u00f6rfr\u00e5gan per sekund med burst 3 f\u00f6rhindrar massiv gissning utan att drabba riktiga anv\u00e4ndare f\u00f6r h\u00e5rt. Dessutom loggar jag upprepade misslyckade inloggningsf\u00f6rs\u00f6k f\u00f6r att tillf\u00e4lligt sp\u00e4rra IP-adresser. I kombination med tv\u00e5faktorsautentisering (2FA) och valfritt Captcha minskar belastningen p\u00e5 databasen och sessionshanteringen m\u00e4rkbart. P\u00e5 s\u00e5 s\u00e4tt h\u00e5ller jag antalet misslyckade inloggningsf\u00f6rs\u00f6k p\u00e5 en l\u00e5g niv\u00e5 och s\u00e4kerst\u00e4ller att <strong>Tillg\u00e5ng<\/strong> redo och stabil.<\/p>\n\n<h2>I praktiken: Tillhandah\u00e5lla API:er p\u00e5 ett r\u00e4ttvist och kontrollerat s\u00e4tt<\/h2>\n\n<p>API:er kr\u00e4ver tydliga <strong>Odds<\/strong>, s\u00e5 att enskilda klienter inte tar upp hela bandbredden. F\u00f6r allm\u00e4nna rutter st\u00e4ller jag in 10r\/s och burst 20, f\u00f6r kostsamma slutpunkter str\u00e4ngare v\u00e4rden. Om tokens eller API-nycklar finns tillg\u00e4ngliga begr\u00e4nsar jag per token ist\u00e4llet f\u00f6r per IP-adress. Detta skapar r\u00e4ttvisa mellan kunderna och f\u00f6rhindrar missbruk. En mer ing\u00e5ende beskrivning finns i min anm\u00e4rkning om <a href=\"https:\/\/webhosting.de\/sv\/api-rate-limiting-hosting-skydd-mot-missbruk-saekerhet\/\">API-begr\u00e4nsning av antalet f\u00f6rfr\u00e5gningar<\/a>, som ger en bredare inramning av begreppet.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-rate-limiting-security-5721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>\u00d6vervakning, loggning och iterativ finjustering<\/h2>\n\n<p>Jag loggar 429-svar inklusive <strong>Nyckel<\/strong> (t.ex. IP-adress eller token) och s\u00f6kv\u00e4g f\u00f6r att uppt\u00e4cka m\u00f6nster. Pl\u00f6tsliga toppar p\u00e5 ett f\u00e5tal s\u00f6kv\u00e4gar tyder p\u00e5 webbskrapning eller brute-force-attacker; en j\u00e4mnt f\u00f6rdelad belastning tyder p\u00e5 botn\u00e4t. Med hj\u00e4lp av dessa data s\u00e4tter jag gr\u00e4nser endast d\u00e4r det \u00e4r n\u00f6dv\u00e4ndigt och minimerar antalet falska positiva resultat. Dashboards med frekvens, felprocent och latens visar mig effekten av varje \u00e4ndring. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir <strong>Prestanda<\/strong> h\u00f6g, samtidigt som skyddet \u00f6kar.<\/p>\n\n<h2>Integrering i ett helhetsinriktat skyddskoncept<\/h2>\n\n<p>Jag anser att Rate Limiting \u00e4r ett starkt f\u00f6rsta steg <strong>skikt<\/strong>, men jag kombinerar det med WAF-regler, IP-reputation och TLS-h\u00e4rdning. Mot volymattacker hj\u00e4lper ett uppstr\u00f6ms DDoS-skydd som filtrerar trafiken p\u00e5 n\u00e4tverksniv\u00e5 innan NGINX beh\u00f6ver tr\u00e4da in. Jag m\u00e4ter kontinuerligt nyckeltal, st\u00e4ller in larm vid ovanliga toppar och reagerar med regeluppdateringar. P\u00e5 s\u00e5 s\u00e4tt skapas ett robust skyddsn\u00e4tverk av flera byggstenar. Dessa ger en praktisk \u00f6versikt <a href=\"https:\/\/webhosting.de\/sv\/ddos-mitigation-webbhotell-strategier-skydd-naetverk\/\">DDoS-strategier<\/a>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx_schutz_tech_office_6352.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Konkreta konfigurationsm\u00f6nster f\u00f6r botar j\u00e4mf\u00f6rt med m\u00e4nniskor<\/h2>\n\n<p>Jag delar upp bes\u00f6karna i kategorier med hj\u00e4lp av map och h\u00e4nvisar dem till egna <strong>Zoner<\/strong>. K\u00e4nda s\u00f6krobotar tilldelas m\u00e5ttliga gr\u00e4nser, medan generiska agenter f\u00e5r str\u00e4ngare gr\u00e4nser. F\u00f6r s\u00f6kv\u00e4gar som \/search eller \/report \u00e4r jag str\u00e4ngare, eftersom de tar upp mycket CPU-kapacitet. Vid \u00e5terkommande \u00f6vertr\u00e4delser h\u00f6jer jag inte gr\u00e4nserna, utan sp\u00e4rrar tillf\u00e4lligt eller flyttar kontrollen till en botdetekteringsmodul. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir <strong>Andel missbruk<\/strong> l\u00e5g, utan att st\u00f6ra s\u00f6kmotorerna.<\/p>\n\n<h2>Exempel: Tv\u00e5 zoner och mappning av anv\u00e4ndaragenter<\/h2>\n\n<p>F\u00f6ljande utdrag visar uppdelningen enligt <strong>Anv\u00e4ndaragent<\/strong> och tilldelning av l\u00e4mpliga gr\u00e4nsv\u00e4rden. Jag kombinerar detta med differentierade statuskoder och loggningsf\u00e4lt f\u00f6r att kunna m\u00e4ta effekten p\u00e5 ett tydligt s\u00e4tt. Botar med generiska agenter hamnar i den strikta zonen. M\u00e4nniskor eller verifierade s\u00f6krobotar anv\u00e4nder den mer flexibla zonen. Denna metod ger f\u00f6ruts\u00e4gbara <strong>Genomstr\u00f6mning<\/strong> per klass:<\/p>\n\n<pre><code>map $http_user_agent $is_bot {\n  default 0;\n  \"~*googlebot\"     0;\n  \"~*bingbot\" 0;\n  \"~*crawler|scraper|bot\" 1;\n}\n\nlimit_req_zone $binary_remote_addr zone=human:10m rate=10r\/s;\nlimit_req_zone $binary_remote_addr zone=bot:10m   rate=1r\/s;\n\nserver {\n  location \/ {\n    if ($is_bot) {\n limit_req zone=bot burst=5;\n    }\n    if ($is_bot = 0) {\n limit_req zone=human burst=20 nodelay;\n    }\n    limit_req_status 429;\n  }\n}\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx_rate_limiting_schutz_3947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Felhantering: Att kommunicera 429 p\u00e5 r\u00e4tt s\u00e4tt<\/h2>\n\n<p>Hos Limits ger jag ett tydligt <strong>Svar<\/strong> med information om n\u00e4r det \u00e4r l\u00e4mpligt att g\u00f6ra ett nytt f\u00f6rs\u00f6k. F\u00f6r API:er ing\u00e5r den giltiga Retry-After-headern, s\u00e5 att klienterna kan till\u00e4mpa backoff. M\u00e4nskliga anv\u00e4ndare f\u00e5r en kort f\u00f6rklaring utan tekniska detaljer. Detta minskar antalet support\u00e4renden och s\u00e4kerst\u00e4ller ett begripligt beteende. En tydlig <strong>UX<\/strong> g\u00f6r gr\u00e4nser acceptabla och f\u00f6rhindrar frustration.<\/p>\n\n<h2>Webbhotell, n\u00e4tverk och k\u00e4rna: st\u00e4rka grunden<\/h2>\n\n<p>H\u00f6g legitim trafik och skydds\u00e5tg\u00e4rder kr\u00e4ver tillf\u00f6rlitliga <strong>Resurser<\/strong> och l\u00e4mpliga standardinst\u00e4llningar p\u00e5 n\u00e4tverksniv\u00e5. Jag ser till att anv\u00e4nda aktuella NGINX-versioner, att det finns tillr\u00e4ckligt med RAM-minne f\u00f6r zonerna och att skyddsfunktioner mot transportattacker finns p\u00e5 plats. F\u00f6r att skydda mot SYN-\u00f6versv\u00e4mningar hj\u00e4lper det att aktivera <a href=\"https:\/\/webhosting.de\/sv\/tcp-syn-cookies-skydd-mot-syn-oeversvaemning-kaernan\/\">TCP SYN-cookies<\/a> i k\u00e4rnan, s\u00e5 att anslutningar inte fastnar. Sammantaget avlastar detta NGINX fr\u00e5n on\u00f6dig belastning. P\u00e5 s\u00e5 s\u00e4tt fokuserar jag begr\u00e4nsningarna p\u00e5 HTTP-niv\u00e5erna och h\u00e5ller <strong>Genomstr\u00f6mning<\/strong> stabil.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-ratelimit-schutz-4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>I korthet: S\u00e5 h\u00e4r anv\u00e4nder jag NGINX:s hastighetsbegr\u00e4nsning p\u00e5 ett effektivt s\u00e4tt<\/h2>\n\n<p>Jag begr\u00e4nsar f\u00f6rfr\u00e5gningarna per <strong>nyckel<\/strong>, skydda kritiska v\u00e4gar och h\u00e5ll bots p\u00e5 avst\u00e5nd med strikta zoner. Burst och nodelay hj\u00e4lper till att till\u00e5ta legitima trafiktoppar utan att fr\u00e4mja missbruk. Med hj\u00e4lp av 429-loggar kalibrerar jag v\u00e4rdena l\u00f6pande och sk\u00e4rper gr\u00e4nserna endast d\u00e4r det beh\u00f6vs. I kombination med WAF, DDoS-skydd, \u00f6vervakning och k\u00e4rnh\u00e4rdning skapas ett robust skyddskoncept. Den som konsekvent implementerar detta minskar bottrafiken avsev\u00e4rt och bevarar <strong>Prestanda<\/strong> \u00e4ven under belastning.<\/p>\n\n<h2>Komponenter som ofta saknas i praktiken<\/h2>\n\n<p>I m\u00e5nga konfigurationer saknas n\u00e5gra avg\u00f6rande komponenter som m\u00e4rkbart \u00f6kar effekten av hastighetsbegr\u00e4nsningen:<\/p>\n<ul>\n  <li><strong>Den verkliga klient-IP-adressen bakom proxyservrar<\/strong>: Utan korrekt hantering av Real-IP begr\u00e4nsar NGINX ofta lastbalanseraren IP-adress \u2013 begr\u00e4nsningarna g\u00e4ller d\u00e5 f\u00f6r alla anv\u00e4ndare som \u00e4r sammanbundna bakom den.<\/li>\n  <li><strong>Torrtester (Dry-Run)<\/strong>: Gr\u00e4nsv\u00e4rden aktiveras \u201ei blindo\u201c. Det \u00e4r b\u00e4ttre att i f\u00f6rv\u00e4g bara registrera hur ofta ett gr\u00e4nsv\u00e4rde skulle ha tr\u00e4tt i kraft.<\/li>\n  <li><strong>Finkorniga nycklar<\/strong>: Ist\u00e4llet f\u00f6r att endast begr\u00e4nsa antalet IP-adresser \u00e4r det b\u00e4ttre att inf\u00f6ra begr\u00e4nsningar per API-token, session eller anv\u00e4ndare f\u00f6r att \u00f6ka r\u00e4ttvisan.<\/li>\n  <li><strong>Samverkan med limit_conn<\/strong>: Parallella anslutningar och f\u00f6rfr\u00e5gningsfrekvenser t\u00e4cker olika typer av missbruk.<\/li>\n  <li><strong>S\u00e4rskilda undantag<\/strong>: H\u00e4lsokontroller, webhooks eller interna tj\u00e4nster kr\u00e4ver ofta mindre strikta begr\u00e4nsningar eller inga alls.<\/li>\n<\/ul>\n\n<h2>Omv\u00e4nd proxy: s\u00e4ker utv\u00e4rdering av klientens verkliga IP-adress<\/h2>\n\n<p>Om NGINX ligger bakom en lastbalanserare st\u00e4ller jag in Real-IP-direktiven s\u00e5 att $binary_remote_addr \u00e5terspeglar den verkliga klienten. Jag litar bara p\u00e5 n\u00e4tverk som tillh\u00f6r mig och aktiverar rekursiv utv\u00e4rdering:<\/p>\n\n<pre><code>http {\n  # Betrodda proxy-IP-intervall (exempel)\n  set_real_ip_from 10.0.0.0\/8;\n  set_real_ip_from 192.168.0.0\/16;\n  # L\u00e4gg till eventuella offentliga LB-\/CDN-intervall\n\n  real_ip_header X-Forwarded-For;\n  real_ip_recursive on;\n\n  limit_req_zone $binary_remote_addr zone=perip:20m rate=10r\/s;\n}\n<\/code><\/pre>\n\n<p>Utan den h\u00e4r inst\u00e4llningen drabbar en begr\u00e4nsning annars oskyldigt m\u00e5nga anv\u00e4ndare samtidigt. Efter konfigurationen kontrollerar jag i \u00e5tkomstloggarna om den f\u00f6rv\u00e4ntade klient-IP-adressen dyker upp.<\/p>\n\n<h2>Nyckelstrategi: IP, anv\u00e4ndare, token och v\u00e4g<\/h2>\n\n<p>Det valda uppl\u00e4gget avg\u00f6r hur r\u00e4ttvist och effektivt det blir. N\u00e5gra bepr\u00f6vade modeller:<\/p>\n<ul>\n  <li><strong>Pro IP<\/strong> ($binary_remote_addr): Snabbt klart f\u00f6r anv\u00e4ndning, l\u00e4mpligt f\u00f6r \/login och anonyma slutpunkter.<\/li>\n  <li><strong>Per API-token<\/strong>: R\u00e4ttvisa mellan kunderna; skyddar mot NAT-buntning. Jag extraherar token med hj\u00e4lp av map.<\/li>\n  <li><strong>Per banklass<\/strong>: Begr\u00e4nsa dyra slutpunkter separat, t.ex. \/search mer \u00e4n \/status.<\/li>\n<\/ul>\n\n<pre><code>map $http_authorization $api_token {\n  default \"\";\n  \"~*^Bearer\\s+(.+)$\" $1;\n}\n\nlimit_req_zone $api_token zone=per_token:30m rate=5r\/s;\n\nserver {\n  location \/api\/ {\n    # G\u00e4ller endast om ett token finns\n    limit_req zone=per_token burst=10;\n    limit_req_status 429;\n  }\n}\n<\/code><\/pre>\n\n<p>Viktigt: H\u00f6g nyckelkardinalitet f\u00f6rbrukar minne i zonen. Planera in buffertar och \u00f6vervaka minnesanv\u00e4ndningen.<\/p>\n\n<h2>Lagring och dimensionering av zonerna<\/h2>\n\n<p>Zonen lagrar metadata f\u00f6r varje aktiv nyckel. F\u00f6rbrukningen uppg\u00e5r till n\u00e5gra dussin byte per post plus overhead. Av detta drar jag slutsatsen att:<\/p>\n<ul>\n  <li>Om det finns m\u00e5nga samtidiga IP-adresser\/token v\u00e4ljer jag st\u00f6rre zoner, t.ex. 50\u2013100 MB.<\/li>\n  <li>Jag b\u00f6rjar ganska gener\u00f6st och l\u00e4ser NGINX-loggarna: \u201eshared memory zone is full\u201c indikerar att det \u00e4r dags f\u00f6r omsk\u00e4rpning.<\/li>\n  <li>Oanv\u00e4nda nycklar f\u00f6rfaller efter en kort period av inaktivitet; toppv\u00e4rdena \u00e4r viktigare \u00e4n dagsgenomsnittet.<\/li>\n<\/ul>\n\n<h2>Anv\u00e4nda burst och nodelay p\u00e5 ett precist s\u00e4tt<\/h2>\n\n<p>Utan <strong>nodelay<\/strong> NGINX ordnar \u00f6verskridandena i burst-buffertens ordning och <em>f\u00f6rdr\u00f6jd<\/em> F\u00f6rfr\u00e5gningar. Med <strong>nodelay<\/strong> Till\u00e5tna burst-f\u00f6rfr\u00e5gningar sl\u00e4pps igenom omedelbart, medan \u00f6verskottet avvisas. Min metod:<\/p>\n<ul>\n  <li><strong>Interaktiva stigar<\/strong> (HTML): helst utan nodelay, f\u00f6r att skapa korta v\u00e4ntetider ist\u00e4llet f\u00f6r ett definitivt 429-fel.<\/li>\n  <li><strong>API:er<\/strong>: ofta med nodelay, s\u00e5 att klienterna tydligt f\u00e5r 429 och till\u00e4mpar backoff.<\/li>\n  <li><strong>Dyra slutpunkter<\/strong>: en kort puls f\u00f6r att j\u00e4mna ut toppar i backend.<\/li>\n<\/ul>\n\n<h2>Testk\u00f6rning, loggniv\u00e5 och utv\u00e4rdering<\/h2>\n\n<p>Innan jag aktiverar gr\u00e4nsv\u00e4rdena aktiverar jag Dry-Run och justerar loggniv\u00e5n. P\u00e5 s\u00e5 s\u00e4tt kan jag se effekten utan risk:<\/p>\n\n<pre><code>server {\n  location \/api\/ {\n    limit_req zone=perip burst=20;\n    limit_req_dry_run on; # endast logga, inte blockera\n    limit_req_log_level notice;  # mindre allvarligt \u00e4n 'error'\n  }\n}\n<\/code><\/pre>\n\n<p>D\u00e4refter analyserar jag \u00e5tkomstdata fr\u00e5n de senaste 3\u20137 dagarna, identifierar flaskhalsar, justerar hastighet och burst och inaktiverar f\u00f6rst d\u00e4refter Dry-Run.<\/p>\n\n<h2>429-fel vid \u00f6verf\u00f6ring: HTML, JSON och Retry-After<\/h2>\n\n<p>F\u00f6r att uppn\u00e5 en bra anv\u00e4ndarupplevelse skiljer jag mellan webbl\u00e4sare och API-klienter och anv\u00e4nder <strong>Retry-After<\/strong>. S\u00e5 h\u00e4r kommunicerar jag gr\u00e4nser tydligt:<\/p>\n\n<pre><code>map $http_accept $wants_json {\n  default 0;\n  \"~*application\/json|\/json\"    1;\n}\n\nserver {\n  error_page 429 = @rate_limited;\n\n  location @rate_limited {\n    add_header Retry-After 2 always;\n    if ($wants_json) {\n add_header Content-Type application\/json;\n      return 429 '{\"error\":\"too_many_requests\",\"retry_after\":2}';\n    }\n    return 429 \"V\u00e4nligen f\u00f6rs\u00f6k igen senare.\";\n  }\n}\n<\/code><\/pre>\n\n<p>API:er kan p\u00e5 s\u00e5 s\u00e4tt reagera automatiskt, och anv\u00e4ndarna f\u00e5r ett tydligt meddelande.<\/p>\n\n<h2>Kombinera limit_req och limit_conn<\/h2>\n\n<p><strong>limit_req<\/strong> anger genomstr\u00f6mning per tidsf\u00f6nster, <strong>limit_conn<\/strong> begr\u00e4nsar antalet samtidiga anslutningar. Mot nedladdningar, chattiga klienter eller HTTP\/2-\u00f6versv\u00e4mningar kombinerar jag b\u00e5da metoderna:<\/p>\n\n<pre><code>limit_conn_zone $binary_remote_addr zone=perip_conn:10m;\n\nserver {\n  location \/api\/ {\n    limit_req  zone=perip burst=20 nodelay;\n    limit_conn zone=perip_conn 20;  # max. 20 samtidiga anslutningar per IP\n  }\n}\n<\/code><\/pre>\n\n<p>P\u00e5 s\u00e5 s\u00e4tt f\u00f6rhindrar jag att ett f\u00e5tal klienter visserligen h\u00e5ller sig inom gr\u00e4nsen, men \u00e4nd\u00e5 tar upp f\u00f6r mycket resurser genom att ha f\u00f6r m\u00e5nga parallella anslutningar.<\/p>\n\n<h2>Undantag, h\u00e4lsokontroller och interna rutter<\/h2>\n\n<p>Inte alla s\u00f6kv\u00e4gar beh\u00f6ver begr\u00e4nsningar. H\u00e4lsokontroller (\/healthz), interna webhooks eller betalningscallbacks tilldelas egna platser utan limit_req \u2013 eller med l\u00e4gre v\u00e4rden:<\/p>\n\n<pre><code>server {\n  # inga begr\u00e4nsningar f\u00f6r h\u00e4lsokontroller\n  location = \/healthz { return 200 \"ok\"; }\n\n  # mjuka begr\u00e4nsningar f\u00f6r betalnings-callbacks\n  location \/webhooks\/pay\/ {\n    limit_req zone=perip burst=5;\n  }\n\n  # striktare skydd f\u00f6r inloggning\n  location = \/login {\n    limit_req zone=perip rate=1r\/s burst=3;\n  }\n}\n<\/code><\/pre>\n\n<p>Detaljerade undantag minskar antalet falska positiva resultat och s\u00e4kerst\u00e4ller stabila integrationer.<\/p>\n\n<h2>Mer robust zonrouting utan \u201dIf-magi\u201d<\/h2>\n\n<p>N\u00e4r det g\u00e4ller uppdelningen \u201ebot vs. m\u00e4nniska\u201c f\u00f6redrar jag interna omdirigeringar via namngivna platser. Det g\u00f6r konfigurationen tydlig och f\u00f6ruts\u00e4gbar:<\/p>\n\n<pre><code>map $http_user_agent $is_bot {\n  default 0;\n  \"~*googlebot|bingbot\" 0;\n  \"~*crawler|scraper|bot\" 1;\n}\n\nlimit_req_zone $binary_remote_addr zone=human:20m rate=10r\/s;\nlimit_req_zone $binary_remote_addr zone=bot:10m   rate=1r\/s;\n\nserver {\n  error_page 418 = @bot;\n\n  location \/ {\n    if ($is_bot) { return 418; }   # intern vidarebefordran\n    limit_req zone=human burst=20 nodelay;\n    limit_req_status 429;\n    try_files $uri $uri\/ \/index.html;\n  }\n\n  location @bot {\n    limit_req zone=bot burst=5;\n    limit_req_status 429;\n  }\n}\n<\/code><\/pre>\n\n<p>P\u00e5 s\u00e5 s\u00e4tt hamnar botar deterministiskt i den strikta zonen, medan m\u00e4nniskor hamnar i den avslappnade \u2013 utan att b\u00e5da gr\u00e4nserna g\u00e4ller samtidigt.<\/p>\n\n<h2>Testa, m\u00e4ta, prova: en praktisk metod<\/h2>\n\n<ul>\n  <li><strong>Iscens\u00e4ttning<\/strong>: V\u00e4lj en konservativ inst\u00e4llning f\u00f6r Rate\/Burst, aktivera Dry-Run och k\u00f6r syntetisk belastning mot Hot-Path.<\/li>\n  <li><strong>R\u00f6kprov<\/strong>: Skapa korta pulser med curl eller Lasttools och kontrollera 429\/f\u00f6rdr\u00f6jningsbeteendet.<\/li>\n  <li><strong>Produktiv-Pilot<\/strong>: Till att b\u00f6rja med ska man till\u00e4mpa detta p\u00e5 enskilda platser och noggrant \u00f6vervaka loggarna.<\/li>\n  <li><strong>Iterativ sk\u00e4rpning<\/strong>: S\u00e4tt endast gr\u00e4nsv\u00e4rden d\u00e4r m\u00f6nster uppt\u00e4cks; minimera antalet falska larm.<\/li>\n<\/ul>\n\n<pre><code># Exempel: snabb burst-test med curl\nfor i in {1..50}; do curl -s -o \/dev\/null -w \"%{http_code}\\n\" https:\/\/example.com\/login &amp; done; wait\n<\/code><\/pre>\n\n<h2>Minut- ist\u00e4llet f\u00f6r sekundintervall och detaljerade s\u00f6kv\u00e4gar<\/h2>\n\n<p>NGINX till\u00e5ter intervall i sekunder eller minuter (<strong>r\/s<\/strong>, <strong>r\/m<\/strong>). Vid missbruk av inloggningen anv\u00e4nder jag ofta 60r\/m ist\u00e4llet f\u00f6r 1r\/s f\u00f6r att till\u00e5ta korta, legitima dubbelklick men begr\u00e4nsa kontinuerlig inmatning. Dyra s\u00f6kv\u00e4gar f\u00e5r sn\u00e4vare gr\u00e4nser \u00e4n billiga. Exempel:<\/p>\n\n<pre><code>limit_req_zone $binary_remote_addr zone=perip_min:20m rate=60r\/m;\n\nserver {\n  location \/search\/ {\n    limit_req zone=perip_min burst=10;   # str\u00e4ngare\n  }\n  location \/status {\n    # ingen begr\u00e4nsning \u2013 billigt och anv\u00e4nds internt\n    return 200;\n  }\n}\n<\/code><\/pre>\n\n<h2>Fallgropar och hur jag undviker dem<\/h2>\n\n<ul>\n  <li><strong>Fel nyckel<\/strong>: N\u00e4r jag anv\u00e4nder proxyservrar utan riktig IP-adress begr\u00e4nsar jag av misstag alla anv\u00e4ndare samtidigt.<\/li>\n  <li><strong>F\u00f6r sm\u00e5 zoner<\/strong>: \u201ezone is full\u201c leder till of\u00f6ruts\u00e4gbart beteende \u2013 dimensionera gener\u00f6st.<\/li>\n  <li><strong>En gr\u00e4ns f\u00f6r allt<\/strong>: Olika v\u00e4gar kr\u00e4ver olika v\u00e4rden; en universall\u00f6sning leder till frustration.<\/li>\n  <li><strong>Ingen \u00f6vervakning<\/strong>: Utan 429-utv\u00e4rdering passerar felkonfigurationer obem\u00e4rkt f\u00f6rbi.<\/li>\n  <li><strong>\u00d6ver-vitlista<\/strong>: F\u00f6r omfattande undantag \u00f6ppnar d\u00f6rren p\u00e5 vid gavel \u2013 skapa en vitlista som \u00e4r m\u00e5linriktad, tillf\u00e4llig och \u00f6versk\u00e5dlig.<\/li>\n<\/ul>\n\n<h2>S\u00e4rdrag med HTTP\/2, SSE och cachelagring<\/h2>\n\n<p>HTTP\/2 samlar f\u00f6rfr\u00e5gningar i ett f\u00e5tal anslutningar; <strong>limit_conn<\/strong> f\u00f6rblir \u00e4nd\u00e5 relevant, eftersom str\u00f6mmar f\u00f6rbrukar resurser. Server-Sent Events eller l\u00e5nga nedladdningar utl\u00f6ser s\u00e4llan hastighetsbegr\u00e4nsningar (f\u00e5 f\u00f6rfr\u00e5gningar), men tar tid i anspr\u00e5k \u2013 h\u00e4r begr\u00e4nsar jag parallellt med limit_conn eller till\u00e4mpar bandbreddsstrategier. D\u00e4r det \u00e4r m\u00f6jligt avlastar jag med <strong>Caching<\/strong> (t.ex. statiska resurser, frekventa GET-f\u00f6rfr\u00e5gningar), s\u00e5 att begr\u00e4nsningarna tr\u00e4der i kraft mer s\u00e4llan och anv\u00e4ndarna f\u00e5r snabbare svar.<\/p>\n\n<h2>Operativ checklista<\/h2>\n\n<ul>\n  <li>Real-IP korrekt, nycklar definierade (IP\/token\/anv\u00e4ndare)<\/li>\n  <li>Zoner med gener\u00f6sa dimensioner, m\u00e4tv\u00e4rden\/loggar finns tillg\u00e4ngliga<\/li>\n  <li>hastighet\/burst anpassad efter v\u00e4gklass, nodelay medvetet inst\u00e4llt<\/li>\n  <li>Testat med provk\u00f6rning, 429-kommunikation (Retry-After) implementerad<\/li>\n  <li>Undantag f\u00f6r Health\/Webhooks, kombination med limit_conn<\/li>\n  <li>Iterativ omsk\u00e4rpning och larm vid avvikelser<\/li>\n<\/ul>","protected":false},"excerpt":{"rendered":"<p>L\u00e4r dig hur du med hj\u00e4lp av NGINX Rate Limiting kan skydda din webbplats mot bottrafik och attacker och d\u00e4rmed f\u00f6rb\u00e4ttra webbserverns s\u00e4kerhet. Praktiska exempel och b\u00e4sta praxis ing\u00e5r.<\/p>","protected":false},"author":1,"featured_media":21248,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-21255","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"71","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"NGINX Rate","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21248","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/21255","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/comments?post=21255"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/21255\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/21248"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=21255"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=21255"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=21255"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}