First, these timeouts occur in the client, not in SQL Server. By default, most client APIs get tired of waiting for response from the database after 30 seconds, whereupon they tell SQL Server to stop running the submitted batch and then they throw an error to the rest of the application.
There can be many reasons for these timeouts. It may be perfectly normal that the batch runs for a few minutes, because it needs to process a lot of data. The remedy is to adjust the timeout which is a property on the command object. My recommendation is that if you have no other requirement to set the timeout to 0, which means wait forever. (And in my not-so-humble opinion, this should be default. Nothing else makes sense.)
But it could also be that the batch is expected to complete in a second, but runs for a much longer time, because of an issue with the query plan.
Another possible reason is blocking. That is, one or more rows that the SQL code needs to access are locked by another process for a longer time. That could be for all sorts of reasons, including someone starting a transaction in SSMS but never committing or rolling it back.
Given that the issue only happens on the publisher and not on the subscriber, suggests that this is a blocking problem. However, it could also be that you get different query plans in the two environments.
The first step is to identify which operations that are failing. Is it always the same query that fails? Or are the multiple, all accessing the same table? Are the queries expected to always be quick? The answers to these questions will lead you whether this is a blocking problem a or an issue with a long-running query.