I'm also getting the error: "The automated update service is unavailable for your site as it's not accessible from the internet. Automated updates have been disabled."

Joomla 5.4 w/ Cloudflare DNS
The site is public, and everything else is functioning correctly.

WR would need the domain namens to validate the issue from our side. If you don't like to send it publish then email me at Harald.Leithner@community.joomla.org

@komir2004 I checked your site and found out that your .htaccess blocks requests to /api/index.php I didn't looked in details which rule exactly is the problem but please validate the url. If this .htaccess file is generated with a builder please contact the vendor of this tool, maybe they can help finding the rule.

I registered your site successfully, but since your .htaccess is in place again your site will not be updated in the future.

@J-Wick4 also please check your .htaccess file, but you might have another issue.

WR would need the domain namens to validate the issue from our side. If you don't like to send it publish then email me at Harald.Leithner@community.joomla.org

I actually use NGINX, here's my config from additional directives in Plesk.

`# Joomla URL rewriting
location / {
try_files $uri $uri/ /index.php?$args;
}

Support API

location /api/ {
try_files $uri $uri/ /api/index.php?$args;
}

Handle PHP files

location ~ .php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include /etc/nginx/fastcgi.conf;
}

Security headers

add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header X-Frame-Options "SAMEORIGIN";
add_header Content-Security-Policy "default-src 'self' https: data: blob: 'unsafe-inline' 'unsafe-eval'";

add_header Referrer-Policy "strict-origin-when-cross-origin";
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()";

Deny running scripts inside writable directories

location ~* /(images|cache|media|logs|tmp)/.*.(php|pl|py|jsp|asp|sh|cgi)$ {
return 403;
error_page 403 /403_error.html;
}

Deny access to sensitive files

location ~* .(tpl|ini|log|conf)$ {
deny all;
}

Optimize file caching

location ~* .(ico|pdf|flv)$ {
expires 1y;
add_header Cache-Control "public, no-transform";
}

location ~* .(js|css|png|jpg|jpeg|gif|swf|xml|txt)$ {
expires 14d;
add_header Cache-Control "public, no-transform";
}`

Plesse send me a super user account.

I have 32 sites, all the same problem, all are on NGINX and are internet faceing (some are with Cloudflare and some are NGINX Proxymanager):
{"errors":[{"title":"Resource not found","code":404}]}

This is my nginx config:

server {
        listen 443 ssl;
        listen [::]:443 ssl;
        http2 on;

        server_name xxx.com www.xxx.com;
        root /var/www/XXXX/CMS;
        index index.php index.html index.htm;

        # SSL configuration
        ssl_certificate /etc/ssl/XXXX/cert.pem;
        ssl_certificate_key /etc/ssl/XXXX/key.pem;

        # Server and security headers
        server_tokens off;
        add_header Alt-Svc 'h3=":443"; ma=86400, h3-29=":443"; ma=86400' always;
        add_header Last-Modified "";
        add_header X-Content-Type-Options "nosniff" always;
        add_header Referrer-Policy "strict-origin";
        add_header X-XSS-Protection "1; mode=block";
        add_header Permissions-Policy "autoplay=(self), encrypted-media=(), fullscreen=(), geolocation=(), microphone=(), midi=()";
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

        # Logging
        access_log /var/log/nginx/xxx.log custom;
        error_log /var/log/nginx/xxx_error.log;

        # Prevent directory listings
        autoindex off;

        # Content-Security-Policy for SVG files
        location ~* \.svg$ {
            add_header Content-Security-Policy "script-src 'none'";
        }

        # Block common exploits
        set $block 0;
        if ($query_string ~ "base64_encode[^(]*\([^)]*\)") {
            set $block 1;
        }
        if ($query_string ~ "(<|%3C)([^s]*s)+cript.*(>|%3E)") {
            set $block 1;
        }
        if ($query_string ~ "GLOBALS(=|\[|\%[0-9A-Z]{0,2})") {
            set $block 1;
        }
        if ($query_string ~ "_REQUEST(=|\[|\%[0-9A-Z]{0,2})") {
            set $block 1;
        }
        if ($block = 1) {
            return 403;
        }

        # Joomla SEF URL rewriting
        location / {
            try_files $uri $uri/ /index.php?$args;
        }

        # API-specific rewriting
        location /api/ {
            try_files $uri $uri/ /api/index.php?$args;
        }

        # PHP processing
        location ~ \.php$ {
            include snippets/fastcgi-php.conf;
            fastcgi_param PHP_ADMIN_VALUE "allow_url_fopen=1";
            fastcgi_param PHP_ADMIN_VALUE "disable_functions=system, shell_exec, passthru, exec, popen, proc_open";
            fastcgi_param PHP_VALUE open_basedir="/var/www/xxxx/:/tmp/";
            fastcgi_param HTTP_AUTHORIZATION $http_authorization;
            fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        }
        
        # Deny access to sensitive files
        location ~* /(configuration\.php|htaccess\.txt|\.htaccess|composer\.json|composer\.lock|web\.config\.txt) {
            deny all;
        }
}

{"errors":[{"title":"Resource not found","code":404}]}

Please verify that the webservices plugin for the Joomlaupdate component is enabled

Wanna rise my hand here. I get the same problem. Plugin is enabled and I can load any *.php fro the API folder if I upload a test. So it's not blocked by .htaccess. Since it DOES reply with a JSON, it sure must run.

Any place where I can gather more information on that problem?

WHO is gonna open that URL when the timeout is reported? If it's a server internal call, then I have no possibility to check how the URL is called from the web server itself. The web is hosted elsewhere and I have no root access. i.e. I can verify it is accessible from the outside, but I cannot tell whether the URL is accessible from the inside.

