<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Ipam on 魔都水滴</title>
    <link>https://blog.margrop.net/tag/ipam/</link>
    <description>Recent content in Ipam on 魔都水滴</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>zh-CN</language>
    <lastBuildDate>Mon, 13 Apr 2026 08:00:00 +0800</lastBuildDate>
    <atom:link href="https://blog.margrop.net/tag/ipam/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Docker 容器太多导致网段冲突：把自动分配网络统一迁回 172 私有段的完整记录</title>
      <link>https://blog.margrop.net/post/docker-network-subnet-conflict-migration-record/</link>
      <pubDate>Mon, 13 Apr 2026 08:00:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/docker-network-subnet-conflict-migration-record/</guid>
      <description>&lt;p&gt;这篇文章记录的是一次很典型、也很容易被忽略的 Docker 网络故障：容器越来越多，Docker 自动分配出来的 user-defined bridge 网段，最后落进了 &lt;code&gt;192.168.x.x&lt;/code&gt;，并且和家里的真实局域网发生了冲突。问题本身不算复杂，但它有一个很讨厌的特点：它不是那种“容器起不来”或者“端口没映射”的显性错误，而是把整个家庭网络拖进一个很别扭的半瘫痪状态。&lt;/p&gt;&#xA;&lt;p&gt;当时在我的 NAS 上，家里部分设备开始出现访问异常。表面上看，像是某个设备离线，或者某个交换机、AP、路由器出了毛病；但我沿着 Docker 的网络一路排查下去后，最终确认，真正的根因不是单个容器坏了，而是 Docker 网络池的自动分配策略，已经把局域网挤到了一个危险的位置。&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
