Nextcloud with NGINX cannot access over LAN

Hello, I am very new to Nextcloud and configuration is definitely not my strong suit, so apologies for being a noob.
I have a problem with accessing my nextcloud instance over my LAN via its ip address. I am able to access it via its domain name I setup with ClouDNS within and outside of my network (as usual) but whenever I try to access it with the local IP address it simply redirects me to the domain. The reason I want to access it locally via its IP is because I don’t want all of my data to go out to the internet and back to my server since I’m in the same network as the server; it seems largely inefficient (if that’s even the case). I am running Nextcloud 20 with NGINX 1.18.0 with PostgreSQL 13 DB on Ubuntu server 20.04. Apologies in advance if this has already been answered, I am quite clueless at this point. Any help at all is hugely appreciated.

[/details]

Nextcloud version (eg, 18.0.2): 20.0.0
Operating system and version (eg, Ubuntu 20.04): Ubuntu server 20.04 LTS
Apache or nginx version (eg, Apache 2.4.25): NGINX 1.18.0
PHP version (eg, 7.1): 7.4

The issue you are facing: Can’t access with IP address

Is this the first time you’ve seen this error? (Y/N): Y

Steps to replicate it:

  1. Install Nextcloud 20 with PostgreSQL 13 DB and NGINX 1.18.0 on Ubuntu Server ([https://skedalabs.com/how-to-install-and-configure-nextcloud-with-nginx-postgresql-and-redis-on-ubuntu-1804])
  2. Port forward 80 and 443 with ClouDNS (works)
  3. Try to access locally with IP address of the machine, it redirects to the domain name with ClouDNS

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'memcache.local' => '\\OC\\Memcache\\Redis',
  'filelocking.enabled' => 'true',
  'memcache.distributed' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'datadirectory' => '/mnt/cloud/nextcloud/data',
  'redis' =>
  array (
    'host' => 'localhost',
    'port' => port#,
    'timeout' => 0,
    'dbindex' => 0,
  ),
  'passwordsalt' => 'removed',
  'secret' => 'removed',
  'trusted_domains' =>
  array (
    0 => 'domain.cloudns',
    1 => 'local IP',
  ),
  'dbtype' => 'pgsql',
  'version' => '20.0.0.9',
  'overwrite.cli.url' => 'https://domain.cloudns',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'user',
  'dbpassword' => 'password',
  'installed' => true,
  'app_install_overwrite' =>
  array (
    0 => 'breezedark',
    1 => 'camerarawpreviews',
    2 => 'unsplash',
    3 => 'files_fulltextsearch_tesseract',
    4 => 'files_fulltextsearch',
    5 => 'fulltextsearch',
    6 => 'bookmarks_fulltextsearch',
    7 => 'fulltextsearch_elasticsearch',
    8 => 'facerecognition',
    9 => 'occweb',
    10 => 'radio',
    11 => 'ocsms',
    12 => 'music',
    13 => 'weather',
    14 => 'sendent',
    15 => 'extract',
    16 => 'printer',
  ),
  'instanceid' => 'id',
  'updater.release.channel' => 'stable',
  'maintenance' => false,
);


You have to add the IP to the server_name directive in your nginx configuration. You might run into „certificate not trusted problems“ though, since an IP is not a valid server name indication.

Are you sure the traffic leaves your local network, when using the domain name? Most modern routers are intelligent enough to not route traffic through the internet going to the external IP of the router itself.

Thank you so much, I replaced the server_name from my domain to the ip (10.0.0.2 for example) address under listen [::]:80 like so:
server {
listen 80;
listen [::]:80;
server_name 10.0.0.2;
# enforce https
return 301 https://$server_name:443$request_uri;

I can now access it both from its local ip and the domain name, hopefully this is the right way to do it, as the domain still works normally and redirects to https (good). It does show a certificate error in the browser but I’m not too bothered by it as long as the server itself works.
I’m unsure whether the traffic was leaving the network or not, but when accessing from the ip address and doing an upload test, it seemed to be much faster than accessing via the domain (25 MB/s compared to 10 MB/s).

Thanks for the help.