The most concordant solution would be to change the front-end application so that, in the first place, it inserts Null instead of 0.
If this isn't possible, it might be relevant to explain why as part of the question, to understand exactly what the profile of limitations are on a solution.
As @SergeyA notes in the comments, it may be a possibility to have a zero-keyed entry in the master table which is used to represent a default or absent link whilst maintaining the referential integrity between the tables.
If you must fall back to triggers, in my view it would be worth considering the possibility of using the trigger to enforce the foreign key selectively, than to use the trigger to rewrite the data on the fly. That is, you would disable the built-in foreign key check, then replace it with a trigger that only enforces the foreign key if it is non-zero, and ignores the enforcement if it is zero.
It is very easy to abuse triggers in ways that make subsequent supervision or re-adaptation of the database extremely difficult and error-prone.
Anything that alters the behaviour of basic SQL commands (such as rewriting an insert zero into an insert null, on the fly), or adds side-effects or forms of reactivity which are not limited to the enforcement of constraints, and does it all in a way that must be completely transparent to a front-end module that cannot be changed, are really the kind of things that are done when an application is already heavily sclerotic and terminally-ill.