<?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 Proxy Manager auf cbrueggenolte.de</title>
    <link>https://cbrueggenolte.de/tags/nginx-proxy-manager/</link>
    <description>Neueste Beiträge in Nginx Proxy Manager auf cbrueggenolte.de</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>de-DE</language>
    <managingEditor>96ca5227@cbrueggenolte.de (cbrueggenolte.de)</managingEditor>
    <webMaster>96ca5227@cbrueggenolte.de (cbrueggenolte.de)</webMaster>
    <copyright>2018-2026 cbrueggenolte</copyright>
    <lastBuildDate>Thu, 19 Mar 2026 00:11:52 +0100</lastBuildDate>
    <atom:link href="https://cbrueggenolte.de/tags/nginx-proxy-manager/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Die .127-Falle: Wie ein /25-Subnetz meinen Reverse Proxy sabotiert hat</title>
      <link>https://cbrueggenolte.de/die-127-falle-subnetz-502/</link>
      <pubDate>Thu, 19 Mar 2026 00:11:52 +0100</pubDate><author>96ca5227@cbrueggenolte.de (cbrueggenolte.de)</author>
      <guid>https://cbrueggenolte.de/die-127-falle-subnetz-502/</guid>
      <description>&lt;p&gt;Es gibt diese Fehler, bei denen man sich sicher ist: &lt;em&gt;Das kann eigentlich nicht falsch sein.&lt;/em&gt;&#xA;Alles sieht korrekt aus – und trotzdem funktioniert es nicht.&lt;/p&gt;&#xA;&lt;p&gt;In meinem Fall lief Gitea sauber auf &lt;code&gt;192.168.10.127:3000&lt;/code&gt;. Lokal war alles erreichbar, DNS zeigte korrekt auf den Server, und auch der Nginx Proxy Manager war wie gewohnt konfiguriert. Trotzdem endete jeder Zugriff über die Domain in einem &lt;strong&gt;502 Bad Gateway&lt;/strong&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Die üblichen Checks brachten nichts. Upstream stimmte, Protokoll passte, keine offensichtlichen Netzwerk- oder Firewall-Probleme. Es sah einfach alles richtig aus.&lt;/p&gt;</description>
      <content:encoded><![CDATA[<p>Es gibt diese Fehler, bei denen man sich sicher ist: <em>Das kann eigentlich nicht falsch sein.</em>
Alles sieht korrekt aus – und trotzdem funktioniert es nicht.</p>
<p>In meinem Fall lief Gitea sauber auf <code>192.168.10.127:3000</code>. Lokal war alles erreichbar, DNS zeigte korrekt auf den Server, und auch der Nginx Proxy Manager war wie gewohnt konfiguriert. Trotzdem endete jeder Zugriff über die Domain in einem <strong>502 Bad Gateway</strong>.</p>
<p>Die üblichen Checks brachten nichts. Upstream stimmte, Protokoll passte, keine offensichtlichen Netzwerk- oder Firewall-Probleme. Es sah einfach alles richtig aus.</p>
<p>Der Wendepunkt kam durch einen simplen Test im Proxy-Container:</p>





<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="ln">1</span><span class="cl">ping 192.168.10.127</span></span></code></pre></div><p>Die Antwort war unerwartet:</p>





<pre tabindex="0"><code>Do you want to ping broadcast? Then -b.</code></pre><p>Spätestens da war klar: Das ist kein klassisches Proxy-Problem, sondern etwas auf Netzwerkebene.</p>
<p>Ein Blick auf die IP-Konfiguration brachte die Erklärung. Das Interface lief mit einem <code>/25</code>-Subnetz. Damit liegt der Adressbereich bei <code>192.168.10.0 – 192.168.10.127</code> – und die <code>.127</code> ist in diesem Fall die Broadcast-Adresse.</p>
<p>Genau diese Adresse hatte ich aber für Gitea verwendet.</p>
<p>Für den Container war <code>192.168.10.127</code> also kein gültiger Host, sondern Broadcast. Entsprechend konnte keine Verbindung aufgebaut werden. Der Reverse Proxy lief ins Leere und quittierte das mit einem 502.</p>
<p>Lokal funktionierte weiterhin alles, weil der Zugriff nicht über diesen Netzwerkpfad ging. Das machte den Fehler besonders verwirrend: Je nachdem, wo man testete, sah alles entweder völlig in Ordnung oder komplett kaputt aus.</p>
<p>Der Fix war letztlich simpel: Subnetz von <code>/25</code> auf <code>/24</code> ändern. Testweise direkt im Container – danach dauerhaft in der Proxmox-Konfiguration:</p>





<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="ln">1</span><span class="cl"><span class="c1"># vorher</span>
</span></span><span class="line"><span class="ln">2</span><span class="cl"><span class="nv">ip</span><span class="o">=</span>192.168.10.105/25
</span></span><span class="line"><span class="ln">3</span><span class="cl">
</span></span><span class="line"><span class="ln">4</span><span class="cl"><span class="c1"># nachher</span>
</span></span><span class="line"><span class="ln">5</span><span class="cl"><span class="nv">ip</span><span class="o">=</span>192.168.10.105/24</span></span></code></pre></div><p>Nach einem Neustart war das Problem sofort verschwunden. Der Proxy konnte den Upstream erreichen, Gitea war über die Domain verfügbar, und der 502 war Geschichte.</p>
<p>Am Ende war es weder ein Problem mit Gitea noch mit Nginx oder DNS – sondern schlicht ein falsch gewähltes Subnetz.</p>
<p>Die Lektion daraus: Wenn etwas komplett unlogisch wirkt, lohnt sich fast immer ein Blick aufs Netzwerk. Gerade bei Subnetzen reichen kleine Details, um alles scheinbar „korrekt“ aussehen zu lassen – während es in Wirklichkeit gar nicht funktionieren kann.</p>
]]></content:encoded>
    </item>
  </channel>
</rss>
