Proxying traffic with Apache Web Server to Apache Tomcat

on Feb 5, 19 • by Andrew Carr • with No Comments

This post explains how to set up your Apache Web Server and Apache Tomcat on a Linux server, and includes a working example...

Home » Open Source, OSS Export » Proxying traffic with Apache Web Server to Apache Tomcat

Application servers are required to allow an end-user to access your applications. After reading this post, you should be able to set up your web server to send traffic to your application server. This blog is split into three sections: the setup, the configuration, and the final working example.

Stay tuned for part 2 of this post, introducing SSL (Secure Socket Layers) or encryption, into this setup.

A simple way to allow access to the application server is to place a web proxy in front of it:


Here, the inbound traffic is passed, via mod proxy, to the application container, Tomcat.

In addition to simply proxying traffic to the application server, you can also load balance if you have a proxy. This will allow you to direct web traffic to multiple application servers:


Here, we see the inbound requests are passed to the web server. The web server then passes the traffic to any number of application containers via proxy and load balancing.

I will be configuring Apache Web Server and Apache Tomcat on CentOS Linux for this post, and I will be using YUM for ease of installing. Most commands can easily be translated into other package management solutions, such as Aptitude.


To begin, we install Apache Web Server, Apache Tomcat, and Java. I am going to use YUM for Apache Web Server and Apache Tomcat, while downloading an RPM for Java.
sudo yum install httpd tomcat mod_proxy_html

You should see output similar to this:

Transaction Summary
====================================================================================Install  2 Packages (+55 Dependent packages)
Total download size: 74 M
Installed size: 167 M
Is this ok [y/d/N]:

Accept the installation, and accept the public keys if asked. Once this process completes, you have Apache Web Server and Apache Tomcat installed on your Linux machine, though they’re not running. If this is a fresh install, then Java is not installed.

Download the Java RPM from Oracle. You can install the Java Runtime or JDK using YUM, but I prefer Oracle for test setups versus OpenJDK.

https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html (I am using Java 8 here, not 9, 10, or 11)

Transfer the RPM to the server (or download it directly on the server), and install it as follows:
sudo rpm -ivh jdk-8uXXX-linux-XXX.rpm

Replace the “XXX”’s with version and arch values. If on CentOS, you should be able to execute the following:
/usr/java/latest/bin/java -version

And receive output:

[andrew@localhost ~]$ /usr/java/latest/bin/java -version
java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)


We have everything in place to start our configuration of Apache Web Server. Before we start making changes, start the server and check that you can connect to the machine and view the web page.
systemctl start httpd
ps -ef | grep httpd

[andrew@localhost ~]$ systemctl start httpd
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to manage system services or units.
Authenticating as: andrew
[andrew@localhost ~]$ ps -ef | grep httpd
root      6295     1  0 22:18 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache    6299  6295  0 22:18 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache    6300  6295  0 22:18 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
andrew    6305  4479  0 22:18 pts/0    00:00:00 grep --color=auto httpd
[andrew@localhost ~]$

You can run “ip” to check your server’s IP address, which you should know already, and use this value to connect to a server from a browser.
ip a

[andrew@localhost ~]$ ip a
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:f0:e9:5b brd ff:ff:ff:ff:ff:ff
inet brd scope global noprefixroute dynamic eth0

Enter the hostname or IP address of the server in your browser and you should see output like this:


Spin up Tomcat for testing too.
systemctl start tomcat
sudo mkdir /var/lib/tomcat/webapps/ROOT
sudo mkdir /var/lib/tomcat/webapps/test
sudo vi /var/lib/tomcat/webapps/test/index.html

Press the “I” key to insert text, type the word “test”, press the “escape” key, then press “SHIFT” + “Z” two times to save and exit.

Now input the IP address or hostname in your browser ending in “:8080/test/”, like my example here:


When Apache Web Server is installed with YUM, it should place the configuration files in “/etc/httpd”. Your directory structure should look like this:

[andrew@localhost ~]$ ls /etc/httpd -R
conf  conf.d  conf.modules.d  logs  modules  run

httpd.conf  magic

autoindex.conf  README  userdir.conf  welcome.conf

00-base.conf  00-dav.conf  00-lua.conf  00-mpm.conf  00-proxy.conf  00-proxyhtml.conf  00-systemd.conf  01-cgi.conf

For the purpose of this tutorial, we will stick with the httpd.conf file and our proxy configuration. Fire up your favorite editor and open the httpd.conf file. I am using VI here.

Note that in Apache 2.4, the configuration is spread out across multiple files. This was done in earlier versions of Apache as well. It depends on the architecture of the deployment system, but this is standard in most cases.

The proxy modules are being loaded from the 00-proxy.conf file, as you can see from the contents, and the html proxy is being loaded from the 00-proxyhtml.conf file. These files contain the “LoadModule” directives, and you can place configuration for the proxy elements here. Today, we will place configuration directives for the proxy module in the httpd.conf file.
sudo vi /etc/httpd/conf/httpd.conf

Here we will add the following lines to the configuration, for ease of use, at the end of the file:

ProxyPass “/test” “http://<your-ip-address>:8080/test/”
ProxyPassReverse “/test” “http://<your-ip-address>:8080/test/”

Save the file.

Working example

Now you need to restart your Apache Web Server.
systemctl restart httpd

Since we are using CentOS with SELinux enabled, we will have to enable the proxying of packages:
/usr/sbin/setsebool -P httpd_can_network_connect 1

Open your web browser, type the IP address, and add “/test” to the end of it. You do not have to enter the port number. This means that it is using port 80 by default. The web server is receiving the traffic and forwarding it to the http connector running in Tomcat on port 8080.

Now enter your server’s IP address in the browser, followed by “/test/error”. We see a 404 error, because there is no “error” page. Note that the error is supplied by Tomcat, not Apache. The first image is the Tomcat error, the second is an Apache Web Server error.


If you go to the IP address of the server, with no suffix, you will receive the original Apache Web Server page, because we are only proxying requests to the “/test” web context.


We see that installing Apache Web Server, Mod Proxy, Apache Tomcat, and Java is pretty straightforward in Linux. Once the appropriate packages are installed, it is pretty easy to set up a proxy. Once you have configured the proxy in the configuration file for the web server and added a little bit of content to Tomcat, you are ready to go.

Once the proxy configuration is set up as it is in this example, you should be able to access the web server home page, and your test page on the Tomcat server, depending on what address you use.

The log files for the web server are located at “/var/log/httpd” and the Tomcat log files are at “/var/log/tomcat.” You do not have to use Apache Tomcat — this proxy configuration will work for any http backend, including another Apache Web Server.

Don’t forget “SELinux,” enabled on some Linux servers, that can cause weird permission errors. If you don’t add the rule for proxying, you might see “Permission Denied” errors in the log files when trying to proxy requests.

In future posts, we will discuss proxying with SSL to an encrypted endpoint, and “End-to-end encryption,” which means data is not decrypted at any point in the transmission process for maximum security.

And don’t forget… Our open source architects are available to assist you with this and other popular open source solutions!

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top