<p>systemd服务无法直接绑定网络命名空间，需通过nsenter进入预创建的netns运行：先用ip netns add创建命名空间并配好veth、IP、路由及宿主机转发/SNAT，再在.service文件中以ExecStart=/usr/bin/nsenter -n -U --preserve-credentials -r /var/run/netns/myapp -- /usr/bin/myserver方式启动。</p>
systemd 服务本身不直接支持“绑定到指定网络命名空间”这一配置项，但可以通过组合 systemd 单元文件、Linux 网络命名空间（netns）和 nsenter 或 unshare 实现服务在专用 netns 中运行——关键在于让服务进程的整个生命周期都处于目标命名空间内。
创建并持久化网络命名空间
网络命名空间需提前创建并确保其在系统重启后仍存在（因为 ip netns 创建的命名空间默认只存在于内存中）：
- 用
ip netns add myapp创建命名空间，它会在/var/run/netns/myapp下生成绑定文件 - 若需开机保留，建议配合 systemd 服务单元，在启动时自动重建（例如通过
ExecStartPre=/usr/bin/ip netns add myapp） - 注意：仅靠
ip netns创建的命名空间无法直接被 systemd 服务引用，必须通过nsenter进入执行
在服务单元中使用 nsenter 启动进程
修改服务的 .service 文件，在 [Service] 段中用 nsenter 包裹实际命令：
- 假设已创建
myapp命名空间，且 veth 已配好、IP 和路由就绪 - 将原
ExecStart=/usr/bin/myserver --port=8080改为：ExecStart=/usr/bin/nsenter -n -U --preserve-credentials -r /var/run/netns/myapp -- /usr/bin/myserver --port=8080 -
-n表示进入网络命名空间，-U和--preserve-credentials保证用户权限不丢失，-r重新挂载 proc/sysfs（必要时）
确保命名空间内基础网络就绪
单纯进入 netns 不等于网络可用。服务启动前，命名空间必须具备完整三层能力：
- lo 接口已启用：
ip netns exec myapp ip link set lo up - veth 对端已配 IP 并启用（如
192.168.100.1/24在 host，192.168.100.2/24在 netns） - 默认路由已设置：
ip netns exec myapp ip route add default via 192.168.100.1 - 若需访问外网，宿主机要开启
ip_forward，并配置 SNAT（MASQUERADE）
验证与调试技巧
服务启动后，快速确认是否真正运行在目标 netns 内：
- 查服务进程的网络命名空间：
readlink /proc/$(pidof myserver)/ns/net，应指向/var/run/netns/myapp - 在 netns 内检查监听地址：
sudo ip netns exec myapp ss -tln，应只看到服务绑定在127.0.0.1:8080或192.168.100.2:8080，而非 host 的 IP - 从 host curl 测试连通性：
curl http://192.168.100.2:8080；换另一个 netns 尝试则应失败
