0

I have a Spring Boot application deployed in a VPS. I packaged it as a war and deployed it through the Tomcat manager (<IP>:<Tomcat port>/manager/html).

It works if I access the endpoints by using the VPS' IP, such as http://<IP>:<Tomcat port>/api/login. However, it doesn't work if I access it by the domain name, such as http://example.com:<Tomcat port>/api/login. More specifically, I get (failed) net::ERR_CONNECTION_TIMED OUT in the Network tab of Chrome Developer Tools.

By other means I know the domain is correctly pointing to the VPS' IP. I searched around and tried the following solutions:

But none of these worked.

I also tried the nginx solution from the linked question, but it seems to me that nginx never worked on this VPS, as it fails nginx -t with the setup that came with the VPS.

Since I have a React app also being deployed by this VPS, I think making Tomcat use port 80 is not an option.

Since I'm not finding any other solution, what can I do?

Update 1: forgot to add apachectl -S output as per the description of (anonymized):

[Fri Sep 21 13:42:06.248978 2018] [proxy_html:notice] [pid 29712] AH01425: I18n support in mod_proxy_html requires mod_xml2enc. Without it, non-ASCII characters in proxied pages are likely to display incorrectly.
VirtualHost configuration:
<VPS IP>:8080    example.com (/home/<user>/conf/web/example.com.apache2.conf:1)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex fcgid-pipe: using_defaults
Mutex watchdog-callback: using_defaults
Mutex proxy-balancer-shm: using_defaults
Mutex rewrite-map: using_defaults
Mutex fcgid-proctbl: using_defaults
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/run/apache2/" mechanism=default
Mutex mpm-accept: using_defaults
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="www-data" id=33
Group: name="www-data" id=33

Update 2: the React app stopped working. I followed the advice of nginx -t, fixed it, restarted it and it started working again. There's a chance I broke something related to that while trying to implement reverse proxy, so probably disregard the above comment about.

Update 3: also forgot about attempt to change Spring's filter.

GuiRitter
  • 109
  • 2
  • 8

2 Answers2

0

The first thing you should do is to capture network traffic on the client side. You should capture traffic for both the case where it is working and where it is not working.

Then compare the two to find out at what point they behave differently. It's quite likely they are not both accessing the same IP address.

Other explanations are possible. If both establish a connection to the same IP and send a request, but only one receives a response it may be that either the server is taking longer time to process the request, or the server produce a longer response and trigger an MTU issue.

kasperd
  • 30,455
  • 17
  • 76
  • 124
  • I used Wireshark and noticed some interesting stuff. While I analyze it, I've updated the first post with something I had forgotten and a probable correction. – GuiRitter Sep 21 '18 at 17:50
  • When I make a request to the IP, Wireshark shows a pair of transmissions, both to Tomcat's port. One of them is composed of 2 TCP packets, where the first one has flags `FIN` and `ACK`. The other one starts with a TCP packet just with the `SYN` flag and contains HTTP packets for the `OPTIONS`'s and the `POST`'s request and response. When I make a request to the domain name, Wireshark shows 3 transmissions containing only a few TCP packets, where all of them start with `FIN` and `ACK` flags and only one of those is addressed to Tomcat's port, the others are addressed to port 80. – GuiRitter Sep 21 '18 at 18:10
  • Oh yeah, all to the same IP. – GuiRitter Sep 21 '18 at 18:12
  • @GuiRitter If the first packet you see is a `FIN` then that is from an older connection which the browser may have kept open since the last time you accessed the page. If you see an actual payload in the `SYN` packet, then that is a bit unusual. Apart from that there isn't enough detail to say what is wrong. – kasperd Sep 21 '18 at 18:39
0

I eventually managed to make it work, but I changed so many things that I don't remember what I did exactly.

But I know that it has something to do with nginx and Apache. Basically, you'll keep Spring as it is and configure those that receive connections before Spring to receive them correctly and redirect them to where Spring is mapped to (i.e. localhost).

I think this is the nginx setup to make it work:

/etc/apache2/sites-enabled/domain.com.conf

server {
    server_name  domain.com;

    location / {
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://localhost:<spring_port>;
    }
}

Find out your main nginx file with nginx -t, edit that file and add an include /etc/apache2/sites-enabled/domain.com.conf inside the http part.

GuiRitter
  • 109
  • 2
  • 8