<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Reverse-Proxy on Margrop Blog</title>
    <link>https://blog.margrop.net/en/tag/reverse-proxy/</link>
    <description>Recent content in Reverse-Proxy on Margrop Blog</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-US</language>
    <lastBuildDate>Fri, 26 Jun 2026 12:30:00 +0800</lastBuildDate>
    <atom:link href="https://blog.margrop.net/en/tag/reverse-proxy/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Docker Images, No More Begging: Build Your Own 13 GB Private Registry From Scratch</title>
      <link>https://blog.margrop.net/en/post/build-private-docker-registry-without-hassle/</link>
      <pubDate>Fri, 26 Jun 2026 12:30:00 +0800</pubDate>
      <guid>https://blog.margrop.net/en/post/build-private-docker-registry-without-hassle/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;My home server runs a single &lt;code&gt;registry:2&lt;/code&gt; container that currently holds &lt;strong&gt;13 GB of cached blobs across 95 repositories&lt;/strong&gt;. Every NAS, Proxmox node, Mac, and Windows machine on my LAN pulls through it. A cold start of &lt;code&gt;alpine:3.19&lt;/code&gt; finishes in under a second, with zero traffic going out to the public Docker Hub.&lt;/p&gt;&#xA;&lt;p&gt;This isn&amp;rsquo;t a one-line &amp;ldquo;install Docker and run a container&amp;rdquo; tutorial. I&amp;rsquo;ll show you the &lt;strong&gt;production-grade deployment script I actually run&lt;/strong&gt;, walk through the Docker v2 auth flow, and call out the four reverse-proxy pitfalls that turn every &lt;code&gt;docker login&lt;/code&gt; into a 401 mystery. You&amp;rsquo;ll leave able to: ① bring up an authenticated registry in 10 minutes; ② explain why the &lt;code&gt;WWW-Authenticate&lt;/code&gt; header is sacred; ③ describe the whole thing to a non-technical family member without losing accuracy.&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>Why a NAS hostname with `speedtest` can sometimes be much faster</title>
      <link>https://blog.margrop.net/en/post/nas-speedtest-subdomain-acceleration/</link>
      <pubDate>Fri, 24 Apr 2026 09:00:00 +0800</pubDate>
      <guid>https://blog.margrop.net/en/post/nas-speedtest-subdomain-acceleration/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;Short version&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;If your NAS is painfully slow when accessed from outside your home, and you control both your domain name and your reverse-proxy entry, putting &lt;code&gt;speedtest&lt;/code&gt; into the subdomain can sometimes make a dramatic difference.&lt;br&gt;&#xA;This is not magic and it is not guaranteed, but it often appears to hit a more permissive carrier policy path for “speed-test-like” traffic.&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;This post was inspired by a discussion on the fnNAS forum. The original thread makes a very direct claim: some home broadband lines seem to throttle ordinary NAS access quite aggressively, but once the hostname contains &lt;code&gt;speedtest&lt;/code&gt;, the connection can suddenly behave much better.&lt;/p&gt;&#xA;&lt;p&gt;I am not repeating the forum post word for word. Instead, I am turning the idea into a longer-lived technical note that answers three questions:&lt;/p&gt;&#xA;&lt;ol&gt;&#xA;&lt;li&gt;Why this trick can work&lt;/li&gt;&#xA;&lt;li&gt;How to set it up with the least amount of moving parts&lt;/li&gt;&#xA;&lt;li&gt;When it will not work, or is not worth the effort&lt;/li&gt;&#xA;&lt;/ol&gt;</description>
    </item>
  </channel>
</rss>
