前阵子帮朋友调一套 vsomeip3 双机通信，两端代码都是从官方示例抄的，service 端和 client 端各自在单机上跑都正常，一拆到两台机器上就互相看不见。最后定位下来，问题全出在配置文件上。vsomeip3 的项目里，业务代码只是把服务 ID、实例 ID、方法 ID 告诉中间件，真正决定这台机器在网络上怎么宣告服务、怎么发现远程服务的，是那份 JSON 配置文件。这篇把服务端和客户端两边的 JSON 配置逐字段拆开讲清楚，再给一段可直接复制的双机联调流程和排错套路，适合正在调 vsomeip3 双机通信、又不想翻源码啃官方示例的工程师。
1. 双机通信的配置文件到底在管什么
先花点时间把概念对齐。很多人在做 vsomeip3 双机通信时，把注意力全放在代码里offer_service、request_service、subscribe_event这几个调用上，配 JSON 时一头雾水，觉得"我代码里都写了，为什么还要配一遍"。这个想法是后面所有坑的根源。
1.1 SOME/IP 的"地址"不止一个 IP
SOME/IP 的寻址模型，可以理解为三层地址叠加：
- 网络层：
IP + 端口，解决"数据到哪台机器的哪个 socket"。 - 服务层：
Service ID + Instance ID，解决"这台机器上哪个进程提供哪个服务"。 - 接口层：
Method ID / Event ID / Eventgroup ID，解决"调用服务的哪个方法 / 订阅服务的哪类事件"。
vsomeip3 的 JSON 配置，本质就是把这三层信息告诉协议栈。比如服务端配了service = 0x1234、instance = 0x5678、unreliable = 30509，协议栈才知道"这个端口上的报文属于哪个服务实例"，SD（Service Discovery）模块才知道"我该对外广播什么内容"。
客户端侧也一样。request_service(0x1234, 0x5678)只是让本地 routing manager 知道"我这个应用想要什么"，但路由管理器去哪个 IP、哪个端口找这个服务，要么靠 SD 动态发现，要么靠配置文件里写死的静态路由。
所以配置文件和代码不是重复关系，而是互补关系。代码表达"意图"，配置文件表达"位置"。
1.2 双机通信里 JSON 的三个核心职责
一份能跑通双机的配置，至少承担三个职责：
第一，声明本机的网络身份。unicast告诉 vsomeip3 本机用哪个 IP 参与通信，netmask用来判断对端是否在同一个子网，multicast字段则是指定 SD 服务发现报文发往哪个组播地址。
第二，声明本机提供的服务。服务端必须在services块里列出自己对外提供的 Service ID、Instance ID、端口和事件信息，协议栈才会把该服务注册到 SD 模块中，周期性向外发送 OfferService 报文。
第三，决定发现远程服务的方式。客户端要么通过 SD 在组播网络上"听"到服务端的 OfferService，要么在services块里通过remote字段直接指定服务端的 IP 和端口。这两种方式对应完全不同的配置写法，后面细说。
单机运行的时候，这三个职责基本可以全部豁免。同一个进程内、或者同一台机器上多个进程通过本地 routing manager 通信，数据根本不走物理网卡，也不需要 SD 参与。很多人单机调通了，就把同一份配置改个 IP 扔到双机上，结果组播不通、路由不对、ID 对不上，各种问题全冒出来。
1.3 双机场景为什么对配置的"一致性"要求极高
双机通信里，配置不是本机自洽就行的，两端的配置模型必须能互相咬合。需要两端一致的内容包括：
- Service ID、Instance ID、Method ID、Event ID、Eventgroup ID。
- SD 组播地址和 SD 端口（常见组合是
224.244.224.245:30490）。 - 传输协议的选择（UDP 还是 TCP），如果一方用
reliable另一方配错成unreliable，链路就建立不起来。 - 事件组的定义，服务端把 Event 归到哪个 Eventgroup，客户端的订阅请求就要对应哪个组。
而两端各自独立、不需要一致的内容包括：各自的unicastIP、各自应用的名字和 ID、各自占用的业务端口。这些内容搞混，是双机配置最常见的低级错误来源。
我在实际项目里习惯先画一张表，把上面这些"必须一致"的 ID 和"各自独立"的网络参数分别列出来，再动手写 JSON。这张表后面还能直接用作联调验收的核对清单，比对着两端配置肉眼找差异可靠得多。
2. 服务端 JSON 模板：让本机服务在网络里"挂牌"
服务端的配置目标很明确：把本机提供的服务挂到网络上，让 SD 模块能周期性广播出去，并告诉 routing manager 该在哪个本地端点接收请求。下面这份配置是我在 Ubuntu 22.04 + vsomeip3.1.6 上验证过的模板，可以直接作为起点改。
2.1 一份可以直接用的服务端配置
假设场景：服务端机器 IP 是192.168.1.10，对外提供服务0x1234 / 0x5678，使用 UDP 端口30509，包含一个事件0x8001，归入事件组1。
{ "unicast": "192.168.1.10", "netmask": "255.255.255.0", "multicast": "224.244.224.245", "logging": { "level": "info", "console": true, "file": { "path": "/tmp/vsomeip_service.log", "max_file_size": 1048576, "max_file_number": 5 } }, "applications": [ { "name": "service_sample", "id": "0x1001" } ], "services": [ { "service": "0x1234", "instance": "0x5678", "unreliable": 30509, "events": [ { "event": "0x8001", "eventgroups": [1] } ] } ], "service-discovery": { "enable": true, "multicast-address": "224.244.224.245", "port": 30490, "protocol": "udp", "initial-delay": 10, "repetition-base-delay": 100, "repetition-max": 3, "ttl": 255 } }2.2 逐字段拆解：哪些不能抄错
我不建议直接把上面的 JSON 复制走就完事，最好理解每个字段背后的原因。几个关键字段拆开看：
| 字段 | 作用 | 容易踩的坑 |
|---|---|---|
unicast | 本机参与通信的 IP，必须和网卡实际 IP 完全一致 | 写127.0.0.1、写错网卡、或写 hostname，SD 报文会发不出去 |
netmask | 判断对端是否同子网 | 双机跨网段时 SD 组播还通，但单播路由可能走错网卡 |
multicast | SD 报文使用的组播地址 | 两端必须一致，常见默认为224.244.224.245 |
applications[].name | 应用注册名，对应代码中get_name() | 必须和启动时VSOMEIP_APPLICATION_NAME或代码注册名一致 |
services[].service/instance | 服务的全局唯一标识 | 两端必须一致；只能写 4 位十六进制，如0x1234 |
unreliable | UDP 业务端口，服务端监听端口 | 不要和 SD 端口30490混用 |
events[].event/eventgroups | 事件 ID 和所属事件组 | 服务端声明的事件 ID 必须与代码offer_event的 ID 对应 |
service-discovery.enable | 是否启用 SD | 双机通信必须true；单机调通后忘了开，双机必挂 |
2.3 配置里的 services 和代码里的 offer_service 是什么关系
这里有个新手最容易误解的点：即使 JSON 里写好了services，代码里没有调用offer_service，这个服务也不会被 SD 广播出去；反过来，代码调用了offer_service，但 JSON 里没有对应条目，协议栈拿不到该服务的网络端点信息，同样无法完成有效宣告。
两者是"登记"和"挂牌"的关系。JSON 负责把服务的端口、事件、实例等静态信息登记进协议栈，代码里的offer_service负责在运行时发出"我要提供这个服务了"的状态切换。我在实际项目中见过两种失败案例：
一种是在配置里写了服务，但代码里没 offer，客户端永远 FOUND 不到。另一种是代码里 offer 了，配置里只写了services却漏写了service-discovery块，日志里能看到 OFFER 流程，但组播网上根本没有报文。两种都诡异，排查到最后都是配置与代码状态不一致。
所以服务端的配置和代码建议一起检查：配置里有的服务，代码里都要有对应的 offer 或注册逻辑；代码里 offer 的 ID，配置里都要有对应的端口条目。
2.4 reliable 和 unreliable 怎么选
unreliable对应 UDP，reliable对应 TCP。SOME/IP 天然支持这两种传输，vsomeip3 也保留了这套语义。
双机通信选哪个，主要看业务数据特征：
- 数据量小、实时性要求高、单包就能承载的，比如状态量、开关信号，用
unreliable（UDP）更合适，没有 TCP 的粘包、重传、队头阻塞问题。 - 数据量大、需要可靠交付的，比如诊断数据、大块配置下发、文件传输，用
reliable（TCP）更稳妥，底层协议栈帮你保证顺序和完整性。
注意事项：同一份配置里，同一个服务可以同时配置unreliable和reliable，vsomeip3 会分别监听 UDP 和 TCP 两个端口。但两端必须配套，服务端开的是 TCP，客户端request_service后协议栈也只会尝试建立 TCP 连接。如果另一端配成 UDP，两个 socket 永远对不上，日志里看起来就是"服务找到了但请求超时"。
3. 客户端 JSON 模板：从"本机注册"到"远程调用"
客户端的配置目标和服务端不同：它不需要对外挂牌，只需要让自己能"看见"并访问远程服务。所以客户端的 JSON 通常更短，但一个关键选择会直接影响整个配置结构：用 SD 动态发现，还是用 remote 静态路由。
3.1 最小可用的客户端配置
假设客户端机器 IP 是192.168.1.11，应用名client_sample，通过 SD 发现服务端0x1234 / 0x5678：
{ "unicast": "192.168.1.11", "netmask": "255.255.255.0", "multicast": "224.244.224.245", "logging": { "level": "info", "console": true }, "applications": [ { "name": "client_sample", "id": "0x2001" } ], "service-discovery": { "enable": true, "multicast-address": "224.244.224.245", "port": 30490, "protocol": "udp", "initial-delay": 10 } }这份配置里没有services块，因为客户端不提供服务。它要做的事只有一件：加入224.244.224.245:30490这个组播组，监听 SD 报文。一旦收到服务端发来的 OfferService，协议栈就自动知道远程服务的 IP 和端口。
3.2 两种发现方式：SD 动态发现和 remote 静态路由
SD 动态发现是 SOME/IP 的标准工作方式，但也有不适用的时候。vsomeip3 的配置文件提供了另一种手段：在services块中通过remote字段直接指定远程服务端的位置。
"services": [ { "service": "0x1234", "instance": "0x5678", "remote": [ { "address": "192.168.1.10", "port": 30509 } ] } ]这两种方式各有明确的适用场景：
| 对比项 | SD 动态发现 | remote 静态路由 |
|---|---|---|
| 是否依赖组播 | 是，组播不通就白搭 | 否，直接单播连接 |
| 服务端 IP 是否需要在客户端写死 | 不需要 | 需要 |
| 服务端重启后能否自动恢复 | 能，SD 会重新发现 | 依赖 vsomeip 的重连机制 |
| 虚拟机 NAT / 防止组播的网络 | 大概率失败 | 稳定可用 |
| 配置复杂度 | 低，客户端不用写服务块 | 高，要写对端 IP 和端口 |
我的建议是：能用 SD 就用 SD，这是 SOME/IP 的常规用法，服务端换 IP 后客户端无需改动；但如果你的网络环境组播受限，或者双机之间隔了不归你管的三层设备，果断切 remote 静态路由，别跟组播死磕。
3.3 客户端重复声明服务会导致什么后果
如果你选择了 SD 动态发现，客户端 JSON 里不要画蛇添足地把远程服务写进services块。vsomeip3 会把services块中的条目当作本机需要关心端点的服务，如果写成：
"services": [ { "service": "0x1234", "instance": "0x5678", "unreliable": 30509 } ]客户端会认为0x1234 / 0x5678就是本机提供的服务，试图在自己本机占用30509端口。如果端口被占用或者服务端配置冲突，会出现各种莫名其妙的启动报错。
反过来，如果走 remote 静态路由，就必须把services块写好，而且remote里的address和port要和服务端配置的unicast、unreliable完全对应。服务端监听在 UDP 30509，客户端 remote 里写 TCP 30509，也会一直连不上。
3.4 发布/订阅事件的配置边界在哪里
聊事件订阅前，先理清哪些是代码的事、哪些是配置的事。
服务端要做的配置：在services块的事件数组里声明eventID 和eventgroups，例如事件0x8001归属于事件组1。代码里调用offer_event(0x8001)，这样 SD 模块才知道"这个事件对外可见"。
客户端要做的代码操作：request_service(0x1234, 0x5678)，然后subscribe_event(0x1234, 0x5678, 0x8001, ...)。订阅请求通过 SD 的 Subscribe 报文发给服务端，服务端返回 SubscribeAck 后，事件数据才开始流动。
客户端配置里需要重复声明这个事件吗？在标准 SD 工作方式下，不需要。客户端的订阅意图完全由代码表达，配置里不需要写 event 或 eventgroup。但如果你用 remote 静态路由、并且关闭了 SD，部分旧版 vsomeip 行为会有差异，这种场景下我建议把事件相关配置也在客户端services块中补齐，避免客户端协议栈因缺少事件组信息而拒绝处理事件数据。
4. 两台机器联调：完整启动顺序与验证日志
配置写完了，接下来是验证环节。我见过不少人在这一步跳过系统性的启动顺序，随手设个环境变量就跑，结果日志看了一堆还是不知道问题在哪。下面这套联调步骤是我自己一直在用的，按顺序做完，能快速定位 90% 的双机通信问题。
4.1 联调前的环境检查清单
不要急着启动程序，先把网络基础确认好：
- 两台机器在同一子网，例如
192.168.1.10/24和192.168.1.11/24，用ping确认互通。 - 防火墙放行 UDP
30490（SD 端口）和 UDP30509（业务端口），以及组播流量。Ubuntu 上我通常先临时关掉 ufw 排除干扰：sudo ufw disable，等联调通过再按需开启。 - 确认组播路由。可以先执行
ip route show | grep 224.244.224.245，没有对应路由的话，sudo ip route add 224.244.224.245 dev eth0加上，注意替换成真实网卡名。 - 服务端代码中
offer_service的 ID 和配置里services块的 ID 核对一致；客户端代码中request_service的 ID 和预期服务 ID 核对一致。
4.2 服务端启动：先看到 OFFER
服务端启动，推荐用环境变量方式指定配置文件：
export VSOMEIP_CONFIGURATION=/opt/vsomeip/config/service.json export VSOMEIP_APPLICATION_NAME=service_sample ./service-exampleVSOMEIP_APPLICATION_NAME必须和 JSON 里applications[].name一致，否则 vsomeip3 找不到对应的应用 ID，启动阶段就会报错。
启动后，留意日志里出现下面这些关键行：
OFFER SERVICE 0x1234：说明服务端已经通知 SD 模块对外提供0x1234。- 如果
service-discovery里配了"initial-delay": 10，OFFER 报文不会立刻发出，而是延迟 10 秒后才周期性广播。这个参数的意义是给应用足够时间完成初始化，避免在服务还没就绪时就对外宣告。
不要一启动就转头去看客户端，先确认 OFFER 日志出现，再继续。
4.3 客户端启动：等到 FOUND
客户端启动：
export VSOMEIP_CONFIGURATION=/opt/vsomeip/config/client.json export VSOMEIP_APPLICATION_NAME=client_sample ./client-example客户端启动后最该看到的关键日志是FOUND SERVICE 0x1234/0x5678。这行日志意味着协议栈通过 SD 报文学习到了远程服务的网络端点，本地的 routing manager 已经为这个服务建立了路由信息。
如果迟迟看不到 FOUND，不要急着把客户端代码翻个底朝天，先回去看第 5 节，大概率是网络或者双方配置的一致性问题。我第一次调双机时，来回改代码改了一天，最后发现是服务端机器防火墙把组播挡了，白白浪费十几个小时。
4.4 方法调用和事件订阅的验证
看到 FOUND 之后再验证业务逻辑才有意义：
- 方法调用：客户端调用
call_method，服务端日志出现收到请求、客户端能收到响应，说明 method 路径通了。 - 事件订阅：代码里
subscribe_event成功后，服务端日志会出现SUBSCRIBE和随后的SUBSCRIBE ACK。客户端每次收到事件数据时，on_event回调会被触发。
如果方法调用和事件都能通，双机通信的配置就算真正闭环了。但你大概率不会一次就全通，所以下面这部分才是重点。
5. 配置不一致的坑：从现象到根因的排查链路
这一节把我自己踩过的、以及帮别人排查过的双机配置问题集中写出来。每个坑都会给出现象、排查链路和最终解法，而不是只丢结论。
5.1 组播被吃掉：客户端永远等不到 FOUND
现象：服务端日志正常输出 OFFER，客户端日志里没有任何 FOUND，两端 IP 能 ping 通，业务端口用 netcat 也通，但 SD 就是过不去。
排查链路是这样走的：
第一步，在客户端机器上抓包确认组播是否到达本机：
sudo tcpdump -i eth0 host 224.244.224.245 and udp port 30490 -vv如果这个命令在客户端上没有任何输出，说明 SD 组播报文根本没有到达客户端网卡。
第二步，回到服务端抓包，确认报文确实发了出去：
sudo tcpdump -i eth0 host 224.244.224.245 and udp port 30490 -vv服务端能看到自己的 OfferService 组播报文、客户端却抓不到，问题几乎可以锁定在网络中间的链路上，而不是 vsomeip 配置本身。
第三步，排查以下最常见的原因：
- 虚拟机 NAT 网络：VMware/VirtualBox 的 NAT 模式默认不会转发组播，改成桥接网络即可解决。
- 交换机 IGMP Snooping：某些三层交换机开启了 IGMP Snooping 但没有组播路由器，组播出不去。临时验证可以把该功能关掉，或者把两个端口加入同一个组播 VLAN。
- 主机防火墙：系统防火墙不一定拦 ping，但可能拦 UDP 组播。用
sudo iptables -L -n检查是否有丢弃规则。
如果这些网络因素的排查成本太高，直接切换为 remote 静态路由配置，客户端在services块里写死服务端 IP 和端口，完全绕开组播。这是我在几套生产环境里的做法——网络不归自己管时，不跟组播硬磕。
5.2 多网卡机器上 unicast 写错导致的"漂移"
现象：服务端有多张网卡，比如eth0是管理网段10.0.0.1，eth1是业务网段192.168.1.10，配置里unicast写了192.168.1.10，但 tcpdump 发现 OfferService 组播报文从eth0发出去了，客户端自然收不到。
这个问题在双机部署非常常见。vsomeip3 的unicast不仅仅是"标识自己是谁"，还直接参与协议栈绑定的本地端点选择。配置里写了哪个 IP，协议栈就认为这个 IP 对应的网卡是唯一可用的通信接口。
排查链路：
- 执行
tcpdump -i any host 224.244.224.245看报文具体从哪个接口出去。 - 检查
ip addr，确认unicast是否是该接口上真实绑定的 IP。 - 检查系统路由，看目的地
192.168.1.11的流量是否会从业务网卡走：
如果结果显示走的是ip route get 192.168.1.11eth0，说明业务网卡缺少到对端的清晰路由，或者业务网卡根本没配独立网段。
解决办法有两个层面：
- OS 层面：添加组播路由，强制组播从业务网卡走：
sudo ip route add 224.244.224.245 dev eth1。 - 配置层面：确认
unicast与业务网卡 IP 一致。部分 vsomeip3 版本还支持配置device字段显式指定网卡名，如果你的版本支持，优先用device锁定接口，避免系统路由策略干扰。
5.3 两端 ID 对不上：OFFER 和 FOUND 鸡同鸭讲
现象：客户端能发现服务，但调用方法报错，日志里始终没有对应的响应，或者事件的回调从不触发。
这种问题大多出在"必须一致"的 ID 列表上。我整理过一个排查对照表，联调时只要有异常就逐个核对：
| 排查项 | 服务端配置/代码 | 客户端配置/代码 |
|---|---|---|
| Service ID | services[].service = 0x1234 | request_service(0x1234, ...) |
| Instance ID | services[].instance = 0x5678 | request_service(..., 0x5678, ...) |
| Method ID | 代码offer_method(0x0001) | 代码call_method(0x0001) |
| Event ID | events[].event = 0x8001 | subscribe_event(..., 0x8001, ...) |
| Eventgroup | events[].eventgroups = [1] | 订阅时指定的事件组 |
| 业务端口 | unreliable/reliable | SD 自动发现 或remote[].port |
| 传输协议 | UDP 或 TCP | 客户端必须匹配 |
这里有个细节：vsomeip3 配置文件里的 ID 都是字符串形式的十六进制，大小写不敏感，但格式有要求。0x1234合法，1234可能被解析成十进制。如果配置是从老项目里拷的，注意核对是不是漏了0x前缀。
这类问题没有捷径，只能逐项核对。我的习惯是把这份对照表直接变成联调文档，每次发版前先过一遍，能省掉大量抓狂时间。
5.4 事件不触发：事件 ID 和事件组不匹配
现象：客户端能 FOUND 服务，方法调用也正常，但服务端一发布事件，客户端回调死活不执行。
这种问题通常出在事件订阅链路的一个细节上：事件 ID 和事件组在服务端配置里对不上。
vsomeip3 的订阅分发逻辑是：客户端订阅时携带事件 ID，服务端 SD 模块检查该事件属于哪个事件组，再决定是否返回 SubscribeAck。如果服务端配置里事件组的声明有问题，即使代码逻辑看起来对，订阅也建立不起来。
排查链路：
- 确认服务端代码的
offer_event事件 ID 与配置events[].event完全一致。 - 确认配置里
eventgroups数组的值与客户端subscribe_event时的事件组一致。比如配置里事件组是[1]，客户端订阅的却是2，订阅就会被忽略。 - 查看服务端日志是否有
SUBSCRIBE但没有SUBSCRIBE ACK。有前者无后者，基本可以断定事件组不匹配，或者服务端的事件注册晚于客户端的订阅请求。 - 服务端代码如果是服务启动后才
offer_event，而客户端的订阅在 FOUND 之后立即发出，就可能出现"订阅请求到达时事件还没注册"的偶发问题。处理方式是让客户端在收到事件注册信息后再订阅，或者服务端初始化完成前先不开 SD，用initial-delay给足准备时间。
6. 日志与抓包：确认配置是否真正生效
最后一个环节是学会让 vsomeip3 自己开口说话。很多人排错靠猜，改一行配置重跑一次，效率极低。vsomeip3 的日志系统和抓包工具其实非常够用，只是默认配置下信息量太少，看起来像"没日志"。
6.1 把日志级别开到 trace
双机联调阶段，建议把日志级别设为trace，这是最能暴露问题的级别。日志配置块长这样：
"logging": { "level": "trace", "console": true, "file": { "path": "/tmp/vsomeip_trace.log", "max_file_size": 1048576, "max_file_number": 10 } }console: true保证日志直接打到终端，file块同时落盘，避免终端滚动太快丢信息。max_file_size和max_file_number是滚动日志配置，线上环境建议保留，避免日志文件撑爆磁盘。
注意：trace 级别日志量非常大，联调时可以开着，稳定性验证阶段改回info。否则几十台设备同时跑起来，光日志就能把磁盘写满。
6.2 日志里的关键关键词
不同版本的 vsomeip3 日志格式略有差异，但关键事件的关键词大体一致。我在排障时主要盯这几类：
| 日志关键词 | 含义 | 该出现的位置 |
|---|---|---|
Registered application | 应用注册成功，配置里applications匹配成功 | 两端启动时 |
OFFER SERVICE | 服务端开始对外宣告服务 | 服务端日志 |
FOUND SERVICE | 客户端通过 SD 学习到远程服务 | 客户端日志 |
SUBSCRIBE | 客户端发起事件订阅 | 服务端日志 |
SUBSCRIBE ACK | 服务端确认订阅成功 | 客户端日志和服务端日志 |
REQUEST SERVICE | 客户端请求服务 | 客户端日志 |
Route/endpoint | routing manager 建立路由 | 两端日志 |
如果服务端日志里出现了OFFER SERVICE却一直没有客户端对应的FOUND SERVICE，问题在网络层；如果客户端FOUND之后方法调用失败，问题多半在 ID 对照或传输协议不匹配；如果SUBSCRIBE之后没有SUBSCRIBE ACK，问题在事件组配置。
6.3 用 tshark 核对 SD 报文
日志是协议栈内部视角，抓包则是网络视角，两个视角交叉验证，能快速判断配置到底有没有从"文件层面"生效到"报文层面"。
抓取 SD 报文：
sudo tshark -i eth0 -f "udp port 30490" -V-V参数会输出报文的详细结构。重点关注：
- SOME/IP-SD 报文里的
Service ID和Instance ID是否和配置一致。 - Entry 类型：服务端发的是
OfferService Entry，客户端发的是FindService Entry。如果客户端在发 FindService，说明它正在主动寻找服务；如果客户端抓不到任何 SD 报文，说明它根本没有加入组播，问题回到网络层。 - Option 里的
EndpointOption：服务端宣告的 IP 和端口是否和配置的unicast、unreliable一致。这里经常能发现"配置写的端口和代码实际监听的端口不一致"的怪问题。
抓包还有一个额外好处：能同时看到 SD 报文的 TTL 字段。如果服务端的 TTL 配置得太短，客户端会频繁认为服务过期。SD 标准建议 TTL 至少大于等于宣告周期，ttl: 255是个稳妥值。
我自己在双机联调时的习惯做法是：终端窗口 A 开 tshark 抓 SD，终端窗口 B 跑服务端，终端窗口 C 跑客户端。看到报文流起来，再对照日志，整个配置链路是否生效一目了然，比盲调高效得多。
最后分享一个我自己一直遵守的调试顺序：先把两端放到同一台机器的两个网络命名空间或者桥接网络里，用官方示例配合上面这份配置跑通，再挪到真实双机环境。如果换了环境立刻又挂，优先怀疑组播，而不是代码。vsomeip3 配置文件是标准 JSON，字段名区分大小写，复制模板时特别注意别把multicast-address漏了横线、把unreliable拼错，这类低级错误我至少帮人排查过三回，基本都是手抄配置抄出来的。祝你们双机一次点亮。
