Deciding between mod_jk, mod_proxy_http and mod_proxy_ajp

posted by mthomas on June 16, 2010 07:06 AM

Over the years there have been a number of connectors developed to enable Apache httpd to communicate with Tomcat that have used a variety of protocols. When searching the web for information on how to do this, it isn't unusual to stumble across some really bad, out of date advice. So first of all the only options you should consider for this are:

All of the other other options have not been supported for a number of years so you should avoid mod_jk2, mod_jserv, mod_webapp and any other module that isn't discussed here.

My experience with providing support to SpringSource customers is that a typical customer is more likely to hit a bug in mod_proxy_ajp than they are in mod_jk or mod_proxy_http. It isn't that mod_proxy_ajp is particularly buggy, I used it myself for 18 months on a production system without a single issue, but that it has a few more bugs than the other two modules. The situation is improving but at the time of writing I would rank mod_jk and mod_proxy_http above mod_proxy_ajp.

That brings us to the crunch question: mod_proxy_http or mod_jk? And the answer? It depends! Both modules have their strengths and weaknesses. Which one is right for you will depend on your circumstances. The factors that normally affect this choice are:

  • Is one module already in use?
  • Does the communication between httpd and Tomcat need to be encrypted?
  • Does httpd terminal SSL but the SSL information needs to be passed to Tomcat?

If you are already using mod_jk or mod_proxy_http and it meets all of your requirements then there is unlikely to be a good reason to change it. It would be better to stick to what you are currently using and to have consistency across your httpd instances.

If you need to encrypt the communication between httpd and Tomcat then this is significantly easier with mod_proxy_http when you can just switch from the http to the https protocol. mod_jk uses the AJP protocol which doesn't support encryption so you have to implement that separately via an SSH tunnel, IPSec or similar. This can add significant configuration complexity to the httpd-Tomcat communication channel.

Where httpd terminates the SSL, providing the SSL attributes are exposed (two simple directives) then mod_jk automatically passes this information to Tomcat and Tomcat makes it available to web applications without any additional configuration required. To achieve the same result with mod_proxy_http requires httpd to be configured to add the SSL information as http headers and a Valve needs to be configured in Tomcat to extract this information and to make it available to web applications. Making SSL information available to Tomcat is therefore a little more complicated with mod_proxy_http.

mod_jk and mod_proxy_http also have very different configuration styles. The mod_proxy_http directives are consistent with other httpd directives whereas mod_jk uses an external property file. For system administrators familiar with httpd, the mod_jk approach can look a little odd.

In summary:

  • If you need to encrypt the httpd to Tomcat channel, use mod_proxy_http
  • If you need to expose SSL information to your web application, use mod_jk
  • If you are already using one of these modules then changing is likely to cause more hassle than it saves
  • Given a completely free choice, I'd use mod_proxy_http just because the configuration is more consistent with other httpd modules.

Mark Thomas is a Senior Software Engineer for the SpringSource Division of VMware, Inc. (NYSE: VMW). Mark has been using and developing Tomcat for over six years. He first got involved in the development of Tomcat when he needed better control over the SSL configuration than was available at the time. After fixing that first bug, he started working his way through the remaining Tomcat bugs and is still going. Along the way Mark has become a Tomcat committer and PMC member, volunteered to be the Tomcat 4 & 7 release manager, created the Tomcat security pages, become a member of the ASF and joined the Apache Security Committee. He also helps maintain the ASF's Bugzilla instances. Mark has a MEng in Electronic and Electrical Engineering from the University of Birmingham, United Kingdom.


why not mod_rewrite

We are using mod_rewrite in our project for communication between apache and tomcat. We are using mod_rewrite as it allows us finer control to redirect only certain subset like *.do to tomcat. Where as same needs to be done by LocationMatch for mod_poxy.

ON what basis is this comparison done? Was mod_rewrite considered?

mod_rewrite is an alternative

mod_rewrite is an alternative way of doing pretty much anything in httpd. The general rule with mod_rewrite is that if there is a more specific directive then it is better (clearer configuration, better performance) to use the more specific directive. Hence, my article focussed on mod_proxy and mod_jk.

In your example, there is no need to use a LocationMatch plus a ProxyPass, you could use ProxyPassMatch.

In the last two years I can think of one example where I used mod_rewrite to configure the reverse proxy and that was where the client wanted to select the back-end server based on part of the query string.

mod_proxy_ajp control interface

How do you control a cluster balanced tomcats using mod_proxy_ajp? For the mod_jk connector you can use the "status" worker to control and throttle trafic to the connected backend tomcat instances.

By using mod_proxy_balancer

Misled re mod_proxy_ajp?

