There are a few technical solutions to this:

• Have them point their domain to your server, and configure your server to accept such requests; this is a simple DNS change, but it does mean that their entire domain now runs on your server.
• Have them set up a reverse proxy on their end that rewrites the desired requests to your domain. Apache, for example, has modules for this (see https://httpd.apache.org/docs/2.2/mod/mod_proxy.html), including filters to rewrite URLs inside the documents you serve; this is kind of a hassle to set up, and it doesn’t work for everything, but it may be worth giving a shot – if it does work, your application will run transparently under their domain, served through their servers, but running on your own servers. The basic idea is that their server matches request URLs against a certain pattern, forwards them to your server, and then changes the URLs in the response it receives before sending it back to the client. (Basically, this is your router.php solution, only at the web server level, thus with less hassle.)
• Have them put an iframe into their page, in which they just put your page. If the iframe has 100% width and height, the user won’t see the difference (except that navigation does not change the visible URL). This is by far the easiest solution.
• Split up your application into a service layer and a front end. Deliver the front end, but keep the service layer on your server. This way, they can only make use of your service through your server; the front-end without the service layer is relatively useless.
• Install and maintain a server (physical or virtual) on their network that runs your application; set it up so that they cannot access it (strong passwords, full-disk crypto, etc.).

However, the problem is a social one, not a technical one, and the proper social solution is to set up a proper contract (hint: you do need a lawyer for this) that clearly states what they can and cannot do with it, and deliver the code. Yes, you need to trust them not to violate the contract in clever ways; but that’s just the way of the world.

If you absolutely cannot trust them not to be criminals, then maybe you should just decline the offer and make your money elsewhere.

1. “www” is a sub-domain.
2. foo.yourclient.com/profile <– if the links are all relative to the root, then there’s nothing to configure. Otherwise, set this for the BASE HREF.

The simple solution is to manage sub-domains, host the software yourself and market it as a SaaS solution. The only hurdle might be skinning the code on a sub-domain basis to match their main site.

Or you can take the overly complex path where you need to deploy obfuscated/compiled code onto their servers, fix any problems with how their servers are setup, coordinate with their IT people to update the software, handle database issues on their servers, etc.

Or you can convert your software to an API and build a RESTful layer that your clients can use from a website they build and maintain.

Would it be an option for them to use a subdomain? So:

They create a subdomain like: accounts.theirdomain.com and in DNS set your server IP.
You accept those requests and show the data for their accounts.

Example: https://support.zendesk.com/entries/13976-mapping-a-host-name-of-your-own-to-zendesk-using-cname

You could protect your code with a tool like Zend Guard, IonCube or something similar. Most hosts I’ve seen support the use of protected scripts.

Distribute your application in a virtual machine which runs on VMWare or VirtualBox or something similar. All your customer sees is a virtual server in their network. Everything inside is only accessible to you. Your customer does need to be able to support virtualization in their IT environment, but that is becoming more & more common these days.

You will have to do some extra configuration depending on whether they support DHCP or fixed IP addresses, if they insist on data backups, and if they need SSL certificates installed. But either way, they don’t have to see anything inside the VM.