[Bug] Store IpUtil.getNearestAddress logs ERROR for hostname addresses and can return 127.0.0.1

Start with hugegraph-store/hg-store-core/src/main/java/org/apache/hugegraph/store/util/IpUtil.java, then inspect the calls in HeartbeatService.java and the Docker Compose and Store README examples. Reproduce the hostname and single-interface cases described in the issue before changing behavior. Done means hostnames remain unchanged without misleading ERROR logs, loopback is not selected, and the Store address examples still behave correctly.

Bug Type (问题类型)

logic (逻辑设计问题)

Before submit

• I have confirmed and searched that there are no similar problems in the historical issue and documents. (Searched open and closed issues and PRs for IpUtil, getNearestAddress, getRaftAddress, "raft address hostname". #3124 is about stale DNS after Store pod replacement and does not touch this code.)

Environment (环境信息)

• Server Version: apache/hugegraph master 176fb56dd (2026-10-02). All line numbers below are on that commit.
• Backend: HStore, 3 PD + 3 Store + 3 Server on kind, installed with the HugeGraph Helm chart (2026-09-22). Store logs from a 3-node k3s run on 2026-09-19 (image 1.7.0, whose IpUtil.java is identical to master) show the same two ERROR lines once per Store start, followed by Register Store ... successfully with the DNS addresses unchanged.
• Standalone repro: IpUtil.java copied unchanged from 176fb56dd, compiled with JDK 17 --release 11, run in eclipse-temurin:11-jre-jammy (sha256:76ffb747ad3a) on 2026-10-02.
• Data Size: not relevant.

Expected & Actual behavior (期望与实际表现)

Code path

1. getIpAddress() (hugegraph-store/hg-store-core/src/main/java/org/apache/hugegraph/store/util/IpUtil.java:42-56) collects every Inet4Address on every interface. It does not skip loopback, link-local or down interfaces, so a Kubernetes pod or a bridge-network container returns two addresses: 127.0.0.1 and the pod or container IP.
2. With two or more addresses, getNearestAddress() splits the configured host on . and calls Integer.parseInt on each part (IpUtil.java:76-78). For a DNS name this throws NumberFormatException. The catch at IpUtil.java:96-97 logs it at ERROR as getRaftAddress, got exception, For input string: "<first label>", and IpUtil.java:99 returns the input unchanged. The message names getRaftAddress, a method that does not exist in this class.
3. With exactly one address, IpUtil.java:72-74 returns that address with the configured port and never looks at the configured host. Because loopback is counted, the single address is 127.0.0.1 when the container has no other interface.

Callers and frequency

HeartbeatService.registerStore() calls it twice, once for the gRPC address and once for the raft address (hugegraph-store/hg-store-core/src/main/java/org/apache/hugegraph/store/HeartbeatService.java:186-187), so each registration attempt logs two ERROR lines. registerStore() runs only while the Store state is Unknown or Offline (HeartbeatService.java:126-130). It repeats until registration succeeds (retry delay 1000 ms at :69, 500 ms when PD returns id 0 at :211), and runs again after each transition to Offline (heartbeat stream closed at :203, or more than 5 consecutive heartbeats reporting Cluster_Fault, :54 and :266-273). Once the Store is Up, storeHeartbeat() (:231-279) does not call IpUtil. The log is therefore per registration attempt, not per heartbeat. A healthy Store prints the pair once per start; a Store waiting for PD prints it on every retry.

Hostname addresses are the normal setup. The bundled compose file uses them (docker/docker-compose-3pd-3store-3server.yml:165 HG_STORE_GRPC_HOST: store0, :168 HG_STORE_RAFT_ADDRESS: store0:8510), and on Kubernetes the stable address of a StatefulSet pod is its headless-service DNS name.

Repro output (Repro prints the IPv4 list, then calls IpUtil.getNearestAddress on each argument)

### docker run --network bridge --hostname hugegraph-store-0 ...
ipv4s: [eth0=192.168.215.2, lo=127.0.0.1]
[main] ERROR org.apache.hugegraph.store.util.IpUtil - getRaftAddress, got exception, For input string: "hugegraph-store-0"
hugegraph-store-0.hugegraph-store.default.svc.cluster.local:8500 -> hugegraph-store-0.hugegraph-store.default.svc.cluster.local:8500
[main] ERROR org.apache.hugegraph.store.util.IpUtil - getRaftAddress, got exception, For input string: "hugegraph-store-0"
hugegraph-store-0.hugegraph-store.default.svc.cluster.local:8510 -> hugegraph-store-0.hugegraph-store.default.svc.cluster.local:8510
10.244.1.9:8510 -> 127.0.0.1:8510

### docker run --network none --hostname hugegraph-store-0 ...
ipv4s: [lo=127.0.0.1]
hugegraph-store-0.hugegraph-store.default.svc.cluster.local:8500 -> 127.0.0.1:8500
hugegraph-store-0.hugegraph-store.default.svc.cluster.local:8510 -> 127.0.0.1:8510
10.244.1.9:8510 -> 127.0.0.1:8510

Expected

• A configured hostname is returned unchanged, without an ERROR log.
• 127.0.0.1 is never chosen as the address the Store registers with PD.

Actual

• Two ERROR lines per registration attempt for any hostname address, naming the wrong method. The returned address is correct, so the ERROR misleads operators who are debugging a Store that does not come up.
• With one local IPv4, a hostname is silently replaced by that IP. In the repro that IP is 127.0.0.1.
• With an IPv4 literal that is not bound locally, the sort picks the numerically closest local address. For 10.244.1.9 in the repro that is 127.0.0.1. The Store README's docker run example sets the host IP (hugegraph-store/README.md:363-364) on a bridge-network container, where that IP is not bound.

Fix direction

• In getIpAddress(), skip loopback and link-local addresses (isLoopbackAddress(), isLinkLocalAddress()).
• In getNearestAddress(), return the configured address unchanged when the host is not a dotted IPv4 literal. Check this before the single-address shortcut at :72-74, instead of relying on the NumberFormatException.
• Name the right method in the log message.

Vertex/Edge example (问题点 / 边数据举例)

Not applicable.

Schema [VertexLabel, EdgeLabel, IndexLabel] (元数据结构)

Not applicable.