How to Fix Connection Timeout Error while Using Gen AI on Oracle APEX 26 (ORA-30699)

I was playing around with Oracle APEX's new AI features on a freshly booted Oracle Linux 9 VM as the new update support many new AI providers and it has a built in test button, I Filled the API keys and model names and setted up everything nicely and Tested It out but it errored out. So i checked my ACL to see if the issue was there, but no, ACL was configured correctly and the necessary privileges was granted .and everything looked fine from the outside: curl and wget worked perfectly from my host machine, no issues. But every single REST call from inside the database would hang and then die with this:

ORA-29273: HTTP request failed
ORA-30699: network connection failed: connection timed out

Infuriating. Here is what was actually going on and how I fixed it about 30 seconds.

My Setup

• Guest OS: Oracle Linux 9 (fresh install, no customization)

• Database: Oracle AI DB 26

• VM Network: VirtualBox with a Bridged Adapter (very important because this was the culprit here)

What's Actually Happening

The culprit is IPv6, specifically, the gap between what your host OS does and what Oracle's network stack does.

When the database here tries to reach an external endpoint like googleapis.com(since i used gemini), it performs DNS lookup. Modern DNS resolvers often return an IPv6 address first (something like 2404:6800:4003:c01::5f). Oracle dutifully tries to connect over IPv6. But here's the problem: VirtualBox's bridged adapter, your local router, or your ISP may not properly route IPv6 traffic. The packets just vanishes. No error, no reset they just silently get dropped.

Oracle waits and it gives up and throws that timeout error.

Meanwhile, your host machine's curl succeeds instantly because most operating systems have smarter fallback logic. they'll quietly retry over IPv4 if IPv6 stalls.

First of all confirm This Is Your Problem

Run this in APEX SQL Workshop → SQL Commands:

DECLARE
  l_host_ip VARCHAR2(100);
BEGIN
  l_host_ip := UTL_INADDR.GET_HOST_ADDRESS('googleapis.com');
  DBMS_OUTPUT.PUT_LINE('Resolved IP: ' || l_host_ip);
END;
/

• IPv6 (broken): Something with colons - e.g., 2404:6800:1111:c111::5f

• IPv4 (healthy): A dotted-quad address - e.g., 142.251.42.46 If you're seeing colons.

The Fix

Option 1 - Force IPv4 Priority (What Worked For Me)

Log into your Linux guest as root and run:

echo "precedence ::ffff:0:0/96 100" > /etc/gai.conf

That's it. This tells the getaddrinfo subsystem to prefer IPv4-mapped addresses over native IPv6, so DNS lookups return IPv4 results. No reboot needed since Oracle will pick it up on the next connection attempt.

This is the cleaner solution since it doesn't actually disable IPv6, it just tells the system to prefer IPv4 when both are available.

Option 2 - Disable IPv6 Entirely (Only attempt if option 1 didn't work)

If Option 1 doesn't cut it (e.g., your virtual network bridge keeps doing weird things with IPv6 discovery), you can turn IPv6 off at the kernel level:

sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.default.disable_ipv6=1

This takes effect immediately. To make it survive reboots, append those same two lines to /etc/sysctl.conf.

Verify the Fix

Re-run the SQL block above then you should now see an IPv4 address. You can also confirm from the terminal:

ping -c 3 googleapis.com

The replies should show a standard IPv4 address in the output.

Then Test again from your Apex enviroment also.

After the Fix

Once IPv4 is prioritized, APEX_WEB_SERVICE.MAKE_REST_REQUEST calls resolve instantly. The AI service integration came up on the first try!

As I understand here. It's just that the VirtualBox bridged adapter + home router combination quietly breaks IPv6 routing, and Oracle doesn't compensate for it the way curl does.

The gai.conf one-liner is all you need.