In the predominant solution design, i.e. if the latest switch lore doesn't have some spankin' new theory attached to it, for a packet to change vlan id it is required to pass through an L3 router.
If your client and server are on the same ip subnet the packet will not pass through an L3 router. If they also are on different VLANs, they effectively will not be able to reach each other.
But if they are on different ip subnets(L3), the network design usually also associate those subnets with separate vlan id's(L2). Then it is a matter of allowing ip routing (i.e. L3) to place the packets into the correct vlan through the routing process. Your servers which accept vlan tagged packets you will typically find to have an ip address per vlan id it accepts, each belonging to the ip subnet associated with the respective vlan. Your routers will facilitate reachability from clients on other vlan ids/subnets.
So routing is either the key to your solution, or the design is such that the vlans which you are looking at are not 'meant' to communicate. In which case you could opt for changing that design.
Put differently, vlan switches add vlan tags on egress and remove them on ingress. You don't change that basic premise and don't add to it unless you really have a thought out design requirement and solution (see the QinQ link below). To hop between vlan ids you use the overlying protocol ip, i.e. most likely your default gateway (the closest router).
If this answer makes no sense, look here for a good discourse on basic vlan theory and how L2 and L3 interoperate from a vlan perspective:
How do VLANs work?
For a splendid discourse on ip subnetting theory, i.e. the L3 perspective, look here:
How does IPv4 Subnetting Work?
If this is not what you want and still wish to do QinQ because you knew all of that stuff anyway, read the final "Problems..."-part in the following link. If you had no trouble understanding those and had answers for them already (I don't as I never did provider bridging), knock yourself out: