<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Nginx on Alexander's Blog</title><link>https://alexanderbakin.com/tags/nginx/</link><description>Recent content in Nginx on Alexander's Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 20 Aug 2026 17:43:42 +0400</lastBuildDate><atom:link href="https://alexanderbakin.com/tags/nginx/index.xml" rel="self" type="application/rss+xml"/><item><title>The Wildcard That Broke Nginx Log Rotation</title><link>https://alexanderbakin.com/logrotate-wildcard-bug/</link><pubDate>Sat, 05 Jul 2025 00:00:00 +0000</pubDate><guid>https://alexanderbakin.com/logrotate-wildcard-bug/</guid><description>&lt;p&gt;One of those infrastructure problems that looks simple, until you realize the filename itself is part of the problem.&lt;/p&gt;
&lt;h2 id="the-setup"&gt;The Setup&lt;/h2&gt;
&lt;p&gt;We had Nginx configured to handle wildcard subdomains: &lt;code&gt;server_name *.example.com;&lt;/code&gt;, with access logs named after the server block. That&amp;rsquo;s a convenient pattern for multi-tenant setups where subdomains get created dynamically and you don&amp;rsquo;t want to hand-maintain a vhost file per tenant. Nginx doesn&amp;rsquo;t care that the resulting log filename contains a literal &lt;code&gt;*&lt;/code&gt; - it just opens the file and writes to it.&lt;/p&gt;</description></item></channel></rss>