Thanks for this useful article Mark! I was very surprised to hear AJP (mod_proxy_ajp) is not particularly recommended here, as I've been led to believe it would generally perform better than mod_proxy_http. The httpd docs page for this module seems to suggest as much (

Are there known bugs you have in mind when you state "it has a few more bugs than the other two modules"?

I also got the feeling that since mod_jk uses AJP "under the hood" that mod_proxy_ajp was nearly the same functionality and performance, just different configuration options--just my assumption. Am I way off? You definitely appear to be able to accomplish a lot of similar techniques with either mod_jk or mod_proxy_ajp--again, presumably due to leveraging the AJP protocol.

Lastly, do you _strongly_ discourage mod_proxy_ajp, or is it just a matter of "don't bother if you don't have a good reason"? And I presume the age-old advice, "it depends," of course applies here ;-) Thanks again!

Not misled

I have similar experience of satisfactory performance from mod_proxy_ajp, but it's a relatively new module and many people are still using prepackaged HTTPD instances at version 2.2.3, which is when mod_proxy_ajp was first included and it definitely was buggy back then.

If you're running a recent version, and of course you should be to stay current with bug and security fixes, then there's less likely to be a problem. I wouldn't go as far as to discourage anyone from using it.

For me, mod_proxy_ajp is useful when the configuration requirement is straightforward and uncomplicated.

I've experienced the bug when

I've experienced the bug when clients get pages intended to other clients instead of requested by them. mod_proxy_ajp in httpd 2.2.11 mix responses from Tomcat in some conditions. That was not funny.

What about flash under https?

Do you have any recommendation on what module to use? I have tried with mod_jk, without any success. That was quite some time ago, so maybe something has changed since then? Any comments on that would be really appreciated.
Thank you for this good article!

can't do with mod_jk: remapping

If you need to rewrite a URL before sending it to the backend server, e.g. the URL the user sees is and this needs to get mapped to - as far as I can tell, there is simply no way whatsoever to do this with mod_jk (I'd be glad to be shown wrong).

Now, this is very difficult to do right with mod_proxy (especially because of your app's self-referential links), but it is at least possible.

Cross platform IIS/Apache

If you have both windows/IIS and linux/Apache configurations, mod_jk and jk isapi filter have the same features, configuration files and manager interface.


mod_jk on Tomcat 7.0

We are trying to go to Apache 7.0; mod_jk needs external compilation there. After we do, we don't know how to hook Tomcat to it as no Tomcat 7 jar file seems to contain org.apache.jk.config.ApacheConfig. Is there a replacement, or do we go to mod_proxy and mod_proxy_ajp?


Eric Jablow


mod_jk and Apache Tomcat 7

There is no software product from the ASF called "Apache 7.0". I'm guessing you mean Apache Tomcat 7.

More recent releases of mod_jk have only included binaries for Windows since few users have a compiler available and only two binaries (one for 32-bit and one for 64-bit) are required. Trying to provide reliable binaries for all the other platforms was a lot of effort for little benefit.

ApacheConfig auto-generated various mod_jk configuration files. Apart from a single bug fix (bz 48917), that code hasn't been touched in well over 6 years. I suspect the configurations it does produce are not the most appropriate.

For as long as I can remember, folks have been creating the necessary mod_jk configuration themselves, usually starting from the sample configurations provided. The reference docs are available from with help and advice available via the Tomcat user's mailing list.

Authentication filtering on the httpd side

I need to wrap access to the tomcat app in a Central Authentication Service (CAS) filter. CAS filters can be activated on a Directory or Location basis. Which of these; mod_jk, mod_proxy_ajp or mod_proxy_html, would allow me to specify access inside of one of those tags?

Is this article still relevant 2 years down the road?

Is this article still relevant 2 years down the road? Particularly in the preference for mod_jk over mod_proxy_ajp? And even more particularly when upgrading from Apache 1.3.x to Apache 2.x to front Tomcat?

Deciding between mod_jk, mod_proxy_http and mod_proxy_ajp

Its still not clear what to use mod_jk, mod_proxy_ajp or mod_proxy_http.

Performance issues

What module is best if I need performance for my web application? Probably the mod_proxy_http module has to load the entire response from the server before starting to send it back to the client. Is this the case? Is this the same with mod_jk or mod_proxy_ajp?

Website performance

From Pivotal engineering:

None will wait on the entire response. Jk/ajp were preferable in the days of slow Ethernet. Now in the modern day, proxy_http is really easier to config and debug, can speak SSL, and doesn't have some hard coded limits of the ajp protocol.

Stacey Schneider is the managing editor for

Need version 2 for this article


I think its 3 year old and with tomcat 8 in beta, I request author to write version 2 of this article and help new bees like me understand the best practice.

Post new comment

This question is for testing whether you are a human visitor and to prevent automated spam submissions.