For Quick-Fix, Jump directly to the ip neigh replace section

Diagnostic Process:
First, check routing and neighbors with ip route and ip neigh

1
2
3

# ip neigh
xx.xx.xx.2 dev eth0 FAILED 
xx.xx.xx.1 dev eth0 INCOMPLETE

Resolution for the INCOMPLETE issue (ignore the FAILED one).
Checking results with tcpdump shows:
When replying, a large number of ARP, Request who-has xx.xx.xx.1 are sent.
Conclusion:
The gateway is “Playing Dead”: The key point is that no one is responding to this ARP request. Because your VPS cannot get the MAC address of the gateway xx.xx.xx.1, it doesn’t know who to throw the reply packet to, causing the packets to be dropped inside your network card.

ip neigh -6 shows the v6 gateway address (usually on the same server; if not, you’ll need to open a ticket or look at your control panel)
Temporary Fix Attempt: Add Static ARP Record

1
2
3

## Recommended to delete first
ip neigh del xx.xx.xx.1 dev eth0
ip neigh add xx.xx.xx.1 lladdr aa:bb:cc:dd:ee:ff dev eth0

If it displays:
RTNETLINK answers: File exists
It means there is already an entry for xx.xx.xx.1 in the kernel’s ARP table (even if it’s in a FAILED state), so the add command cannot be executed.

In this case, you should use the replace command, or fully flush the neighbor table first (ip neigh flush dev eth0)

1

ip neigh replace xx.xx.xx.1 lladdr 00:01:e8:8b:9c:10 dev eth0

Usually, the connection will be restored at this point. Try ping -c 4 1.1.1.1. If it works, make the settings permanent.
Add a line to the v4 section in /etc/network/interfaces:

1
2

# Recommended to add after the route or gateway line
ip neigh add xx.xx.xx.1 lladdr 00:01:e8:8b:9c:10 dev eth0 || true

Do not restart just yet, run:

1

systemctl restart networking

Then check if the network is normal.

Fix Completed.

Addendum: Why does v4 fail while v6 works?

Because IPv4 and IPv6 are completely different in their underlying mechanisms for “finding neighbors (gateways)”.

IPv4 is a 40-year-old technology, while IPv6 was designed with the lessons learned from IPv4, making it more “intelligent” and automated.

Here are the three core reasons for “V4 failing, V6 working”:

1. Difference in Discovery Mechanisms: ARP (IPv4) vs. NDP (IPv6)

  • IPv4 uses ARP (Broadcast): When your VPS wants to find the gateway, it shouts aloud: “Who is xx.xx.xx.1? Please tell me your MAC!” (Broadcast). In some data centers, if the switch has ARP Suppression or Port Isolation enabled, or because you reinstalled the system and the switch hasn’t reacted to the old MAC record, it may ignore your shout.
  • IPv6 uses NDP (Multicast/Notification): IPv6 no longer uses broadcast; it uses Neighbor Discovery Protocol (NDP). More importantly, IPv6 gateways usually send Router Announcements (RA) periodically.

Key Point: IPv4 is you actively “asking” where the gateway is (if it doesn’t reply, you’re blind); whereas the IPv6 gateway usually actively “announces” where it is. Your VPS just needs to listen (Listen) to get the MAC of the gateway, with no need for active requests.

  • IPv4: Must have a globally unique IP and configured mask to talk to the gateway.
  • IPv6: Every network card automatically generates an address starting with fe80:: upon startup. IPv6 gateway communication is usually based on this local address. Even if your public IPv6 is not configured well, as long as there is an fe80 address, your VPS can communicate with the gateway at layer two.

3. “Silent Gateway” Security Policy

Many modern data centers implement extremely strict restrictions on switches to prevent ARP Spoofing:

  • The switch only allows specific MAC addresses to send ARP requests.
  • Or, the switch does not forward any ARP broadcasts at all unless it has learned your device information through the DHCP process.

If you manual configure a static IPv4 without going through a DHCP handshake, the switch might treat you as an “illegal device” and refuse to reply to your ARP requests. In contrast, IPv6 was designed from the ground up with security (such as SeND protocol) in mind, making its compatibility in cloud environments often better than that of the aging IPv4.

Summary

Your situation is essentially: The IPv4 gateway is “playing deaf and dumb,” not replying to your ARP requests; while the IPv6 gateway is “shouting loudly,” actively telling you its location. Therefore, by manually “pinning” the IPv4 gateway’s MAC address in the system, you bypass that “asking” step and push the data packets directly to the gateway.