{"id":20898,"date":"2026-08-22T15:04:55","date_gmt":"2026-08-22T13:04:55","guid":{"rendered":"https:\/\/webhosting.de\/nginx-cache-optimierung-fenster\/"},"modified":"2026-08-22T15:04:55","modified_gmt":"2026-08-22T13:04:55","slug":"janela-de-otimizacao-da-cache-do-nginx","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/nginx-cache-optimierung-fenster\/","title":{"rendered":"Configurar o Open File Cache do NGINX de forma ideal: como tirar o m\u00e1ximo partido do desempenho do teu servidor"},"content":{"rendered":"<p><strong>Cache do NGINX<\/strong> ganha visivelmente em velocidade quando configuro o Open File Cache de forma espec\u00edfica: este mant\u00e9m os metadados dos ficheiros e os identificadores na mem\u00f3ria, poupando acessos dispendiosos ao sistema de ficheiros. Com valores adequados para <strong>max<\/strong>, <strong>inativo<\/strong>, <strong>v\u00e1lido<\/strong> e <strong>min_uses<\/strong> Otimizo a entrega de conte\u00fados est\u00e1ticos para tempos de resposta r\u00e1pidos e uma menor carga de E\/S.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<ul>\n  <li><strong>Cache de metadados<\/strong>: armazena a exist\u00eancia, o tamanho, os tempos e os identificadores, em vez dos conte\u00fados<\/li>\n  <li><strong>Dimensionamento<\/strong>: Equil\u00edbrio entre consumo de RAM, taxa de acerto e taxa de altera\u00e7\u00e3o<\/li>\n  <li><strong>Contextos<\/strong>: ideal para imagens\/CSS\/JS; evitar caminhos din\u00e2micos<\/li>\n  <li><strong>Valida\u00e7\u00e3o<\/strong>: Garantir a atualidade com open_file_cache_valid<\/li>\n  <li><strong>Medi\u00e7\u00e3o<\/strong>: Verificar os efeitos relacionados com as lat\u00eancias, as entradas\/sa\u00eddas e a taxa de erros<\/li>\n<\/ul>\n\n<h2>O que o Open File Cache realmente armazena<\/h2>\n\n<p>Eu guardo em cache com <strong>Abrir ficheiro<\/strong> A cache n\u00e3o armazena o conte\u00fado dos ficheiros, mas sim informa\u00e7\u00f5es estruturadas: se um ficheiro existe, qual \u00e9 o seu tamanho, quando foi alterado e qual o descritor que j\u00e1 se encontra aberto. Estas informa\u00e7\u00f5es est\u00e3o dispon\u00edveis na mem\u00f3ria e encurtam o caminho at\u00e9 \u00e0 pr\u00f3xima resposta. Cada consulta ao disco r\u00edgido evitada reduz o <strong>Carga de E\/S<\/strong> e poupa tempo de CPU, o que \u00e9 especialmente importante quando se trata de muitos ficheiros pequenos. De acordo com a documenta\u00e7\u00e3o do NGINX, esta fun\u00e7\u00e3o abrange descritores abertos, informa\u00e7\u00f5es de diret\u00f3rio e erros de pesquisa. Isto acelera as varreduras de diret\u00f3rio e os caminhos de acesso, que, de outra forma, teriam de ser consultados novamente no disco a cada pedido.<\/p>\n\n<p>Utilizo este mecanismo deliberadamente para diret\u00f3rios com acessos frequentes, como bibliotecas de ficheiros multim\u00e9dia e recursos de compila\u00e7\u00e3o. O efeito \u00e9 particularmente vis\u00edvel em projetos com muitos <strong>Activos<\/strong>, em que, de outra forma, o sistema de ficheiros se tornaria um estrangulamento. A cache reduz sensivelmente as chamadas de sistema como stat(), open() e readdir(). Ao mesmo tempo, o controlo mant\u00e9m-se altamente granular, uma vez que defino separadamente o \u00e2mbito e a validade das entradas. Desta forma, mantenho os dados atualizados sem perder a vantagem do armazenamento em cache.<\/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\/08\/server-tuning-7234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Quando vale a pena utilizar o Open File Cache<\/h2>\n\n<p>Ligo o <strong>Cache<\/strong> especificamente para entregas est\u00e1ticas: imagens, CSS, JavaScript, tipos de letra e ficheiros para download. Em zonas din\u00e2micas, como p\u00e1ginas de in\u00edcio de sess\u00e3o, cestos de compras ou percursos personalizados, evito utiliz\u00e1-lo, pois a\u00ed aplicam-se outras regras. O WordPress e os front-ends \u00abheadless\u00bb beneficiam muito com isto, uma vez que os temas, plugins e pacotes disponibilizam muitos ficheiros. Quanto mais constantes os ficheiros permanecerem, melhor funciona a <strong>Taxa de acerto<\/strong> dos metadados. Quando realizo implementa\u00e7\u00f5es com muita frequ\u00eancia, ajusto os intervalos de valida\u00e7\u00e3o de forma mais rigorosa.<\/p>\n\n<p>No que diz respeito \u00e0 entrega de conte\u00fados atrav\u00e9s de SSDs locais, o ganho \u00e9 particularmente significativo. Mesmo em configura\u00e7\u00f5es SATA mais antigas ou montagens NFS, poupo tempo a cada acesso. Tenho o cuidado de ativar o cache apenas nos contextos relevantes (http, servidor ou localiza\u00e7\u00e3o). Assim, evito que diret\u00f3rios inadequados consumam mem\u00f3ria. Uma separa\u00e7\u00e3o clara garante, neste caso, uma configura\u00e7\u00e3o organizada e um comportamento fi\u00e1vel.<\/p>\n\n<h2>Configura\u00e7\u00e3o inicial que funciona<\/h2>\n\n<p>Vou come\u00e7ar com uma breve <strong>Base<\/strong>, e depois continuo a medir e a ajustar de forma controlada. Estes valores proporcionam bons resultados iniciais em muitos hosts e mant\u00eam o risco baixo. Importante: verifique primeiro com o comando `nginx -t` e, s\u00f3 depois, execute o `reload`. Defino deliberadamente as diretivas ao n\u00edvel do http, mas posso utiliz\u00e1-las de forma mais restrita no bloco location adequado, se necess\u00e1rio. Desta forma, encontro rapidamente um bom equil\u00edbrio entre o consumo de mem\u00f3ria e <strong>Desempenho<\/strong>.<\/p>\n\n<pre><code>open_file_cache max=1000 inactive=20s;\nopen_file_cache_valid 30s;\nopen_file_cache_min_uses 2;\nopen_file_cache_errors off;<\/code><\/pre>\n\n<p>Com \u00abmax\u00bb, limito o n\u00famero m\u00e1ximo de objetos armazenados na cache. \u00abinactive\u00bb elimina as entradas n\u00e3o utilizadas ap\u00f3s o tempo selecionado. \u00abvalid\u00bb controla a frequ\u00eancia com que o NGINX volta a verificar os metadados em rela\u00e7\u00e3o ao sistema de ficheiros. \u00abmin_uses\u00bb garante que apenas os ficheiros realmente utilizados sejam armazenados na cache. Utilizo os caches de erros de forma moderada, para evitar resultados negativos desnecess\u00e1rios.<\/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\/08\/nginx_cache_optimierung_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Dimensionamento correto: max, inactive, min_uses<\/h2>\n\n<p>Determino o tamanho da cache com base em valores reais <strong>Dados de carga<\/strong> em vez de me basear em suposi\u00e7\u00f5es. Quantos ficheiros est\u00e1ticos acedo nos hor\u00e1rios de pico e como se distribui o tr\u00e1fego. \u00c0 medida que o n\u00famero de ficheiros aumenta, vou aumentando o valor de \u00abmax\u00bb gradualmente, normalmente em incrementos de 500 ou 1000. No in\u00edcio, mantenho o valor de \u00abinactive\u00bb relativamente baixo, at\u00e9 conseguir avaliar com seguran\u00e7a o comportamento. O valor de \u00abmin_uses\u00bb limita o ru\u00eddo de dispers\u00e3o, para que os ficheiros raramente utilizados n\u00e3o bloqueiem a mem\u00f3ria.<\/p>\n\n<p>Em sites com muitos recursos, acabo frequentemente por definir o valor m\u00e1ximo entre 5 000 e 10 000. Em projetos mais pequenos, valores entre 500 e 1 500 costumam ser suficientes. Acompanho a taxa de acertos, a curva de RAM dos trabalhadores do NGINX e a lat\u00eancia nos recursos est\u00e1ticos. Depois, vou ajustando os valores de \u00abmax\u00bb e \u00abinactive\u00bb at\u00e9 que a rela\u00e7\u00e3o fique correta. Paralelamente, analiso o lado das liga\u00e7\u00f5es e fa\u00e7o o dimensionamento, se necess\u00e1rio. <a href=\"https:\/\/webhosting.de\/pt\/nginx-ligacoes-dos-workers-escalabilidade-milhares-de-pedidos-aumento-do-trafego\/\">Escalar o `worker_connections`<\/a>, para n\u00e3o sobrecarregar o sistema durante os picos de tr\u00e1fego.<\/p>\n\n<h2>Valida\u00e7\u00e3o e atualidade: open_file_cache_valid<\/h2>\n\n<p>Eu defino com <strong>v\u00e1lido<\/strong>, durante quanto tempo o NGINX considera os metadados como fi\u00e1veis. Em muitas implementa\u00e7\u00f5es, opto por um valor mais conservador, por exemplo, entre 15 e 30 segundos. No caso de altera\u00e7\u00f5es pouco frequentes, posso optar por um intervalo significativamente mais longo, por exemplo, entre 60 e 300 segundos. Este intervalo influencia a frequ\u00eancia com que o NGINX verifica novamente os atributos dos ficheiros, mas n\u00e3o afeta a entrega de conte\u00fados. Desta forma, a <strong>Atualidade<\/strong> elevada, sem que seja necess\u00e1rio recorrer ao disco em cada consulta.<\/p>\n\n<p>Evito valores extremos, porque ambos apresentam desvantagens. Intervalos demasiado curtos aumentam a carga de chamadas ao sistema. Intervalos demasiado longos correm o risco de o NGINX manter metadados desatualizados na mem\u00f3ria durante demasiado tempo. Oriento-me pela frequ\u00eancia de altera\u00e7\u00e3o dos ficheiros e pelos ciclos de lan\u00e7amento. Assim que o pipeline de lan\u00e7amento estiver definido, ajusto o `valid` de acordo com o ritmo.<\/p>\n\n<h2>Armazenar erros em cache de forma \u00fatil: open_file_cache_errors<\/h2>\n\n<p>Consigo resolver rapidamente erros como \u201eFicheiro n\u00e3o encontrado\u201c <strong>armazenar temporariamente<\/strong>, para aliviar o tr\u00e1fego de pedidos inv\u00e1lidos repetidos. Isto compensa no caso de erros 404 recorrentes em percursos conhecidos que n\u00e3o existem. Por isso, defino \u00aberrors\u00bb como \u00abon\u00bb de forma pontual e mantenho \u00abinactive\u00bb num n\u00edvel moderado. No entanto, no caso de ficheiros potencialmente tempor\u00e1rios com ciclos de vida curtos, procuro ser cauteloso. Desta forma, evito que ficheiros tempor\u00e1rios <strong>condi\u00e7\u00f5es<\/strong> levarem a resultados falsos negativos.<\/p>\n\n<p>Para casos gen\u00e9ricos de erros 404, recomendo antes um bloco \u00ablocation\u00bb dedicado com regras claras. A\u00ed, posso gerir as caches de erros separadamente da cache normal de ficheiros. Em diret\u00f3rios de multim\u00e9dia bem organizados, os erros geralmente n\u00e3o ocorrem. Isto poupa mem\u00f3ria e evita mal-entendidos em an\u00e1lises posteriores. Uma separa\u00e7\u00e3o clara facilita, neste caso, a resolu\u00e7\u00e3o de problemas.<\/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\/08\/nginx-cache-optimierung-server-7419.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sinergias: sendfile, buffer, compress\u00e3o<\/h2>\n\n<p>Combino o Open File Cache com <strong>sendfile<\/strong> porque as transfer\u00eancias de ficheiros pelo kernel poupam o trabalho de c\u00f3pia no espa\u00e7o do utilizador. No caso de conte\u00fados est\u00e1ticos, isto resulta em menos mudan\u00e7as de contexto e entregas mais fluidas. Buffers de sa\u00edda adequados reduzem ainda mais as chamadas de sistema e mant\u00eam a taxa de transfer\u00eancia est\u00e1vel. O gzip ou o Brotli comprimem os recursos baseados em texto e reduzem a largura de banda e a lat\u00eancia. Paralelamente, configuro o <a href=\"https:\/\/webhosting.de\/pt\/configurar-de-forma-ideal-os-processos-de-trabalho-do-nginx-para-melhorar-o-desempenho\/\">Processos \u00abWorker\u00bb<\/a> de forma a que se adaptem \u00e0 topologia da CPU.<\/p>\n\n<p>Al\u00e9m disso, analiso estrat\u00e9gias de cabe\u00e7alhos para o armazenamento em cache do lado do cliente. Tempos de Cache-Control prolongados em pacotes imut\u00e1veis poupam RTTs, enquanto mantenho uma abordagem cautelosa no caso de ficheiros que mudam frequentemente. Em conjunto com ETags ou Last-Modified, garanto revalida\u00e7\u00f5es eficientes. \u00c9 assim que o cache do cliente, o Open File Cache e a compress\u00e3o funcionam em conjunto. Isto funciona como um multiplicador para uma <strong>Tempos de resposta<\/strong>.<\/p>\n\n<h2>Linux e armazenamento: o papel do hardware<\/h2>\n\n<p>Vou tirar mais partido do <strong>Cache de ficheiros<\/strong>, desde que o armazenamento e a configura\u00e7\u00e3o do kernel estejam adequados. SSDs mais r\u00e1pidos, agendadores de E\/S otimizados e mem\u00f3ria RAM suficiente para a cache de p\u00e1ginas trazem benef\u00edcios imediatos. Por outro lado, uma elevada utiliza\u00e7\u00e3o de inodes e sistemas de ficheiros fragmentados custam tempo. Al\u00e9m disso, mantenho-me atento ao n\u00famero de descritores abertos e ajusto os limites do sistema. Desta forma, o sistema operativo constitui uma base eficiente para um funcionamento r\u00e1pido <strong>Acessos<\/strong>.<\/p>\n\n<p>Nos hosts de VM, tenho em conta os efeitos de overcommit e de \u00abvizinho ruidoso\u00bb. Verifico se as lat\u00eancias do NFS ou da rede reduzem os benef\u00edcios do Open File Cache. Tamb\u00e9m os cen\u00e1rios de contentores com sistemas de ficheiros overlay apresentam comportamentos diferentes, dependendo da estrutura em camadas. Por isso, medo a carga real de produ\u00e7\u00e3o, e n\u00e3o apenas testes em diret\u00f3rios vazios. Desta forma, identifico os pontos de estrangulamento numa fase precoce e posso reagir de forma direcionada.<\/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\/08\/nginx_performance_5793.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoriza\u00e7\u00e3o e m\u00e9tricas: \u00e9 assim que avalio o impacto<\/h2>\n\n<p>Mede o impacto atrav\u00e9s de <strong>Lat\u00eancias<\/strong>, chamadas de sistema, tempos de espera de E\/S e recursos dos workers. Ferramentas como o strace, o perf, o iostat e o nginx-status ajudam-me a tornar esse efeito vis\u00edvel. Observo o \u00abTime-to-First-Byte\u00bb para rotas est\u00e1ticas e comparo situa\u00e7\u00f5es de \u00abhit\u00bb e \u00abmiss\u00bb. Atrav\u00e9s dos registos, identifico percursos 404 recorrentes ou diret\u00f3rios mais acedidos. Paralelamente, verifico o <a href=\"https:\/\/webhosting.de\/pt\/limite-do-descritor-de-ficheiro-alojamento-do-servidor-afinacao-dos-limites-do-servidor\/\">Limite de descritores de ficheiros<\/a>, para que os handlers abertos n\u00e3o falhem devido a limites de processos.<\/p>\n\n<p>Registo as m\u00e9tricas antes e depois da mudan\u00e7a. Depois, ajusto os valores de \u00abmax\u00bb, \u00abinactive\u00bb e \u00abvalid\u00bb e volto a medir. Duas a tr\u00eas itera\u00e7\u00f5es costumam ser suficientes para atingir um valor-alvo preciso. Em picos de tr\u00e1fego, verifico se as curvas de carga se tornam mais suaves. Desta forma, n\u00e3o compro os ganhos com base em dados aned\u00f3ticos, mas sim com dados inequ\u00edvocos <strong>n\u00fameros<\/strong>.<\/p>\n\n<h2>Armadilhas t\u00edpicas e como evit\u00e1-las<\/h2>\n\n<p>Eu ativo o <strong>Cache<\/strong> N\u00e3o de forma global para tudo, mas apenas onde houver benef\u00edcio. Alivio a carga dos pontos finais din\u00e2micos de outra forma, por exemplo, atrav\u00e9s de caches de aplica\u00e7\u00f5es ou estrat\u00e9gias de borda. N\u00e3o escolho valores m\u00e1ximos extremamente elevados ao acaso, porque, mais cedo ou mais tarde, a RAM acaba por ficar insuficiente. Valores de inatividade demasiado longos mant\u00eam na mem\u00f3ria elementos obsoletos que j\u00e1 n\u00e3o s\u00e3o necess\u00e1rios para nenhuma solicita\u00e7\u00e3o. Al\u00e9m disso, intervalos de validade prematuros geram chamadas de sistema desnecess\u00e1rias e anulam a vantagem em termos de velocidade.<\/p>\n\n<p>Estabele\u00e7o diretrizes para cada diret\u00f3rio e documento as responsabilidades. Ap\u00f3s as implementa\u00e7\u00f5es, verifico aleatoriamente se os ficheiros importantes est\u00e3o atualizados. Defino mensagens de erro de forma clara, para que as an\u00e1lises de erros 404 n\u00e3o se percam no ru\u00eddo. Para mim, as advert\u00eancias no registo de erros fazem parte da verifica\u00e7\u00e3o regular. Com uma manuten\u00e7\u00e3o disciplinada, a cache de ficheiros abertos mant\u00e9m-se fi\u00e1vel e <strong>eficaz<\/strong>.<\/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\/08\/nginx_file_cache_performance_6789.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Exemplos pr\u00e1ticos: sites pequenos vs. sites grandes<\/h2>\n\n<p>Distingo as configura\u00e7\u00f5es com base no n\u00famero de ficheiros, no tr\u00e1fego e na frequ\u00eancia das altera\u00e7\u00f5es e, a partir da\u00ed, deduzo que <strong>Valores<\/strong> . Os projetos mais pequenos requerem poucas entradas, per\u00edodos de inatividade curtos e valids moderados. Os sites de m\u00e9dia a grande dimens\u00e3o recorrem a valores m\u00e1ximos mais elevados e a intervalos ajustados. As implementa\u00e7\u00f5es frequentes justificam valids mais curtos, enquanto as implementa\u00e7\u00f5es raras permitem valids mais longos. A tabela apresenta pontos de partida t\u00edpicos, que irei ajustar posteriormente com base em medi\u00e7\u00f5es.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Configura\u00e7\u00e3o<\/th>\n      <th>Ficheiros (aproximadamente)<\/th>\n      <th>max<\/th>\n      <th>inativo<\/th>\n      <th>v\u00e1lido<\/th>\n      <th>min_uses<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Pequeno site<\/td>\n      <td>200\u20131.000<\/td>\n      <td>500\u20131.500<\/td>\n      <td>20-30s<\/td>\n      <td>30\u201360 s<\/td>\n      <td>2<\/td>\n      <td><strong>Econ\u00f3mico<\/strong> iniciar, verificar<\/td>\n    <\/tr>\n    <tr>\n      <td>M\u00e9dio<\/td>\n      <td>1.000\u201310.000<\/td>\n      <td>2.000\u20136.000<\/td>\n      <td>30\u201360 s<\/td>\n      <td>60\u2013120 s<\/td>\n      <td>2-3<\/td>\n      <td><strong>Tr\u00e1fego<\/strong>- Observar os picos<\/td>\n    <\/tr>\n    <tr>\n      <td>Grande<\/td>\n      <td>10.000+<\/td>\n      <td>6.000\u201310.000<\/td>\n      <td>45\u2013120 s<\/td>\n      <td>120\u2013300 s<\/td>\n      <td>3+<\/td>\n      <td>RAM e E\/S limitadas <strong>controlo<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Implementa\u00e7\u00f5es frequentes<\/td>\n      <td>vari\u00e1vel<\/td>\n      <td>adaptado<\/td>\n      <td>20\u201345 s<\/td>\n      <td>15\u201360 s<\/td>\n      <td>2-3<\/td>\n      <td>Frescura em primeiro lugar <strong>Taxa de acerto<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Lista de verifica\u00e7\u00e3o para a implementa\u00e7\u00e3o<\/h2>\n\n<p>Estou a preparar um <strong>Plano<\/strong> Primeiro: definir os diret\u00f3rios em que o armazenamento em cache de metadados traz benef\u00edcios e delimitar as zonas din\u00e2micas. Em seguida, defino valores iniciais conservadores e verifico a configura\u00e7\u00e3o com o comando `nginx -t`. Reinicio o NGINX, observo as lat\u00eancias e analiso os registos, bem como as m\u00e9tricas do sistema. Em seguida, ajusto os par\u00e2metros max, inactive, valid e min_uses em pequenos incrementos. Por fim, documento os valores finais para cada ambiente e guardo as altera\u00e7\u00f5es com controlo de vers\u00f5es.<\/p>\n\n<p>Tenho uma op\u00e7\u00e3o de revers\u00e3o preparada, caso os resultados sejam diferentes do esperado. No caso de percursos 404 recorrentes, decido separadamente se devo armazenar os erros em cache temporariamente. Descrevo as responsabilidades: quem altera os valores, quem faz as medi\u00e7\u00f5es e quem aprova as vers\u00f5es. Em implementa\u00e7\u00f5es com muitos meios, defino par\u00e2metros de refer\u00eancia em fun\u00e7\u00e3o do tr\u00e1fego de pico. Desta forma, procedo de forma planeada e obtenho resultados sustent\u00e1veis <strong>Resultados<\/strong>.<\/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\/08\/nginx-cache-optimierung-1045.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Escolher corretamente o \u00e2mbito de aplica\u00e7\u00e3o: http, servidor ou localiza\u00e7\u00e3o<\/h2>\n\n<p>Ativo o Open File Cache nos casos em que a sua utilidade \u00e9 mensur\u00e1vel. A aplica\u00e7\u00e3o global ao n\u00edvel do HTTP \u00e9 pr\u00e1tica, mas muitas vezes demasiado gen\u00e9rica. \u00c9 prefer\u00edvel um <strong>Defini\u00e7\u00e3o do \u00e2mbito<\/strong> por servidor ou localiza\u00e7\u00e3o. Desta forma, as \u00e1reas din\u00e2micas n\u00e3o s\u00e3o afetadas e os diret\u00f3rios est\u00e1ticos beneficiam ao m\u00e1ximo. Para as rotas da API ou de administra\u00e7\u00e3o, desativo a cache; para os caminhos dos recursos, ativo-a e defino as dimens\u00f5es de forma personalizada.<\/p>\n\n<pre><code>http {\n    # Padr\u00e3o: desativado, para que as zonas din\u00e2micas permane\u00e7am neutras\n    open_file_cache off;\n\n server {\n root \/var\/www\/site;\n\n        # Recursos est\u00e1ticos com perfil pr\u00f3prio\n location ^~ \/assets\/ {\n open_file_cache max=6000 inactive=60s;\n open_file_cache_valid 120s;\n open_file_cache_min_uses 2;\n            open_file_cache_errors desativado;\n try_files $uri =404;\n }\n\n # Din\u00e2mico: n\u00e3o \u00e9 necess\u00e1rio o Open File Cache\n location \/api\/ {\n proxy_pass http:\/\/backend;\n }\n    }\n}<\/code><\/pre>\n\n<p>Come\u00e7o com poucos locais bem definidos e vou expandindo gradualmente. Desta forma, os efeitos mant\u00eam-se compreens\u00edveis e evito intera\u00e7\u00f5es indesejadas entre as regras.<\/p>\n\n<h2>Arquitetura multiprocessos: uma an\u00e1lise da RAM e dos limites<\/h2>\n\n<p>O NGINX funciona com v\u00e1rios <strong>Trabalhadores<\/strong>, e cada worker mant\u00e9m o seu pr\u00f3prio cache de ficheiros abertos. Isto significa que o n\u00famero m\u00e1ximo de entradas se multiplica pelo n\u00famero de workers. Quatro workers e um valor m\u00e1ximo de 5 000 resultam potencialmente em at\u00e9 20 000 entradas no espa\u00e7o do processo. Por isso, pretendo alocar RAM <em>por trabalhador<\/em> e analiso as curvas reais. Cada registo gera algumas centenas de bytes de metadados e estruturas administrativas, al\u00e9m dos custos associados aos descritores abertos.<\/p>\n\n<p>Al\u00e9m disso, apresento a <strong>Limites dos descritores de ficheiros<\/strong> de forma adequada (a n\u00edvel do sistema e para o processo NGINX). Se o limite n\u00e3o for suficiente, os handles abertos podem falhar e a cache deixa de ser eficaz. Verifico o `ulimit -n` para o utilizador do NGINX e, se necess\u00e1rio, utilizo o `worker_rlimit_nofile` para garantir que os picos sejam geridos com seguran\u00e7a. Verifico o n\u00famero real de ficheiros abertos com o `lsof` ou atrav\u00e9s das estat\u00edsticas do processo, para n\u00e3o me limitar a estimar, mas sim saber com certeza.<\/p>\n\n<h2>Links simb\u00f3licos, aliases e try_files: detalhes com impacto<\/h2>\n\n<p>Na pr\u00e1tica, \u00e9 frequente que <strong>Links simb\u00f3licos<\/strong>, alias e try_files em conjunto. Tenho o cuidado de utilizar o alias corretamente (com a sem\u00e2ntica de barra adequada) e de evitar armadilhas. Os destinos dos links simb\u00f3licos podem alterar-se entre vers\u00f5es, enquanto o NGINX ainda mant\u00e9m os metadados na cache. Isto \u00e9 intencional, desde que o intervalo \u00abvalid\u00bb seja suficientemente curto. No caso de caminhos sens\u00edveis, aplico uma prote\u00e7\u00e3o adicional com \u00abdisable_symlinks if_not_owner\u00bb.<\/p>\n\n<pre><code>location \/media\/ {\n    O alias # tem de corresponder ao estilo do diret\u00f3rio (barra final!)\n    alias \/mnt\/storage\/media\/;\n    desativar liga\u00e7\u00f5es simb\u00f3licas se n\u00e3o for o propriet\u00e1rio a partir de \/mnt\/storage;\n    cache de ficheiros abertos m\u00e1x.=8000 inativo=90s;\n    validade do cache de ficheiros abertos 60s;\n    try_files $uri =404;\n}<\/code><\/pre>\n\n<p>No `try_files`, defino alternativas claras e evito cadeias que provoquem pesquisas m\u00faltiplas. Percursos consistentes (raiz\/alias) e um tratamento de erros claro reduzem os resultados negativos desnecess\u00e1rios na cache. Desta forma, as pesquisas mant\u00eam-se r\u00e1pidas e transparentes.<\/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\/08\/nginx-cache-optimierung-1045.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Implementa\u00e7\u00f5es sem arranque a frio: gerir a atualiza\u00e7\u00e3o<\/h2>\n\n<p>Em <strong>Tempo de inatividade zero<\/strong>- Nas implementa\u00e7\u00f5es, costumo trocar um link simb\u00f3lico (por exemplo, current \u2192 releases\/123). O Open File Cache mant\u00e9m os metadados antigos at\u00e9 \u00e0 pr\u00f3xima valida\u00e7\u00e3o. Eu controlo isto de forma deliberada: ou defino um valor mais curto para o `open_file_cache_valid` (por exemplo, 5\u201315 s) em torno da implementa\u00e7\u00e3o, ou reinicio o NGINX ap\u00f3s a mudan\u00e7a. Uma recarga inicia novos workers, que criam metadados atualizados, enquanto os workers antigos processam as solicita\u00e7\u00f5es de forma correta. Desta forma, a entrega permanece est\u00e1vel e a <strong>Frescura<\/strong> elevado.<\/p>\n\n<p>No caso de conjuntos de ativos muito grandes, posso identificar os caminhos mais solicitados posteriormente <em>aquecimento<\/em> (por exemplo, atrav\u00e9s de um breve rastreio), para que as entradas mais importantes sejam armazenadas na cache logo no in\u00edcio. No entanto, procuro manter este processo simples, para n\u00e3o criar picos de E\/S artificiais.<\/p>\n\n<h2>Op\u00e7\u00f5es do sistema de ficheiros e de montagem: pequenos ajustes, grande impacto<\/h2>\n\n<p>Presto aten\u00e7\u00e3o a <strong>noatime\/nodiratime<\/strong> ao montar volumes locais. Desta forma, os acessos evitam atualiza\u00e7\u00f5es desnecess\u00e1rias do Atime e reduzem a E\/S. No NFS, a estrat\u00e9gia de cache de atributos (por exemplo, actimeo) influencia o <em>aparente<\/em> Atualidade \u2013 escolho valores que se ajustem ao valid, para evitar inconsist\u00eancias. Para dados de produ\u00e7\u00e3o, opto por sistemas de ficheiros maduros (como o ext4 ou o xfs) e mantenho-me atento \u00e0s reservas de inodes. Volumes sobrecarregados ou altamente fragmentados custam tempo, independentemente do NGINX.<\/p>\n\n<p>Em contentores com sistemas de ficheiros overlay, estou a avaliar o efeito da cache de ficheiros abertos <strong>sob carga<\/strong>, e n\u00e3o em modo de espera. A t\u00e9cnica de \u00ablayering\u00bb pode tornar o acesso aos metadados mais dispendioso; por isso, ajusto os par\u00e2metros \u00abinactive\u00bb e \u00abvalid\u00bb de forma mais conservadora e concentro-me nos \u00abhotsets\u00bb.<\/p>\n\n<h2>Compress\u00e3o e variantes est\u00e1ticas: gzip_static, Brotli e Ranges<\/h2>\n\n<p>Sempre que poss\u00edvel, utilizo, <strong>gzip_static<\/strong> (e, da mesma forma, o Brotli), para servir diretamente ficheiros pr\u00e9-comprimidos. O Open File Cache disponibiliza tamb\u00e9m os metadados para as variantes .gz\/.br; o min_uses filtra os ficheiros raros e pouco comuns. Os pedidos de intervalo beneficiam de metadados est\u00e1veis (tamanho, mtime), juntamente com o sendfile e configura\u00e7\u00f5es adequadas de tcp_nopush\/tcp_nodelay.<\/p>\n\n<pre><code>location ~* \\.(?:css|js|svg|json|txt)$ {\n    gzip_static on;  # dar prioridade aos ficheiros .gz existentes\n    sendfile on;\n    tcp_nopush on;\n    open_file_cache max=4000 inactive=45s;\n    open_file_cache_valid 90s;\n    open_file_cache_min_uses 2;\n}<\/code><\/pre>\n\n<p>Mantenho o ETag e o Last-Modified consistentes. Desta forma, os clientes podem revalidar de forma eficiente e o NGINX tem de aceder ao sistema de ficheiros em profundidade com menos frequ\u00eancia. O Open File Cache fornece rapidamente os metadados necess\u00e1rios para isso.<\/p>\n\n<h2>An\u00e1lise aprofundada e resolu\u00e7\u00e3o de problemas: o que verifico concretamente<\/h2>\n\n<ul>\n  <li>Chamadas de sistema: A t\u00edtulo de teste, aplico o strace a um worker (por exemplo, -e trace=open,stat) e comparo a frequ\u00eancia antes e depois da ativa\u00e7\u00e3o.<\/li>\n  <li>Carga de E\/S: o comando \u00abiostat -xz\u00bb, executado em intervalos curtos, mostra se os tempos de espera e as profundidades das filas est\u00e3o a diminuir.<\/li>\n  <li>Caminhos incorretos: os registos indicam-me se ocorrem erros 404 recorrentes. Estes caminhos s\u00e3o pass\u00edveis de ativa\u00e7\u00e3o tempor\u00e1ria do \u00aberrors on\u00bb \u2013 de forma pontual.<\/li>\n  <li>Limites do FD: o comando \u00ablsof -p  | wc -l\u00bb d\u00e1-me um n\u00famero astron\u00f3mico do n\u00famero de descritores abertos.<\/li>\n  <li>Mem\u00f3ria: Estou a monitorizar o RSS por worker e a correlacionar esses dados com o valor m\u00e1ximo e a taxa de sucesso das solicita\u00e7\u00f5es est\u00e1ticas.<\/li>\n<\/ul>\n\n<p>Quando surgem lat\u00eancias inesperadas, verifico primeiro se o \u00abvalid\u00bb \u00e9 demasiado curto (demasiados re-stats) ou se o \u00abinactive\u00bb \u00e9 demasiado longo (ficheiros inativos). Retiro do cache diret\u00f3rios espec\u00edficos com erros e volto a medir. \u00c9 assim que isolo rapidamente as causas.<\/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\/08\/nginx_performance_5793.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Aspectos de seguran\u00e7a e fronteiras limpas<\/h2>\n\n<p>Eu separo <strong>claro<\/strong> distingo entre caminhos p\u00fablicos e internos e desativo o autoindex. No caso de aliases e liga\u00e7\u00f5es simb\u00f3licas, defino variantes restritivas (if_not_owner) para evitar percursos indesejados. S\u00f3 ativo o armazenamento em cache de erros quando compreendo o comportamento. Em ambientes multi-tenant, isolo as caches por vHost para evitar sobreposi\u00e7\u00f5es. Limites bem definidos tamb\u00e9m ajudam na depura\u00e7\u00e3o, pois permitem-me atribuir melhor os efeitos a cada zona.<\/p>\n\n<h2>Passos adicionais de afina\u00e7\u00e3o<\/h2>\n\n<p>Olho por cima do <strong>Cache de ficheiros<\/strong> Al\u00e9m disso, ajusto os par\u00e2metros de rede e TLS. As defini\u00e7\u00f5es de keepalive, a utiliza\u00e7\u00e3o de HTTP\/2 ou HTTP\/3 e os tempos de espera adequados influenciam significativamente as lat\u00eancias globais. No caso de ficheiros grandes, verifico o sendfile, o aio e os tamanhos dos buffers de sa\u00edda. Defino limites adequados para os tamanhos dos cabe\u00e7alhos e do corpo, para que as solicita\u00e7\u00f5es at\u00edpicas n\u00e3o bloqueiem tudo. Al\u00e9m disso, mantenho o registo de eventos de forma seletiva, para minimizar a sobrecarga <strong>manter<\/strong>.<\/p>\n\n<p>No que diz respeito \u00e0s aplica\u00e7\u00f5es, organizo as caches est\u00e1ticas e din\u00e2micas de forma a que n\u00e3o interfiram entre si. O controlo de vers\u00f5es de recursos de longo prazo atrav\u00e9s de hash reduz as revalida\u00e7\u00f5es e permite caches de cliente mais duradouras. Para as APIs, estabele\u00e7o regras curtas e claras e mantenho os ficheiros est\u00e1ticos separados. Separo as inst\u00e2ncias do NGINX por caso de utiliza\u00e7\u00e3o, quando o isolamento traz vantagens. A organiza\u00e7\u00e3o na configura\u00e7\u00e3o poupa tempo na opera\u00e7\u00e3o e na resolu\u00e7\u00e3o de problemas.<\/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\/08\/nginx_file_cache_performance_6789.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Brevemente resumido<\/h2>\n\n<p>Com um <strong>Aberto<\/strong> Com o cache de ficheiros, reduzo os acessos ao sistema de ficheiros, poupo tempo de CPU e entrego ficheiros est\u00e1ticos mais rapidamente. Come\u00e7o com valores modestos, avalio os efeitos reais e, depois, vou ajustando gradualmente os par\u00e2metros max, inactive, valid e min_uses. As pastas est\u00e1ticas beneficiam com isso; os pontos finais din\u00e2micos, por outro lado, deixo de fora. Em conjunto com o `sendfile`, o ajuste do buffer, a compress\u00e3o e limites de sistema s\u00f3lidos, consigo melhorar significativamente o desempenho global. Assim, o NGINX torna-se um servidor fi\u00e1vel <strong>Base<\/strong> para uma entrega r\u00e1pida e que poupa recursos.<\/p>","protected":false},"excerpt":{"rendered":"<p>Configure corretamente o Open File Cache do NGINX e obtenha um melhor desempenho para o seu servidor com os melhores par\u00e2metros.<\/p>","protected":false},"author":1,"featured_media":20891,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20898","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":"166","_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 Cache","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":"20891","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20898","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=20898"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20898\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/20891"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=20898"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=20898"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=20898"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}