Please run curl -A "Joomla.org Automated Updates Server" https://yourdomain/api/index.php and check the result. It's possible that the request is getting blocked by a WAF or similar. You can also check if the IP of the update server ist blocked. Currently the IP of the outgoing requests of the update server is 52.14.131.139 but we can't guarantee this IP forever. Which means it can change next month or in 10 years.

if you get an error page with the curl request you might ask your ISP to while list the IP of the update server.

The CURL (called from my workstaion) results in the infamous {"errors":[{"title":"Resource not found","code":404}]}.

Traceroute again done from my workstation...

traceroute to 52.14.131.139 (52.14.131.139), 64 hops max
  1   192.168.2.254  0,378ms  0,235ms  0,232ms 
  2   91.135.161.2  3,118ms  1,318ms  1,885ms 
  3   185.196.242.97  1,823ms  1,850ms  1,805ms 
  4   213.248.76.30  5,901ms  5,613ms  5,544ms 
  5   62.115.114.184  5,977ms  5,917ms  5,507ms 
  6   62.115.137.202  16,089ms  16,880ms  16,949ms 
  7   62.115.123.13  25,118ms  24,426ms  24,458ms 
  8   62.115.140.105  106,961ms  107,480ms  108,923ms 
  9   62.115.140.101  110,442ms  *  101,114ms 
 10   *  *  * 
 11   108.166.248.74  109,843ms  108,984ms  109,219ms 
 12   *  *  * 
 13   108.166.244.2  113,112ms  111,348ms  112,886ms 
 14   *  *  * 
 15   *  *  * 
 16   *  *  * 
 17   *  *  * 
 18   *  *  * 
 19   * ^C

---
traceroute to 52.14.131.139 (52.14.131.139), 64 hops max
  1   192.168.2.254 (_gateway)  0,307ms  1,094ms  0,207ms 
  2   91.135.161.2 (bng01.neum.net.pr-link.at)  1,812ms  2,776ms  1,741ms 
  3   185.196.242.97 (bng01-neum.core01.neum.net.pr-link.at)  2,038ms  0,826ms  1,812ms 
  4   213.248.76.30 (win-b2-link.ip.twelve99.net)  5,875ms  6,283ms  5,804ms 
  5   62.115.114.182 (win-bb2-link.ip.twelve99.net)  5,655ms  6,100ms  5,850ms 
  6   62.115.138.22 (ffm-bb2-link.ip.twelve99.net)  16,557ms  17,632ms  17,093ms 
  7   62.115.122.138 (prs-bb2-link.ip.twelve99.net)  25,279ms  26,101ms  25,838ms 
  8   62.115.140.107 (ash-bb2-link.ip.twelve99.net)  107,556ms  106,722ms  106,527ms 
  9   62.115.140.209 (rest-b6-link.ip.twelve99.net)  106,708ms  106,412ms  106,736ms 
 10   *  *  * 
 11   108.166.248.33 (108.166.248.33)  117,746ms  117,220ms  116,050ms 
 12   *  *  * 
 13   *  *  * 
 14   *  *  * 
 15   *  *  * 
 16   *  *  * 
^C

Things get a little weird, once entering the twelve99.net area.

Got the same results as @rorso

I just tried that curl command on a server where updates are enabled successfully and get a 404 as well - so I'm not sure thats a good test to run

get a 404 as well

We have to be careful about how we call this result. A 404 error usually means an HTTP return code of 404 due to a "page not found" reported from the web service.

Here we get an HTTP result of 200 which means "page successfully returned" and indeed the PHP script does run, it processes some data and returns a valid JSON structure - that happens to contain a value named "errors". This is not exactly "a 404 error" and thus not likely something to be solved with the own web server/provider.

This probably should hint to a fact that the process itself tried to contact some remote page and faced a "page not found" or more likely a timeout - which is returned to the caller. I didn't walk through the code, but if the script is trying to contact the server at 52.14.131.139, then it most likely will fail.

I meanwhile managed to try a ping from the web server shell and get timeout. Unfortunately traceroute is not available at the provider web server shell.

The update server is behind cloudflare, the IP it uses to connect to your site is from the aws VM, so the stack trace isn't really helpful since the connection seems to work since a 404 is returned.

I was not explicit enough on the return value of the /api/index.php check

if it returns {"errors":[{"title":"Resource not found","code":404}]} it's likely the joomla installation telling you that it doesn't found the component. If it looks different it might be a WAF or similar which blocks the request.

if you run the following request /api/index.php/v1/joomlaupdate/healthcheck you would get
{"errors":[{"title":"Token is required","code":403}]} which is ok because you don't have the auth token set.
This is what we need so the update server can check the health of the page, on activation and afterwards.

it's likely the joomla installation telling you that it doesn't found the component.

I tried to follow the execution with the API, but I confess I'm not capable enough. I would at least have to enable XDebug on the hosting site - which is not available.

Is it possible to determine the component that seems to be missing? Essentially all the API stuff is "system" and "locked", everything enabled and "looks fine".

I would expect that this would be something new, as this started with the 5.4 update. So either something was not installed as necessary or the API is broken for a longer time and this function just used it for the first time. I'm not certain whether any of my stuff ever used the API before. So I might have migrated a problem from past ages.

When I try to access specific parts in the API tree, I seem to get a return. I find nothing to be blocked by the server. But certainly I don't know where to look exactly.///

Just tried registering again -- tadaaa

I did change nothing. Honestly.

Thanks for listening ...