Hi there, is there any willing legend here?
I installed on Ubuntu 22.04 Nextcloud 29 according to this Complete Walkthrough for Installing Nextcloud on Ubuntu 24.04 – Learn Linux TV and after that Only Office document server according this install_onlyoffice_nextcloud_same_ubuntu_server [Install Config Wiki].
Everything is working like a charm, both are visible from external domains and internal IPs (OO DS on 81 port).
External ports 80 and 443 on my router are forwarded to the internal IP of the Ubuntu Server, Authorization OO DS in Nextcloud App is set according to this (since set time) https://youtu.be/d-mAT_StyeY?feature=shared&t=398.
Unfortunately, I still got this message.
I think, there is some problem with NGINX. Isn´t it? What to send to you to suggest the right solution?
This is my nginx.config
user www-data;
worker_processes auto;
pid /run/nginx.pid;
error_log /var/log/nginx/error.log;
include /etc/nginx/modules-enabled/*.conf;
events {
worker_connections 768;
# multi_accept on;
}
http {
##
# Basic Settings
##
sendfile on;
tcp_nopush on;
types_hash_max_size 2048;
# server_tokens off;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# SSL Settings
##
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;
##
# Logging Settings
##
access_log /var/log/nginx/access.log;
##
# Gzip Settings
##
gzip on;
# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
##
# Virtual Host Configs
##
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
Thank you in advance
Hello.
You need to define your host/connection to onlyoffice-service inside the http{} directive.
It should be something like this:
upstream office-gryg427 {
server 127.0.0.1:81;
}
Hello again.
I was able to reach your OO-service, based on the server address from your screenshot.
Did you tried out the integrated test example to see if OO is working correctly?
Check the logs from OO first to see what is going on. Could be an issue with other services blocking ports.
Usually those instructions/howtos work, if not too outdated and followed to the letter.
Cheers.
Thanks a lot. I put the snippet into nginx.conf and I see an alert “Error when trying to connect (cURL error 6: Could not resolve host: office-gryg427 … (see libcurl - Error Codes) for https://office-gryg427.duckdns.org/healthcheck)” on OO configuration page in Nxtc, and domain is not reachable from outside.
healthcheck depicts 502 Bad Gateway …
So obviously something is wrong :-/. Any other idea? Thanks again
Example is visible without any troubles (with original nginx.conf)
Hello again.
What have you put in for the internal addresses in the connector server settings?
Your screenshot doesn’t show that part.
The upstream directive is obviously wrong, since you have set up the virtual hosts according to the instructions in the wiki. It was just a guess of mine, since you asked for help with your nginx config. But the hosts are configured and your nextcloud and OO service is reachable from outside (tested it myself)
Cheers.
Thanks, man, I´m kind of a newbie so my questions or definitions might sound silly. Don´t worry about saying to me that anytime.
Anyway,
in the “ONLYOFFICE Docs address for internal requests from the server” is put HTTP://“internal_address”:81 (“internal …” is in correct form x.x.x.x)
in the “Server address for internal requests from ONLYOFFICE Docs” is the domain name you already successfully tested
I hope they are both ok 
The situation is pretty same in case I leave both fields empty or fill in with HTTPS://“domain …”
Hi,
you should put in there the internal addresses of the services. Since you have your setup on the same host, it should be http://127.0.0.1:81 for OO-services and http://127.0.0.1:80 for your nextcloud-services.
Since my setup is virtual in a docker environment, my settings looks like this:
This defines how both are resolved internally. This is just to understand where OO and nextcloud are supposed to be.
Don’t mind my secure connection. I simply configured it this way initially.
Just a question … did you add your subdomains to nextcloud’s “trusted_domains” configuration?
yes, I did. But still a dead end
I had a liveable combination OO and Nextc on two Ubuntu VM’s under Truenas, but I woul like to simplify all the solution just on one engine …
Then you have to check the logs from onlyoffice.
Everything seems to be set up (almost) correctly.
Check the logs for errors and everything that looks unusual to you. That may give you the push in the right direction. Post the most important parts (use proper format) if you can’t make anything of them.
Then you should check out docker in the near future. It is kinda like a VM but stripped down to the core functions and isolated in an container-environment. Very easy to setup (once you understand the principle) manage and to update/downgrade, etc. Most services are run in VMs today.
1 Like
this is the log I got. Is there any clue which can help us?
may be, but I always don’t give affairs up without fight 
When this is your log from onlyoffice, then there is some mixup with “wordpress”.
I guess “127.0.0.1” really redirects to your own PC
Put in your internal OO/NC server ip back under server settings in the connector-app and try again. But put also the internal ip for your nextcloud connection, not the external. Then restart you nginx and after press “save” in the connector-app again. Then provide the log.
Hello,
just checking. Have you managed to make it work?
Cheers.
Sorry for the late answer, I have been overwhelmed since our last contact.
So, I don’t have any idea where the message wordpress comes from I only run WP in test mode on other VM with different internal IP through the same br0 under the same TrueNAS system, but it was completely erased about a week ago and TN has been already restarted for a few times.
Now I put both addresses, clicked on Save button, restarted ngingx, and clicked on Save again (the message Bad GTW was still there in both cases).
This is the log nginx.error.log output now.
2024/11/13 11:00:23 [error] 2593#2593: *69 connect() failed (111: Connection refused) while connecting to upstream, client: x.x.x.x, server: , request: “GET /healthcheck HTTP/1.1”, upstream: “http://127.0.0.1:8000/healthcheck”, host: “x.x.x.x:81”
x.x.x.x is my right internal IP I hid (don´t know exatly why but I feel safer now :-)))))))
Do you need anything more for investigation? Thx
Well, the log says the connection is being redirected to “http://127.0.0.1:8000/healthcheck”, which in your case should be “http://<your internal IP>:<port>/healthcheck”.
Everything goes by your proxy. In my opinion configuring localhost in the connector makes sense, since everything is on the same host, but for the sake of not making a mistake, you should be also able to put your hostname in here too or his IP (generally speaking, in my opinion, 127.0.0.1:8000 is not wrong here)
In my case the internal host is "https://onlyoffice/ which I can’t resolve from the pc I’m sitting at right now. The redirect happens on the server and is not exposed to the client. So that is why I was sure 127.0.0.1 in your case would be ok. The proxy redirects to the same host (itself) but to a different port. It makes sense in my head
I know document-server is running on port 8000 in the default configuration. You can check it on your host
cat /etc/onlyoffice/documentserver/default.json |grep -B4 8000
You can also verify that on the host (your server) too. Use this on the host’s console:
wget -qO - http://127.0.0.1:8000/healthcheck
And this you use from your client’s console:
wget -qO - http://<your servers internal ip>:8000/healthcheck
In both cases you should see the string “true” being send back.
Alternatively, you can also use curl to see what really happens:
curl -v http://<IP depending on which host you are>:8000/healthcheck
There should be a more detailed output showing you a successful response or some soft of failure.
Report back with a failure if you see one. Success will only prove that document-server is running like it should. Then we have to really check your proxy or the connector settings again.
Cheers.
