How to manage non-constant release days in Scrum?

For example, last Friday we finished our last sprint before regression. We have to start our next sprint in Monday but we can't do so because of regression and bug fixing.

Should I start sprint after regression in this case at Wendsday? Or may be I should start at Monday and spend this days for mythic build time and do not plan work for my teams?

You don't really have an increment if additional testing is needed or bugs need to be fixed after the Sprint. Every Product Backlog item added to the Increment should the Definition of Done. Do you have a robust Definition of Done that all teams who integrate with your product agree to and follow? Your Definition of Done should include regression and integration testing. I might start there.

Your Increment from what I understand is never "done" every Sprint. If you don't have a Done Increment every Sprint you are not yet doing Scrum - that's the game changer you need to work towards.

When we are close to release, we make a regression testing for 2 days

That's a long time to wait before obtaining transparency over the state of a Done, integrated increment. It's not surprising that all sorts of problems are then uncovered.

It sounds as though you have a Nexus of Scrum Teams working on the same Product, which has integration requirements.

What can the teams do to assure transparency over the state of the Done increment continually throughout the Sprint? How can testing -- including regression -- be better automated for example? Perhaps representatives from each team ought to meet every day and collaborate over these and other integration matters.

The thing that I don't understand is the "independent teams who are also working on this project". Is this referring to the three teams that aren't the team you are working on? Or are there team(s) other than the four teams who work on the project.

Since you have four teams working on the same product, I see two problems.

The first thing that I would do is see what it would take to allow each team to get each unit of work fully designed, developed, integrated, and tested (as a whole system, including regression testing) within a Sprint. That could be much more difficult than it sounds.

I'd also look at a scaling framework like LeSS or Nexus to coordinate the work between the set of teams. Even if one team is able to effectively plan their work, you also need to manage dependencies and make sure that all of the teams understand the impacts that they may have on each other and reduce those dependencies.

The difficultly will be in solving both of these problems simultaneously. I don't think that you'll see measurable wins unless you take on both problems. Solving the problems for one team won't do much for the overall product delivery unless all of the teams are able to improve the quality of their work and make the integration and regression activities faster and more consistent.

Every Product Backlog item added to the Increment should the Definition of Done. Do you have a robust Definition of Done that all teams who integrate with your product agree to and follow? Your Definition of Done should include regression and integration testing. I might start there.

Yes, we have a rough DoD for every sprint, but we make regression testing just before releasing our build. So yes, you are right. This is a start point. Regress and integration testing not uncluded in DoD.

But there is always «but». We can't make one feature for just one sprint. We have complex features that require at least 5 weeks of work or more. We work at 2 weeks sprint for now because it is suitable for us. If we merge our not-ready-for-publish features in one branch and then start regression testing, our release will not be ready for deploy due to unfinished work. 

Perhaps representatives from each team ought to meet every day and collaborate over these and other integration matters.

We have Scrum of Scrums every day, but it's not that clear about state of the release build. We talk about sprints, dates of code freeze, and regression testing, but we have problems when all that starts. Just pure chaos, a lot of bugs that we could not predict. Half of them appear due to merge one big feature with another. 

Or are there team(s) other than the four teams who work on the project.

My bad. We have team of animators, motion designers and so on. They are working with our project and another one. We cannot just add them to one of our team due to lack of work most of the time for sprint.

Even if one team is able to effectively plan their work, you also need to manage dependencies and make sure that all of the teams understand the impacts that they may have on each other and reduce those dependencies.

Great advice! Thanks.

Solving the problems for one team won't do much for the overall product

And this is the problem. We have to do that for project, not for teams. Scaling is hard :)

Thank you all for answers! If you have something in mind, I would like to hear it too.

How can I plan the work of my team in this circumstance? 

I'm going to start with that question.  You don't mention what role you are fulfilling but in reality it doesn't matter. The answer is that you can't plan the work of your team.  The team as a whole needs to plan the work. And if you are using the word "team" to encompass all four of the teams, then my answer becomes even more correct.  You have identified a possible problem which you need to take to the team(s) to address. 

Adding on to the great advice you have gotten so far, you are not creating an increment, as described in the Sprint Guide, for any of your Sprints. Your increments are not valuable or useful until your regression testing is completed and that occurs outside of your Sprints. 

The increment is measured for completeness by the Definition of Done.  You do not mention whether any of these definitions exist for the organization or any team.  However your statements imply at least two parts of a Definition of Done. "All code must be fully Regression Tested" and "All defects must be addressed".  According to your statement, each team "on our project" works on different features so each team should be able to regress independent of the others.  As others are suggesting, your teams should find a way to bring the regression testing for each increment into the boundaries of the Sprint. In the end, it will lead to quicker releases for the customers and more productivity for the developers.